OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Groups - Event "Bi-weekly PSTC meeting" modified


Submitter's message
Corrected in the minutes several points made by Karsten during the Sep 12 meeting.
-- Gary Cole
Event Title: Bi-weekly PSTC meeting

Date: Monday, 12 September 2011, 02:00pm - 03:00pm ET
Description

1-866-682-4770 conference: 1938387 passcode: 123456


This meeting counts towards voter eligibility.

Agenda

1) Call Roll.

2) Approve minutes from Aug 29 meeting.

3) Review "SIMPLEST" draft:
- Account Management (adds Target and Account)
-- Added a draft of Account
-- Document implicit attributes of Target?

4) Discuss priorities for work yet to do on draft:
- Add draft of Access-Policy, Access-Privilege
- Examples of minimal implementation
- Examples of supporting User only

5) AOB


Minutes

Chair: Gary Cole

Attendees:
Gary Cole (Oracle)
Prateek Mishra (Oracle)
Karsten Huneycutt (UNC Chapel Hill)

Agenda:
1) Call Roll.
2) Approve minutes from Aug 29 meeting.
3) Review "SIMPLEST" draft:
- Account Management (adds Target and Account)
 -- Added a draft of Account
 -- Document implicit attributes of Target?
4) Discuss priorities for work yet to do on draft:
- Add draft of Access-Policy, Access-Privilege
- Examples of minimal implementation
- Examples of supporting User only
5) AOB


1) Call Roll
- Gary took roll.
- Quorum was *not* achieved (2 of 6 voting members attended)
- Voting status changes:
  -- Hal Lockhart changed from voting-member to member.
  -- Prateek Mishra changed from member to voting-member.
     --- Mr. Mishra should have regained voting-rights on June 6
     after attending both that meeting and the previous on May 23.
     --- The chair apologizes for this oversight.

2) Approve minutes from Aug 29 meeting
- Skipped due to lack of quorum.

* AI: Gary to add this to the agenda for next meeting on 9/26.

3) Review "SIMPLEST" draft:

Gary presented a draft of the Account object-class:
- Password Capability, Suspend Capability, isLocked...
- Additional attributes of Account per Schema of Target.
- Relationship to User (who owns each account).
- Target object-class is implicit (SPML listTargets, RESTPML target-contexts).

3A) Karsten asked:  Why not use inetOrgPerson attribute names in Person object-class?
Karsten mentioned that he doesn't have strong feelings either way, but he thinks it would be nice if the names are shared with at least one other schema so that the standards world doesn't have a gazillion similar-but-slightly-different names for the same thing.

Gary said that he is open to this and asked Karsten to suggest changes to names of attributes.
- Current names differ from inetOrgPerson for several reasons, none necessarily compelling:
  -- historically, participants in SPMLv2 objected to direct borrowing from inetOrgPerson.
  -- current proposal is a subset of earlier work, in which careful naming was often necessary
     in order to disambiguate several related attributes, e.g.:
     --- role-members-Direct
     --- role-members-Dynamic
     --- role-members-Indirect
     --- role-members-All       // direct, indirect, or dynamic
  -- current names facilitate comparison with other recent proposals for User schema.

3B) Karsten asked why Person has password-related attributes:
- A Person does not inherently possess a password as he does a physical address or email address.
- A Person requires a password only in the context of some system or application.
- This should be modeled as a Person with a relationship to an Account with a password.

Gary acknowledged the validity of Karsten's position.
Gary also admitted to having argued the same position in the past.
Gary presented his reasons for including password-related attributes in Person:
- Many enterprises use an entry in a central namespace to represent the Person.
  -- An entry in an LDAP Directory or Active Directory or IDM system has a loginName and password.
  -- This central loginName and password are often used for Single-SignOn (SSO).
  -- Many enterprises think of this as the loginName and password of the Person (rather than to a particular account).
  -- SSO and dynamic entitlements services grant access to many applications without any statically-provisioned account.
- Enterprises tend to refer to only statically-provisioned accounts (for apps that require them) as Accounts.
- Centrally-defined loginName and password are often treated as commonLogin and commonPassword:
  -- IDM systems use CommonLogin and commonPassword as the default credentials for provisioned applications.
  -- IDM systems often propagate changes of commonLogin and commonPassword to downstream applications.
- Customers and implementers of Providers want Person to (be able to) have loginName and password:
  -- Some want only to expose (a centralized definition of) Person.
  -- Requiring them also to expose an Account with a one-to-one relationship to Person is overkill.
  -- The relationship between Person and the Account used for SSO would have to be special.
  -- Distinguishing this SSO Account from other Accounts would require a special type of relationship or a 'primary' flag.
  -- Not only must a provider expose all of this, but each client must consume all of it.
- Allowing Person to have password-related attributes does not require any Provider to expose those attributes.
- Allowing Person to have password-related attributes is much simpler for providers who prefer to expose only Person.
- Allowing Person to have password-related attributes is simpler even for providers who intend to expose other Accounts.

Prateek echoed Gary's point about enterprise usage-patterns for "common" loginName and "common" password:
- SIMPLEST so far emphasizes a "catalog" of "conventions" with respect to object-classes and attributes.
- Conventions are more flexible than what strict interoperability straight-from-the-box would require.

