Subject: Re: [scim] Choosing a path regarding TIER-SCIM relationship

From: Keith Hazelton <[email-masked]>
Date: Thu, 14 Apr 2016 15:16:04 +0000

Chris,

Well, below you'll see one of the principal SCIM authors showing a fairly relaxed attitude about how schema get handled. To me, this reads as "do what you want 'in your own domain' but if you expect interoperability across domains, stick to 100% pure SCIM." Seems reasonable. That's what I think we'd want to do: Where we want/need to interoperate with SCIM-speaking domains,  map/filter our Internet2 TIER stuff down to pure SCIM and expose it on endpoints that are explicitly SCIM endpoints.

I also hear him being disinclined to re-open discussion of the SCIM extension model, so that makes it less likely that we will see significant changes there.

Does all that mean we revisit our choice to define TIER-specific User and Group resource types using SCIM-provided mechanisms? I don't think there's much to gain by that.

Think of a small utility: You send it a TierUser representation and you get back a pure SCIM representation; You send it a SCIM User and you get back a TierUser representation where only the directly corresponding attributes are carried over. You've got bi-directional translation, so TIER domain <==> SCIM domain interoperability is never more than one utility call away.

-------
"I don't think there is much interest in further extension features. The objective is to have a standard user object that represents a neutral format inspired by vcard that can be used to provision users between domains.

You can extend scim in many ways. The catch is what do you expect other implementations to accept and to parse? Scim's processing rules do ensure that at least most servers won't throw errors (scim2 has a "robust" model), they will just accept the data they understand--which means your extensions would likely be ignored.

IMO, Scim compliance then is about cross platform expectations and conventions. Like any rest service you are still free to do what you want in your domain."

Phil Hunt
------
From: Chris Hyzer <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 14, 2016 at 9:36 AM
To: Keith Hazelton <[email-masked]<mailto:[email-masked]>>, TIER-API <[email-masked]<mailto:[email-masked]>>
Subject: RE: Choosing a path regarding TIER-SCIM relationship

I understand the reasons for wanting to follow the standard and use SCIM, but I feel like if we want to do that we should take our current plan and compare it to pure scim one more time.  i.e. not have TierUser and TierGroup and just have User and Group and see what they would look like when we add in our Tier extension schemas.  I know its not ideal not to have a pristine representation, but Im bothered by having two separate resources, seems like it will cause issues down the road…

I know there are pros and cons here, but I think we should at least give it another look.  Maybe its not that bad…

Attached is some discussion on the scim list and they do not recommend our current approach…

Thanks
Chris

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Keith Hazelton
Sent: Wednesday, April 13, 2016 7:45 AM
To: TIER-API <[email-masked]<mailto:[email-masked]>>
Subject: [tier-api] Choosing a path regarding TIER-SCIM relationship

I have done my best to capture the two primary proposals I have heard in this ongoing discussion.  Each of you should feel empowered to edit the proposal definitions as well as the pros and cons.  See
https://spaces.internet2.edu/display/DSAWG/Alternative+Proposals+on+the+Relationship+Between+TIER+and+SCIM+APIs+and+Schema

Again, the TIER-API Working Group WILL make a definitive choice between alternatives no later than 5:00 pm, Friday April 15.

            Regards,   --Keith

Subject: Re: [scim] SCIM compliance
From: Phil Hunt <[email-masked]>
To: "Hyzer, Chris" <[email-masked]>
Cc: Steve Moyer <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 13 Apr 2016 23:08:29 +0000

Adding extensions to attributes is not a supported (or at least expected) way to extend the schema.

The expectation for each extension is there is a single JSON structure whose attribute name corresponds to the schema extension in the schemas attribute.

Existing implementations would not look for embedded extensions anywhere other than the root level of the top JSON structure.

Note also that you have “public” and “authenticated” as not valid in their own right.  They need a name value pair.

So assuming these are attributes with a true / false value, here is a structure that might work.  Note also that you can’t just overright a published schema (e.g. enterprise user). I’ve changed the schema URN to something unique (it could be anything really).  Note that in viewEmails I use the same “type” to associate the new attribute with the standard emails attribute.

Also, you could use just “emails” in your extension and that would generate no conflicts.  HOWEVER, it means that every time you want to reference emails in the extended schema you’d have to reference the attribute with the full urn namespace as well (e.g. urn:ietf:params:scim:schemas:extension:someorg:viewType:emails) in order to distinguish it from emails in the parent block (whose schema is urn:ietf:params:scim:schemas:core:2.0:User:emails).

