SCIM Interop Discussion

Cross-Domain Identity Management: SCIM Interop Discussion

Tuesday 3E Convener: Phil Hunt

Notes-taker(s): Phil Hunt & Prateek Mishra

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

A number of people came to hear about SCIM Interop. We discussed that an interop is being held next Month and concluding at the Cloud Identity Summit in New Orleans on Monday June 6:  https://www.cloudidentitysummit.com/en/events.html

The interop is following the format that was carried out for SCIM 1 but updated for SCIM 2.  Participants will arrange with each other to test each other’s clients and servers over the month of May and report back on their findings. 

Long term we discussed that we would like to see an organization like OpenID Foundation take on a certification process along the lines that OpenID Connect has already done.

We had some general Q&A, who is implementing, and talked about some of the new work regarding provisioning events. More about that on Wednesday.

We had some really good discussion on the issue of “soft” or “tombstone” deletes and the paradoxical issues that some service providers are mandated never to destroy data while others must destroy it.  In enterprises, there are particular problem with employees that return to work and previous authorizations are lost when new identifiers are issued or used. For more information see the proposal from Morteza Ansari at:  https://tools.ietf.org/html/draft-ansari-scim-soft-delete-00

Those that are interested in working on Soft Delete, or participating in the SCIM Interop are invited to join the SCIM mailing list and let the group know.  See: https://www.ietf.org/mailman/listinfo/scim

Notes From: Prateek Mishra

General discussion about the nature of SCIM interop - What are the expected error conditions from a SCIM request? One goal is loosely coupled relationship between the client and the server. But this means that clients don’t know exactly what the server state is. They have to be ready for changes in user attributes. They have to be ready for variations in responses returned from the server

Kelly - SCIM 1.0 testing history - hand built script to test user create/delete etc. The real challenge was that there was no way to describe required attributes, so it was difficult to communicate between client and server. So what would be a basic test set for a SCIM 2.0 server? Probably a set of use-cases that should work against all SCIM 2.0 servers. Split into sub-sets, e.g., core, implementation of advanced features such as bulk or patch. General discussion of the need for a standard identity api and how scim helps. Next steps: define some concrete use-case flows and work on them at the next IIW