Subject: [scim] SCIM schema IDs and JSON representation

From: Michael Frost <[email-masked]>
Date: Thu, 12 Feb 2015 12:46:07 -0800 (PST)

The following is the list of schema IDs present in the api/schema docs:

urn:ietf:params:scim:schemas:core:2.0:User*

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User*
urn:ietf:params:scim:schemas:core:2.0:Group*
 
urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig
urn:ietf:params:scim:schemas:core:2.0:ResourceType
urn:ietf:params:scim:schemas:core:2.0:Schema

urn:ietf:params:scim:api:messages:2.0:ListResponse
urn:ietf:params:scim:api:messages:2.0:SearchRequest
urn:ietf:params:scim:api:messages:2.0:PatchOp
urn:ietf:params:scim:api:messages:2.0:Error
urn:ietf:params:scim:api:messages:2.0:BulkRequest
urn:ietf:params:scim:api:messages:2.0:BulkResponse
 
We only provide JSON representation (of the schema itself) for the first three (marked with *).  Shouldn't we provide JSON representation for all schemas we reference?  It would be much more definitive and useful to have a JSON representation of all of these in a single place (appendix perhaps), than scattered text descriptions throughout the docs.
 
Message schemas in general appear somewhat problematic because they require complex within complex, which is not normally allowed.  The other problem is with urn:ietf:params:scim:api:messages:2.0:PatchOp.  Given the current text description, this schema cannot be represented in JSON using our current rules.  The "value" attribute is union of every possible attribute type, which is not allowed.  Therefore it is impossible to define a schema to drive parsing and validation as can be done with all other requests/responses.  It seems kind of wrong to have a URI reference a schema that cannot legitimately be defined with our own rules.
 
If these schemas are all standard, then is seems we should provide the definitive JSON representation for each one which alleviates ambiguities, misinterpretations, and compatibility issues that can arise from different understandings of the text descriptions.
 
-mrf

---

From: Phil Hunt <[email-masked]>
Date: Thu, 12 Feb 2015 12:58:15 -0800

Michael,

Can you provide examples?

The schema in the API has to extend the registry define in core.   As editor I think it would be even more confusing to mix data schema and request schema in a single document. It also becomes problematic when specs cross reference each other. Instead the document layout is such that API builds on core schema. 

The format in PATCH comes from the JSON Patch RFC. 

Phil

> On Feb 12, 2015, at 12:46, Michael Frost <[email-masked]> wrote:
> 
> .0:ResourceType
> urn:ietf:params:scim:schemas:core:2

---

From: Michael Frost <[email-masked]>
Date: Thu, 12 Feb 2015 16:44:44 -0800 (PST)

Hi Phil, 

Not sure what you mean by examples.  My concern is that in the schema doc, section 8.7 provides schema representation for core user/group and enterprise user.  What about all the other schemas we reference?  We should provide schema representation for every schema defined in the spec.  Everyone implementing this spec will need them.  Why provide just three and leave the rest up to guess work?  Every implementation needs to do validation, every validation needs a schema to validate against.  So my concern is twofold.  First, we reference a bunch of schemas that everyone needs, but we don’t provide them.  Second, some of the schemas we reference (such as patchOp) cannot be represented in JSON using our own definitions.

I’m certainly OK with an appendix in the api doc for message schemas and an appendix in the schema doc for all of the entity schemas.  My point is all these schemas should exist.  We reference them, we describe them, but we only provide three of them.  It just seems wrong to me (perhaps my own shortcoming) but we’re asking people to implement SCIM patch, using a SCIM schema defined request, that we do not provide, and cannot define using rules we set forth in section 7 of the schema doc.

So bottom line, all I’m requesting is the JSON representation of the SCIM schemas we reference.
 