{
  "schemas":
    ["urn:ietf:params:scim:schemas:core:2.0:User",
      “urn:ietf:params:scim:schemas:extension:someorg:viewType"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": "701984",
  "userName": "[email-masked]<mailto:[email-masked]>",
  "emails": [
    {
      "value": "[email-masked]<mailto:[email-masked]>",
      "type": "work",
      "primary": true
    },
    {
      "value": "[email-masked]<mailto:[email-masked]>",
      "type": "home"
    }
  ],
"urn:ietf:params:scim:schemas:extension:someorg:viewType”:{
  “viewEmails”: [{
     "authenticated”:true,
    “type”:”home”
   },
  {
    “public”:true,
    “type”:”work”
  }
  ],
  "meta": {
    "resourceType": "User",
    "created": "2010-01-23T04:56:22Z",
    "lastModified": "2011-05-13T04:42:34Z",
    "version": "W\/\"3694e05e9dff591\"",
    "location":
"https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
  }
}
Phil

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

   On Apr 13, 2016, at 1:28 PM, Hyzer, Chris <[email-masked]<mailto:[email-masked]>> wrote:

   Can you extend attributes inside the representation?  This is not a real example, just a hypothetical.

   i.e. if this is the SCIM representation:

   {
     "schemas":
       ["urn:ietf:params:scim:schemas:core:2.0:User",
         "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
     "id": "2819c223-7f76-453a-919d-413861904646",
     "externalId": "701984",
     "userName": "[email-masked]<mailto:[email-masked]>",
     "emails": [
       {
         "value": "[email-masked]<mailto:[email-masked]>",
         "type": "work",
         "primary": true
       },
       {
         "value": "[email-masked]<mailto:[email-masked]>",
         "type": "home"
       }
     ],
     "meta": {
       "resourceType": "User",
       "created": "2010-01-23T04:56:22Z",
       "lastModified": "2011-05-13T04:42:34Z",
       "version": "W\/\"3694e05e9dff591\"",
       "location":
   "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
     }
   }

   And we wanted to add an attribute to emails, we would want it to look like this.  But you cant add attributes throughout the object model right?  So if we add attributes to Meta, we need our own Meta object.  If we add attributes to Group, we wouldn’t see those in the groups attribute of the User?  The extensions seem usable if you are adding top level attributes to the returned resource, not if you are adding attributes to nested objects...

   {
     "schemas":
       ["urn:ietf:params:scim:schemas:core:2.0:User",
         "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
     "id": "2819c223-7f76-453a-919d-413861904646",
     "externalId": "701984",
     "userName": "[email-masked]<mailto:[email-masked]>",
     "emails": [
       {
         "value": "[email-masked]<mailto:[email-masked]>",
         "type": "work",
         "primary": true,
         "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:viewType": "public"
       },
       {
         "value": "[email-masked]<mailto:[email-masked]>",
         "type": "home",
         "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:viewType": "authenticated"
       }
     ],
     "meta": {
       "resourceType": "User",
       "created": "2010-01-23T04:56:22Z",
       "lastModified": "2011-05-13T04:42:34Z",
       "version": "W\/\"3694e05e9dff591\"",
       "location":
   "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
     }
   }

   -----Original Message-----
   From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
   Sent: Wednesday, April 13, 2016 4:07 PM
   To: Steve Moyer <[email-masked]<mailto:[email-masked]>>
   Cc: [email-masked]<mailto:[email-masked]>
   Subject: Re: [scim] SCIM compliance

   I would think you would want to use the core user resource and then extend it as we did with eduperson in ldap.

   Phil

   > On Apr 13, 2016, at 11:55, Steve Moyer <[email-masked]<mailto:[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.
   >
   > 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".
   >
   > 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
   > <DSAWG-AlternativeProposalsontheRelationshipBetweenTIERandSCIMAPIsandSchema-130416-1845-2144.pdf>
   > _______________________________________________
   > scim mailing list
   > [email-masked]<mailto:[email-masked]>
   > https://www.ietf.org/mailman/listinfo/scim

   _______________________________________________
   scim mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/scim

---

From: Steve Moyer <[email-masked]>
Date: Thu, 14 Apr 2016 11:36:39 -0400 (EDT)

I'd have to agree ... the chosen option (proposal two) looks like the right choice in light of Phil Hunt's comments. 

I'm not part of IdS at PSU (they may have other opinions) but as an integrator who has to write a lot of interface code to tie systems together, I'd be very happy if I could call a TIER system and get a SCIM User or Group back. Seems like you've found the best of both worlds? 

Steve 

From: "Keith Hazelton" <[email-masked]> 
To: "TIER-API" <[email-masked]> 
Cc: "SCIM WG" <[email-masked]> 
Sent: Thursday, April 14, 2016 11:16:04 AM 
Subject: [tier-api] Re: Choosing a path regarding TIER-SCIM relationship 

Chris, 

------- 

Phil Hunt 
------ 
From: Chris Hyzer < [email-masked] > 
Date: Thursday, April 14, 2016 at 9:36 AM 
To: Keith Hazelton < [email-masked] >, TIER-API < [email-masked] > 
Subject: RE: Choosing a path regarding TIER-SCIM relationship 

Thanks 

Chris 

From: [email-masked] [ mailto:[email-masked] ] On Behalf Of Keith Hazelton 
Sent: Wednesday, April 13, 2016 7:45 AM 
To: TIER-API < [email-masked] > 
Subject: [tier-api] Choosing a path regarding TIER-SCIM relationship 

Regards, --Keith