Subject: [scim] Where are arbitrary fields allowed in a SCIM resource?

From: "Moyer, Steven William" <[email-masked]>
Date: Thu, 2 Apr 2020 13:48:44 +0000

When SCIM resources are represented as JSON objects, the specification is pretty clear that arbitrary fields are allowed in the top-level JSON object but a question has come up related to arbitrary fields within complex objects.  We need additional information in the SCIM Address type and would rather embed the attributes than reference extension data.

Thanks,  Steve

---

From: Phillip Hunt <[email-masked]>
Date: Thu, 2 Apr 2020 12:01:00 -0700

Steve,

It is unfortunate, but extending sub-attributes of CMVAs is still on the grouops *wish* list and has not been addressed - its been challenging to get a new SCIM charter moving forward at the IETF.  Especially hard now with the current situation.

In practice, I suspect many just go ahead and modify the standardized objects and publish it to the schemas endpoint. In a “robust” design, you must expect that many clients or SPs may choose to ignore attributes and sub-attributes they do not care about. This kind of behaviour is throughout the spec such as with how attribute mutability is handled during a PUT operation.

With that said, there are many within IETF who are starting to argue against “robust" design.  We in the world of IDM often have to deal with schema impedance mis-matches all the time. If you ever worked on X.500 of LDAP, you know what I mean. Also, I find RESTful style’s lack of formalization opens up a number of edge cases for which SCIM has only scratched the surface. ROBUSTness (take what you understand and ignore the rest) seems to be the only pragmatic response to the informality of RESTful design. 

Hope this helps.

Cheers,

Phil Hunt
@independentid
[email-masked]

> On Apr 2, 2020, at 6:48 AM, Moyer, Steven William <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>