This is a SCIM schema reference, “ urn:ietf:params:scim:api:messages:2.0:PatchOp“, I feel we should provide the JSON representation for it.  If we can’t do it, nobody implementing the spec can either.  All of the schemas we reference should be provided using our own definitions set down in section 7 of the schema rfc (or enhanced in the api doc, using section 7 as a base).  Frankly, I’m dreading the outcome of all this because I’ve already spent a couple of months implementing patch in its current form with over 150 unit tests to confirm it does what I think the spec requires.  But several of my peers have come to me and asked for these schema definitions (in JSON) and a couple have pointed out that the patch request schema, “ urn:ietf:params:scim:api:messages:2.0:PatchOp“, cannot be represented using section 7 rules and that we cannot do upfront validation on patch requests the way we do all other SCIM requests.  And it’s true, we cannot do an upfront validation of patch after it’s parsed the way we can all other requests.  Simple attribute validation is impossible because “value” depends on the target of “path”, and therefore “value” cannot be defined in a JSON schema using section 7 of the schema doc.
 
Even if we can’t fix patch, for whatever reason, we should provide the rest of the schemas, represented in JSON format, for both docs.
 
-mrf

From: Phil Hunt 
Sent: Thursday, February 12, 2015 12:58 PM
To: Michael Frost
Cc: [email-masked]
Subject: Re: [scim] SCIM schema IDs and JSON representation

Michael,

Phil

On Feb 12, 2015, at 12:46, Michael Frost <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

.0:ResourceType

---

From: Phil Hunt <[email-masked]>
Date: Thu, 12 Feb 2015 17:13:36 -0800

I think what you suggest causes far more confusion and complication rather than consistency.

Yes, both SCIM protocol messages (URIs starting urn:ietf:params:scim:api:messages:2.0:<type>) and resources carry schema URIs.  They are intended to signal to a parser what to expect.

The schemas endpoint you reference in 8.7 is solely to do with the “data” model and thus only applies to the core schema.  API messages are not persisted and thus things like mutability and return ability do not make sense.

Finally I would be careful about compliance testing suggesting that a server 100% matches section 8.7. Sec 8.7 is an example set of schema for SCIM core resources. It would be quite reasonable for individual servers to change specific settings like mutability, returned, uniqueness etc.  For compliance, what matters is that the server conforms/enforces the configuration reported by the /Schemas endpoint.

Phil

@independentid
www.independentid.com
[email-masked]

> On Feb 12, 2015, at 4:44 PM, Michael Frost <[email-masked]> wrote:
> 
> Hi Phil,
>  
> On Feb 12, 2015, at 12:46, Michael Frost <[email-masked] <mailto:[email-masked]>> wrote:
> 
> .0:ResourceType

---

From: Kelly Grizzle <[email-masked]>
Date: Fri, 13 Feb 2015 14:55:42 +0000

Michael … let me make sure I understand what you are looking for.  You would like a schema representation (such as what is included in section 8.7) for all resources and messages.  Is that right?

If so, then I 100% agree that this is useful.  In the SCIM 1.0 spec (back when we supported XML as a data format) there was an XSD that did exactly what you are looking for – described both resources and messages.  I agree that having this codifies the rules and removes some ambiguity.  I would be in favor of adding something like this to the SCIM spec.

Regarding the PatchOp, is the problem that the value sub-attribute could be anything – multivalued could be true or false, there may or may not be sub-attributes (ie – it could be complex, which is not technically supported), and the type is dependent upon the actual attribute that you are replacing?  With this ambiguity there isn’t a good way to represent this in a schema currently.

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Michael Frost
Sent: Thursday, February 12, 2015 6:45 PM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [scim] SCIM schema IDs and JSON representation

Hi Phil,

-mrf

From: Phil Hunt
Sent: Thursday, February 12, 2015 12:58 PM
To: Michael Frost
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] SCIM schema IDs and JSON representation

Michael,

Phil

On Feb 12, 2015, at 12:46, Michael Frost <[email-masked]<mailto:[email-masked]>> wrote:

