Subject: [scim] ATTN: Your opinions please by CoB today

From: Keith Hazelton <[email-masked]>
Date: Fri, 15 Apr 2016 17:51:38 +0000

TIER-APIarians and Other Interested Parties,

Please read the following edited excerpt from the TIER-API call earlier today and send back any criticisms or suggestions by CoB Friday (today). The long arc of the 'Alternative Proposals' thread on TIER-API seems to be bending toward convergence.  Here’s the point reached by the participants on today’s call. If anyone has concerns or suggestions, please send them to the list ASAP. We’d like to get a definitive position nailed down in writing before the TIER Release 1 button is pressed (Saturday). Thanks in advance, --Keith

----------

  *   TIER will initially define two new resource types and their schemas: (Edu)Person and (Edu)Member. Other TIER resource types may follow later: Membership, Attribute, etc). The new resource types will follow the well documented SCIM procedures and rules for defining new resource types.

  *   TIER will adopt the SCIM-defined Users and Groups resources and, if a few additional TIER-Specific attributes are needed, TIER will define a schema extension following SCIM procedures and rules, and the TIER-specific attributes would then show up in a TIER schema extension element after all the normal SCIM attributes that make up a User representation.

  *   Sites that adopt TIER may need to add some local attributes to (Edu)Person, the likeliest point of extension. In that case, they should use the same SCIM-defined schema extension model, and add their local attributes in a locally-defined schema extension at the bottom of an (Edu)Person representation.

  *   Open question: Use the 'Edu' prefix on all TIER-defined Resource Types?  It seems like a good idea, but it is not strictly necessary because the schema URL will uniquely specify its own naming authority.

--
email & jabber: [email-masked]<mailto:[email-masked]>
calendar: http://go.wisc.edu/i6zxx0

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Apr 2016 11:00:25 -0700

Keith,

Thanks for sharing. 

See my comment in line…

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Apr 15, 2016, at 10:51 AM, Keith Hazelton <[email-masked]> wrote:
> 
> Please read the following edited excerpt from the TIER-API call earlier today and send back
>  any criticisms or suggestions by CoB Friday (today). The long arc of the 'Alternative Proposals' thread on TIER-API seems to be bending toward convergence.  Here’s the point reached
>  by the participants on today’s call. If anyone has concerns or suggestions, please send them to the list ASAP. We’d like to get a definitive position nailed down in writing before the TIER Release 1 button is pressed (Saturday). Thanks in advance, --Keith
> 
> 
> ----------
> TIER will initially define two new resource types and their schemas: (Edu)Person and (Edu)Member.
>  Other TIER resource types may follow later: Membership, Attribute, etc). The new resource types will follow the well documented SCIM procedures and rules for defining new resource types.

Why new resource types?  Why not extend the SCIM User resource (same way as enterprise user does)?  FWIW, not all that different from LDAP.  One downside to having multiple resources for a User is referential integrity issues. Extending the base user object lets you keep attributes together.  One difference that we have form LDAP is we maintain a separate JSON sub-object for the extension schema - that avoids naming collisions between extensions (e.g. say one university creates an attribute with the same name as a TIER attribute).

> 
> 
> TIER will adopt the SCIM-defined Users and Groups resources and, if a few additional TIER-Specific
>  attributes are needed, TIER will define a schema extension following SCIM procedures and rules, and the TIER-specific attributes would then show up in a TIER schema extension element after all the normal SCIM attributes that make up a User representation.
> 
> Sites that adopt TIER may need to add some local attributes to (Edu)Person, the likeliest point of extension. In that case, they should use the same SCIM-defined
>  schema extension model, and add their local attributes in a locally-defined schema extension at the bottom of an (Edu)Person representation.
> 
> Open question: Use the 'Edu' prefix on all TIER-defined Resource Types?  It seems like a good idea, but it is not strictly necessary because the schema URL will uniquely specify its own naming authority.
Agreed.  However, “Edu” prefix makes it more obvious in all the interactions you’ll have (ie. you can see it in the URL).
> -- 
> email & jabber: [email-masked] <mailto:[email-masked]>
> calendar: http://go.wisc.edu/i6zxx0 <http://go.wisc.edu/i6zxx0>_______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Keith Hazelton <[email-masked]>
Date: Fri, 15 Apr 2016 18:49:16 +0000

Responses inline

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 15, 2016 at 13:00
To: Keith Hazelton <[email-masked]<mailto:[email-masked]>>
Cc: TIER-API <[email-masked]<mailto:[email-masked]>>, SCIM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] ATTN: Your opinions please by CoB today

Keith,

Thanks for sharing.

See my comment in line…

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Apr 15, 2016, at 10:51 AM, Keith Hazelton <[email-masked]<mailto:[email-masked]>> wrote:
TIER-APIarians and Other Interested Parties,

----------

  *
