Subject: Re: [scim] SCIM compliance

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

Comments inline.
-- 
email & jabber: [email-masked]
calendar: http://go.wisc.edu/i6zxx0
_________
On 2016-04-13, 13:55 , "scim on behalf of Steve Moyer" <[email-masked] on behalf of [email-masked]> wrote:

>All,
>
>We've been working on a first-principles rewrite of our SCIM 2.0 system (based on a pre-ratified version of the specification) but we've also been promoting SCIM for its intended use in the higher-ed community.
>
>Recently there's been a discussion about what it really means to be "compliant".  I'm taking the hard-line view that without inter-operability, there's not really a point in being technically compatible.  The TIER group within the Internet2 is talking about creating TierUser and TierGroup ResourceTypes and using those instead of the core User and Group ResourceType.

The TIER API WG has now dropped that idea in favor of using the SCIM-defined USER and GROUP resource types. If there are TIER-Specific attributes, we will use the SCIM-defined schema extension model to include them.

>
>Technically, the specification allows *any* resource type to be added (per section 3.2 of the Schema specification) and while it implies the core User and core Group are required (using the word "provided") the specification doesn't technically say a service MUST provide those end-points.
>
>I've attached a document with the two favorite TIER proposals and my view is that neither of them are compliant.  Proposal two *could* be inter-operable if the persisted TIER user object was exposed via both the TierUsers and Users endpoints.  This violates a principle of REST (a resource has a unique URL) though.  I should also note that the use of query parameters, headers and HTTP status codes proposed by TIER are also "interesting".

The proposal currently on the table for the TIER WG is quite different than those described in Steve's attachment:

We will only create TIER-specific Resource Types when the SCIM-provided Resource Types don't already include an 80/20 solution to our requirements.

SCIM User and Group resources types suffice for TIER needs, possibly with small schema extensions for TIER-specific attributes.

TIER will initially define two new Resource Types, EduPerson and EduMember: 

-  EduPerson will carry representations of people in their rich and various guises within an Education and Research context. Each EduPerson resource will have a mapping to a corresponding SCIM User resource.

-  EduMember will carry detailed information about people in their guise as members of SCIM Groups. Memberships might include, for instance: Begin and end dates and other features that apply to memberships.

- In general, we are determined to make interoperation with SCIM endpoints as easy and transparent as possible while also meeting requirements particular to higher education and research domains. We intend to have a representative join the SCIM IETF Working Group for ongoing discussions.

       --Keith Hazelton, Chair of the TIER Data Structures and APIs Working Group

>
>What are this group's opinions?
>
>Thanks,
>
>Steve
>
>“All the easy stuff’s been done…. We’ve got the wheel, fire, the TV clicker—what else do you need?” - Dean Kamen