Karsten emphasized that he wants to keep the model as clean as possible for the sake of interoperability:
- If a client expects those optional attributes to be present on Person and the attributes are absent,
  this could pose greater challenges to interoperability than the absence of other optional attributes (such as emails or phone numbers).
- This could have significant, practical implications for interoperability.

Karsten suggested treating "Person" and "Account" like LDAP objectClasses or Java interfaces -- different standard views on (perhaps) a single object...
- This has all of the benefits of keeping the password on the "Person", since any target with both capabilities could expose the same object as a Person and an Account.
- This has none of the drawbacks, except perhaps some minor difficulty or complexity with respect to the "RESTSPML" protocol's current approach of using object-class as part of the URI.

3C) Karsten suggested indicating which attributes are single-valued and which are multi-valued:
- he suggested adding a separate column in the tables in SIMPLEST draft on the PSTC wiki.

* AI: Gary agreed to do this, noting that Prateek had made a similar suggestion during a previous meeting.

3D) Karsten said that SIMPLEST need not model the Target-accepts-Account relationship explicitly:
- Agreed with Gary that this relationship was already implicit.
- Agreed with Gary that any attribute that could be placed on that relationship could just as well be placed in the Account itself, e.g.:
  -- whoAssigned
  -- whyAssigned
  -- whenAssigned
  -- whenCreated
- Prateek concurred in not modeling this as a formal Relationship-Type.

* AI: Gary to remove the Target-accepts-Account relationships, perhaps noting the reasons above.
20110919 - done.

3E) Gary *misunderstood* Karsten as suggesting that the boolean attribute "isDisabled" is partially redundant with "disableDate" and "enableDate":
- A client who understood the values of "disableDate" and "enableDate" should be able to calculate the value of "isDisabled".

Gary agreed with (what he thought was) Karsten's observation, but pointed out that:
- For many use-cases, clients care only whether an account is disabled currently--and care nothing about the future schedule.
- Requiring each client to calculate "isDisabled" requires in each client logic that is redundant--and possibly inconsistent.
- Some targets do not support future enablement or future disablement--and therefore cannot store disableDate or enableDate.

3F) Karsten discussed a distinction between *disablement* of an Account and *expiration* of an Account.
- The university system might expire an account on a schedule--e.g., when a student graduates.
- The university system might disable an account in response to certain conditions--e.g., a violation of policy--until those are addressed.

Gary said that *disablement* might work for both of those purposes:
- Administrative disablement can be scheduled.
- Administrative disablement can be set or cleared immediately.

Gary also pointed out that the university system is free to define its own attributes (e.g., "isExpired" or "status") with any semantics:
- Adding to SIMPLEST attributes with the university's semantics would require:
  -- that those semantics and any accompanying contract--i.e., testable behavior--be defined.

3G) Karsten asked whether it would be simpler to define a single attribute (e.g., "status") than separate attributes:
- A single attribute could replace, for example, "isDisabled", "isExpired", "isLocked"....

Gary replied that defining a single attribute such as "status" tends to overload the attribute:
- A "status" attribute could not represent both date-of-future-enablement and date-of-future-enablement:
  -- Thus, even a single "status" attribute would be coupled to other attributes (such as "disableDate" and "enableDate").
- Each value of "status" must be defined (and each client must understand each possible values).
- This tends to imply a detailed state-model that is complete and specific enough for every client to understand:
  -- Making such a state-model general enough that it works for everyone--i.e., standard--tends to be difficult.
  -- Each client must understand the meaning of each state and which transitions are valid--which is burdensome.
- It is (arguably)simpler to model separately each aspect of state that seems sufficiently general:
  -- This applies to the specification, to any provider who implements it, and to each client who consumes it.


4) Discuss priorities for work yet to do on draft:

(Did not discuss.)


5) AOB

(None.)



Owner: Gary Cole
Group: OASIS Provisioning Services TC
Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
METHOD:PUBLISH
VERSION:2.0
PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:America/New_York
BEGIN:STANDARD
DTSTART:20001029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T060000Z
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000402T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T070000Z
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CATEGORIES:MEETING
STATUS:CONFIRMED
TRANSP:OPAQUE
DTSTAMP:20110919T000000Z
DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20110912T140000
DTEND;VALUE=DATE-TIME;TZID=America/New_York:20110912T150000
SEQUENCE:2
SUMMARY:Bi-weekly PSTC meeting
DESCRIPTION:1-866-682-4770 conference: 1938387 passcode:
  123456\n\nAgenda: 1) Call Roll.\n2) Approve minutes from Aug
  29 meeting.\n3) Review &quot\;SIMPLEST&quot\; draft: \n-
  Account Management (adds Target and Account)   \n-- Added a
  draft of Account   \n-- Document implicit attributes of
  Target?\n4) Discuss priorities for work yet to do on draft:
  \n- Add draft of Access-Policy\, Access-Privilege \n-
  Examples of minimal implementation \n- Examples of
  supporting User only\n5) AOB\nGroup: OASIS Provisioning
  Services TC\nCreator: Gary Cole
URL:http://www.oasis-open.org/apps/org/workgroup/provision/event.php?event_id=30846
UID:http://www.oasis-open.org/apps/org/workgroup/provision/event.php?event_id=30846
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT00H15M00S
END:VALARM
END:VEVENT
END:VCALENDAR


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]