TIER will initially define two new resource types and their schemas: (Edu)Person and (Edu)Member. Other TIER resource types may follow later: Membership, Attribute, etc). The new resource types will follow the well documented SCIM procedures and rules for defining new resource types.

Phil,  Thank you for responding so quickly.

  *   The primary reason we currently prefer the separate Resource Type route is that the venn diagram of the schema for EduPerson and SCIM Users would show a relatively small intersection. That makes us think they should be represented as two different resources subject to two largely distinct sets of operations.  Yes, there is a referential integrity aspect to the Person-User relationship, but that relationship seems conceptually clean and manageable: EduPerson representations would contain pointers to their corresponding User object, and User representations could have a simple Edu extension that carried pointers back to the corresponding EduPerson object. The creation and maintenance of those relationships occur at a relatively few logical points in the architecture.
  *   As Chris Hyzer pointed out in a recent email to SCIM, another pain point with the JSON container approach to extensions is that if we wanted to tinker with a complex element within a User resource, e.g. add a TIER-specific type to a particular User email address, the extension JSON object would have to have some kind of link to carry the association between the extension Type attribute and a particular User email attribute, so that raises a referential integrity issue at the attribute level.
  *   SCIM extension by JSON object DOES prevent naming collisions, but so would namespace alias prefixes on extension attributes. However, I certainly understand the disinclination to reopen the discussion around SCIM extension mechanisms.

                       Regards,   --Keith

  *
TIER will adopt the SCIM-defined Users and Groups resources and, if a few additional TIER-Specific attributes are needed, TIER will define a schema extension following SCIM procedures and rules, and the TIER-specific attributes would then show up in a TIER schema extension element after all the normal SCIM attributes that make up a User representation.

Agreed.  However, “Edu” prefix makes it more obvious in all the interactions you’ll have (ie. you can see it in the URL).
--
email & jabber: [email-masked]<mailto:[email-masked]>
calendar: http://go.wisc.edu/i6zxx0
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 15 Apr 2016 11:55:06 -0700

Yes. I agree, extending existing complex attributes has been an issue that has come up for us as well. 

We'll have to see if this becomes a more widespread desire to address at the standards level. 

Phil

> On Apr 15, 2016, at 11:49, Keith Hazelton <[email-masked]> wrote:
> 
> Responses inline
> -- 
> email & jabber: [email-masked]
> From: Phil Hunt <[email-masked]>
> To: Keith Hazelton <[email-masked]>
> Cc: TIER-API <[email-masked]>, SCIM WG <[email-masked]>
> www.independentid.com
> [email-masked]
>> Please read the following edited excerpt from the TIER-API call earlier today
>>  and send back any criticisms or suggestions by CoB Friday (today). The long arc of the 'Alternative Proposals' thread on TIER-API seems to be bending toward convergence.
>>   Here’s the point reached by the participants on today’s call. If anyone has concerns or suggestions, please send them to the list ASAP. We’d like to get a definitive position nailed down in writing before the TIER Release 1 button is pressed (Saturday). Thanks
>>  in advance, --Keith
>> 
>> 
>> ----------
>> TIER will initially define two new resource types and their schemas: (Edu)Person
>>  and (Edu)Member. Other TIER resource types may follow later: Membership, Attribute, etc). The new resource types will follow the well documented SCIM procedures and rules for defining new resource types.
> 
> The primary reason we currently prefer the separate Resource Type route is that the venn diagram of the schema for EduPerson and SCIM Users would show a relatively small intersection. That makes us think they should be represented as two different resources subject to two largely distinct sets of operations.  Yes, there is a referential integrity aspect to the Person-User relationship, but that relationship seems conceptually clean and manageable: EduPerson representations would contain pointers to their corresponding User object, and User representations could have a simple Edu extension that carried pointers back to the corresponding EduPerson object. The creation and maintenance of those relationships occur at a relatively few logical points in the architecture.
> As Chris Hyzer pointed out in a recent email to SCIM, another pain point with the JSON container approach to extensions is that if we wanted to tinker with a complex element within a User resource, e.g. add a TIER-specific type to a particular User email address, the extension JSON object would have to have some kind of link to carry the association between the extension Type attribute and a particular User email attribute, so that raises a referential integrity issue at the attribute level.
> SCIM extension by JSON object DOES prevent naming collisions, but so would namespace alias prefixes on extension attributes. However, I certainly understand the disinclination to reopen the discussion around SCIM extension mechanisms.
>                        Regards,   --Keith
>>  TIER will adopt the SCIM-defined Users and Groups resources and, if a few
>>  additional TIER-Specific attributes are needed, TIER will define a schema extension following SCIM procedures and rules, and the TIER-specific attributes would then show up in a TIER schema extension element after all the normal SCIM attributes that make up
>>  a User representation.
>> 
>> email & jabber: [email-masked]