Subject: [scim] SCIM compliance

From: Steve Moyer <[email-masked]>
Date: Wed, 13 Apr 2016 14:55:25 -0400 (EDT)

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

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 13 Apr 2016 13:06:54 -0700

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]> wrote:
> 
> All,
> 
> <DSAWG-AlternativeProposalsontheRelationshipBetweenTIERandSCIMAPIsandSchema-130416-1845-2144.pdf>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: "Hyzer, Chris" <[email-masked]>
Date: Wed, 13 Apr 2016 20:28:53 +0000

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]",

  "emails": [

    {

      "value": "[email-masked]",

      "type": "work",

      "primary": true

    },

    {

      "value": "[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]",

  "emails": [

    {

      "value": "[email-masked]",

      "type": "work",

      "primary": true,

      "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:viewType": "public"

    },

    {

      "value": "[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]>
Cc: [email-masked]
Subject: Re: [scim] SCIM compliance

Phil

> On Apr 13, 2016, at 11:55, Steve Moyer <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>

scim mailing list

[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 13 Apr 2016 16:08:29 -0700

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 <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]> wrote:
> 
>   "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",
> "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646 <https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646>"
>   }
> }
>  
>   "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",
> "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646 <https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646>"
>   }
> }
>  
>  
> > On Apr 13, 2016, at 11:55, Steve Moyer <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > All,
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>

---

From: Koushik Narayanan <[email-masked]>
Date: Thu, 14 Apr 2016 04:41:31 +0000

Hi,

On Wed, 2016-04-13 at 14:55 -0400, Steve Moyer wrote:
> the TierUsers and Users endpoints.  This violates a principle of REST
> (a resource has a unique URL) though.

Is SCIM a REST protocol? I don't see that being mentioned in any of the
SCIM RFCs. 

Regards,
Koushik

---

From: Steve Moyer <[email-masked]>
Date: Thu, 14 Apr 2016 08:16:50 -0400 (EDT)

I originally asked the question since I have a vested interest in "at least" compatibility between TIER and SCIM, but I should point out that even in our current integrations, we've seen cases where extensions are cumbersome.  Yes, they technically work but also lead to what I'd call "dangerous" data structures.  To add an example to what Chris Hyzer posted below, we've got a system that stores multiple names.  Our extension allows you to retrieve this array of names, but you have to be very careful when allowing someone to update this resource as the User.name and Extension.names might contain conflicting data.

I understand the pros related to the extension mechanism, especially for inter-operability but perhaps we can at least describe the best-practices for using them.

One idea (that I believe would be backwards compatible with the released 2.0 specification:  What if single-valued and multi-valued complex attributes (such as name and address) were defined by their own core schema?  Then a core.User would contain a core.Name and an array of core.Address?  Making it possible for ResourceTypes to nest would promote reuse and would allow the "registration" of extensions against "defined attributes" (those with a corresponding schema).  It would also simplify the including schemas.

Any other ideas?  I appreciate the work that went into create the SCIM specifications and am excited by their potential.  I suspect that some of the harder parts of creating an implementation will be recurring themes as more projects adopt the SCIM standard.

Steve

----- Original Message -----
From: "Koushik Narayanan" <[email-masked]>
To: [email-masked], [email-masked]
Sent: Thursday, April 14, 2016 12:41:31 AM
Subject: Re: [scim] SCIM compliance

Hi,

Regards,
Koushik

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 14 Apr 2016 07:03:01 -0700

Yes. SCIM is restful.  

There is no published standard for REST so it is tricky to cite in a normative way in a specification. 

Phil

> On Apr 13, 2016, at 21:41, Koushik Narayanan <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 14 Apr 2016 07:40:10 -0700

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

> On Apr 14, 2016, at 05:16, Steve Moyer <[email-masked]> wrote:
>