.0:ResourceType

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Feb 2015 11:00:53 -0800

Kelly,

Just a minor correction. There was never any schema for the REST API in SCIM 1.

The addition of schemas for request/response messages came about because of IANA mime-type registration and it gives the ability to pass SCIM messages independently of HTTP. Using “schemas” for both messages and data made the registry much simpler to define. But the way they are used are vastly different.

Finally, the Schemas endpoint that we expose is not a schema in the sense of XSDs. It does not describe JSON “schema". It describes server behaviours around schemas. For example, is an attribute returnable, what’s its mutability.   This is nothing like an XSD.

Phil

@independentid
www.independentid.com
[email-masked]

> On Feb 13, 2015, at 6:55 AM, Kelly Grizzle <[email-masked]> wrote:
> 
> Cc: [email-masked] <mailto:[email-masked]>

---

From: Kelly Grizzle <[email-masked]>
Date: Fri, 13 Feb 2015 19:50:53 +0000

> Just a minor correction. There was never any schema for the REST API in SCIM 1.

Ah … I see what you’re saying.  You’re right – there was not a URN for any of our REST API elements.  I was more referring to the XSD that outlined the REST API elements along with the core resources (ie – this guy - https://scim.googlecode.com/svn/trunk/website/specs/schema/scim-core.xsd).

> This is nothing like an XSD.

I disagree with this somewhat.  Granted, the schema representation does express rules that the server expects (mutability, etc…).  However, it also provides similar information that an XSD provides around what data elements are supported (attribute and sub-attribute names), data types, and whether it is multivalued or not.

You’re right, though … there are some things in the schema representation (eg – mutability) that don’t really make any sense when applied to API messages.  IMO, having some something codified (other than the text in the API spec) around the API messages would be helpful.  For example:

{
  "id": "urn:ietf:params:scim:api:messages:2.0:ListResponse",
  "name": "List Response",
  "attributes": [
    {
      "name" : "totalResults",
      "type" : "integer",
      "multiValued" : false,
      "description" : "...",
    },
    {
      "name" : "startIndex",
      "type" : "integer",
      "multiValued" : false,
      "description" : "...",
    },
    {
      "name" : "itemsPerPage",
      "type" : "integer",
      "multiValued" : false,
      "description" : "...",
    },
    {
      "name" : "Resources",
      "type" : "complex",
      "multiValued" : true,
      "description" : "...",
    }
  ]
}

As you mentioned, this is a bit of a hacked up version of our normal schema.  Maybe there is a better or different way to represent it?

From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, February 13, 2015 1:01 PM
To: Kelly Grizzle
Cc: Michael Frost; [email-masked]
Subject: Re: [scim] SCIM schema IDs and JSON representation

Kelly,

Phil

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

On Feb 13, 2015, at 6:55 AM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:

--Kelly

Hi Phil,

-mrf

From: Phil Hunt

Michael,

Phil

.0:ResourceType

---

From: Michael Frost <[email-masked]>
Date: Fri, 13 Feb 2015 12:29:12 -0800 (PST)

Yes Kelly, you are correct.  I was looking for schema representation for all resources and messages.  You also correctly identified the issue I was trying to raise with regards to PatchOp.  Thanks for taking a look.

-mrf

From: Kelly Grizzle [mailto:[email-masked]] 
Sent: Friday, February 13, 2015 6:56 AM
To: Michael Frost; Phil Hunt
Cc: [email-masked]
Subject: Re: [scim] SCIM schema IDs and JSON representation

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Michael Frost
Sent: Thursday, February 12, 2015 6:45 PM
To: Phil Hunt
Cc: HYPERLINK "mailto:[email-masked]"[email-masked]
Subject: Re: [scim] SCIM schema IDs and JSON representation

Hi Phil, 

 

-mrf

From: Phil Hunt 
Sent: Thursday, February 12, 2015 12:58 PM
To: Michael Frost
Cc: HYPERLINK "mailto:[email-masked]"[email-masked]
Subject: Re: [scim] SCIM schema IDs and JSON representation

Michael,

Phil

.0:ResourceType

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Feb 2015 13:08:05 -0800

With the patch operation, the contents of “value” is currently driven by the “path” attribute.  In other words in a normal JSON structure, the Patch path attribute describes the left half of a name value pair, and the “value” describes the right half.

So if “path" points to a complex attribute, then “value” MUST be a JSON object of one or more sub-attributes.  If path describes a simple attribute, than the corresponding value must be a boolean, string depending on the schema of the attribute described by “path”.

SCIM patch is based on and follows the same design as for RFC6902 (JSON Patch). The only difference is we decided to limit the number of operation types and to use filters in paths rather than array indexed access based on JSON Pointers (RFC6901).

Phil

@independentid
www.independentid.com
[email-masked]

> On Feb 13, 2015, at 12:29 PM, Michael Frost <[email-masked]> wrote:
> 
> From: scim [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Michael Frost
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Erik Wahlström neXus <[email-masked]>
Date: Tue, 24 Feb 2015 09:43:32 +0000

Hi,

I agreed that there are some inconsistency and philosophical issues present in the specifications that probably need addressing.

I think we should make differences to the Resources and messages, and we need some changes to the schema and the api drafts to make that clear.

The Resources requires fixed schemas, the messages not so much. Schemas is intended solely for the purpose of allowing a client to understand what attributes and associated metadata (readability, mutability, type, etc) is supported by a particular service provider. Disregarding on the currently used bearer.

The message don’t need to be validated according to a schema. SCIM follows the Robustness Principal (Jon Postel’s law - one of the founding principles of TCP/IP). This means that message should not need to comply with schema in order to be interpreted (within reason) by a service provider.  In practical terms, a SCIM client should never have to do a lot of work to create or search for a User. At the same time, a service provider is not obliged to accept a new User *exactly* as the client specifies. The service provider is always free to interpret and change data.

Messages is part of the API draft, and Resources and there schemas is a part of the Schema draft. We should not mix them to much and make it clear in the spec that is also the case.

I think that the Resources that we have today, Schema, ResourceTypes and ServiceProviderConfigs MUST be added to the /Schemas endpoint. We should also add Schema, ResourceTypes and ServiceProviderConfigs to the section "8.7 Schema Representation” in the schema spec.

A second important change to make it clear that messages are messages, is to remove the schema attribute on of of the messages. They where added rather late in the spec-writing process to give a notion to the service provider what kind of message that’s currently sent. The intention was not to force the SP to validate the messages against a schema. I suggest that we remove the “schemas" attribute in messages and replaces it with a “msgType” that could indicate what message it is (PatchOp or ListResponse).

/ Erik

On 13 Feb 2015, at 22:08, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

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

On Feb 13, 2015, at 12:29 PM, Michael Frost <[email-masked]<mailto:[email-masked]>> wrote:

-mrf

--Kelly

Hi Phil,

-mrf

From: Phil Hunt

Michael,

Phil

.0:ResourceType

_______________________________________________
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: Phil Hunt <[email-masked]>
Date: Tue, 24 Feb 2015 10:00:34 -0800

Erik

Agreed. I think this makes sense and is a good compromise. This reflects what we discussed on our informal call last week.

Any other comments?

Phil

@independentid
www.independentid.com
[email-masked]

> On Feb 24, 2015, at 1:43 AM, Erik Wahlström neXus <[email-masked]> wrote:
> 
> Hi,
> 
>> On 13 Feb 2015, at 22:08, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
>>> On Feb 13, 2015, at 12:29 PM, Michael Frost <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> From: Kelly Grizzle [mailto:[email-masked] <mailto:[email-masked]>] 
>>> [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: Kelly Grizzle <[email-masked]>
Date: Tue, 24 Feb 2015 22:31:03 +0000

One thing that is nice about “schemas” is that it gives us a way to extend a resource (or the representation of a resource).  By moving our messages to use msgType instead of schemas, we might lose some of this flexibility.  I’m not sure that we would want it or not, but I can envision a ListResponse from a server that returns a “paging token” along with the current page number, etc…  This could potentially be put into an extension.  Just something to consider…

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, February 24, 2015 12:01 PM
To: Erik Wahlström neXus
Cc: SCIM WG
Subject: Re: [scim] PATCH and schema (was: SCIM schema IDs and JSON representation)

Erik

Any other comments?

Phil

@independentid

On Feb 24, 2015, at 1:43 AM, Erik Wahlström neXus <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

/ Erik

Phil

@independentid

-mrf

--Kelly

Hi Phil,

-mrf

From: Phil Hunt

Michael,

Phil

.0:ResourceType

---

From: Phil Hunt <[email-masked]>
Date: Tue, 24 Feb 2015 15:03:15 -0800

I believe we are ok on this. We have pretty good separation. For example List response does contain json objects that have resource specific schemas. 

E.g. The outer json object would have a msgType of ListResponse while the array of result objects each contains a resource each with its own schemas attribute. 

Phil

> On Feb 24, 2015, at 14:31, Kelly Grizzle <[email-masked]> wrote:
> 
> On 13 Feb 2015, at 22:08, Phil Hunt <[email-masked]> wrote:
>

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 24 Feb 2015 23:13:33 +0000

Right.  My thinking was more around the ListResponse itself being extended rather than the contained resource objects.  For example:

   {
     "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse", "urn:some-extension:pagination"],
     "totalResults":2,
     "Resources":[
       {
         "userName":"bjensen"
       },
       {
         "userName":"jsmith"
       }
     ],
     "urn:some-extension:pagination": {
       "pagingToken": "8982jak84j.nkd8"
     }
   }

Again … I’m not even sure if this is something that anyone would want to do or if it should be supported in this way.  I just wanted to bring it up.

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, February 24, 2015 5:03 PM
To: Kelly Grizzle
Cc: SCIM WG; Erik Wahlström neXus
Subject: Re: [scim] PATCH and schema (was: SCIM schema IDs and JSON representation)

Phil

On Feb 24, 2015, at 14:31, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
One thing that is nice about “schemas” is that it gives us a way to extend a resource (or the representation of a resource).  By moving our messages to use msgType instead of schemas, we might lose some of this flexibility.  I’m not sure that we would want it or not, but I can envision a ListResponse from a server that returns a “paging token” along with the current page number, etc…  This could potentially be put into an extension.  Just something to consider…

--Kelly

Erik

Any other comments?

Phil

@independentid

Hi,

/ Erik

Phil

@independentid

-mrf

--Kelly

Hi Phil,

-mrf

From: Phil Hunt

Michael,

Phil

.0:ResourceType

---

From: Phil Hunt <[email-masked]>
Date: Tue, 24 Feb 2015 15:52:03 -0800

Normally, I would expect that would be handled by a new extension draft and registered appropriately with IANA. I still have to research the implications on registry handling but I think this should be do-able. As with your example extension for paging, there’s nothing saying we can’t follow the same extension technique in our JSON.

If I roll your suggestion together with Erik’s proposal we would have:

  {
     "msgType":["urn:ietf:params:scim:api:messages:2.0:ListResponse", "urn:some-extension:pagination"],
     "totalResults":2,
     "Resources":[
       {
         "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User”],
          “id" : <some-id-a>,
         "userName":"bjensen"
       },
       {
         "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User”],
          “id" : <some-id-b>,
         "userName":"jsmith"
       }
     ],
     "urn:some-extension:pagination": {
       "pagingToken": "8982jak84j.nkd8"
     }
   }

Notice that inside each “Resources” array element is a resource object with its data schema reference included.  Also, since id is always returned, it would also be present.

By using “msgType”, we are clearly separating what is request or response metadata content as distinct from resource schema (which has state).

Phil

@independentid
www.independentid.com
[email-masked]

> On Feb 24, 2015, at 3:13 PM, Kelly Grizzle <[email-masked]> wrote:
> 
> On Feb 24, 2015, at 14:31, Kelly Grizzle <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: scim [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phil Hunt
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
>  
> On Feb 24, 2015, at 1:43 AM, Erik Wahlström neXus <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
>  
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
>

---

From: Erik Wahlström neXus <[email-masked]>
Date: Wed, 25 Feb 2015 07:06:04 +0000

Hi,

The API draft don’t mention extension (to the API) anywhere. I think a brand new endpoints that supports pagingToken is more in line with the specification. That also makes discover using the ServiceProviderConfig endpoint more accurate. Isn’t it better to add an extension there that announce that the server also supports other endpoints?

Like this:

{
    "schemas": [
      "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig”, urn:some-extension:pagination"
    ],
    "documentationUrl":"http://example.com/help/scim.html",
    "patch": {
      "supported":true
    },
    "bulk": {
      "supported":true,
      "maxOperations":1000,
      "maxPayloadSize":1048576
    }
     "urn:some-extension:pagination": {
       “filterWithNewTokenEndpoint": “true"
     },
    ….
    ….

And then the service provider also have support for the new /v2/UsersWithExtraBellsEndWistlesEndpoint

/ Erik

On 25 Feb 2015, at 00:52, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

  {

          “id" : <some-id-a>,

         "userName":"bjensen"
       },
       {

          “id" : <some-id-b>,

         "userName":"jsmith"
       }
     ],

Phil

@independentid

On Feb 24, 2015, at 3:13 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:

   {

Phil

--Kelly

Erik

Any other comments?

Phil

@independentid

Hi,

/ Erik

Phil

@independentid

-mrf

--Kelly

Hi Phil,

-mrf

From: Phil Hunt

Michael,

Phil

.0:ResourceType

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 25 Feb 2015 23:19:02 +0000

Both you and Phil’s suggestions make sense to me.  Just wanted to throw it out there for discussion before we go down a certain route.  My mind has been eased now. ;)

From: Erik Wahlström neXus [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 1:06 AM
To: Phil Hunt
Cc: Kelly Grizzle; SCIM WG
Subject: Re: [scim] PATCH and schema (was: SCIM schema IDs and JSON representation)

Hi,

Like this:

{
    "schemas": [

/ Erik

  {

          “id" : <some-id-a>,
         "userName":"bjensen"
       },
       {

          “id" : <some-id-b>,
         "userName":"jsmith"
       }
     ],

Phil

@independentid

   {

Phil

--Kelly

Erik

Any other comments?

Phil

@independentid

Hi,

/ Erik

Phil

@independentid

-mrf

--Kelly

Hi Phil,

-mrf

From: Phil Hunt

Michael,

Phil

.0:ResourceType

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Fri, 27 Feb 2015 02:05:23 +0000

Great discussion and sounds like we are converging.

Michael,  since you brought this question up, any thoughts?  Does this make sense to you?

Cheers,
Morteza

From: Kelly Grizzle <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 25, 2015 at 3:19 PM
To: Erik Wahlström neXus <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] PATCH and schema (was: SCIM schema IDs and JSON representation)

Hi,

Like this:

{
    "schemas": [

/ Erik

  {

          “id" : <some-id-a>,
         "userName":"bjensen"
       },
       {

          “id" : <some-id-b>,
         "userName":"jsmith"
       }
     ],

Phil

@independentid

   {

Phil

--Kelly

Erik

Any other comments?

Phil

@independentid

Hi,

/ Erik

Phil

@independentid

-mrf

--Kelly

Hi Phil,

-mrf

From: Phil Hunt

Michael,

Phil

.0:ResourceType