SCIM at IIW - Looking for Simple and Effective

I attended several sessions at IIW last week discussing the new Simple Cloud Identity Management (SCIM) proposal. Already, there have been several positive and negative blog posts on SCIM. I won't try to rehash them, but here are a list of a few:

• Martin Kuppinger, Kuppinger-Cole, April 23, SCIM – will SPML shortcomings be reinvented?
• Nishant Kaushik, Oracle, April 25, SCIMming the Surface of User Provisioning
• Dave Kearns, Network World, April 29, SCIMing the provisioning landscape
• Patrick Harding, Ping Identity, April 29, Why SCIM over SPML? Why not?
• Mark Diodati, Gartner, May 6, SCIM and the Future of Standards-Based Provisioning
• Dave Kearns, Network World, May 10, Got SCIM?

SCIM Related Links:

• Information Site
• Google Code Project Site

SCIM supports a couple of key data flows which are:

• Copy and update identities from an enterprise cloud subscriber (ECS) to a cloud service provider (CSP) based on some event based triggers [ECS to CSP].
• Copy and update identities between cloud service providers [CSP to CSP].

For a list of possible event triggers, and flow details, check out the scenarios document here.

During the discussions, there was a question about having new operations designed to differentiate between delete and disable/suspend. For workflow based systems, suspend is often more preferable to delete. It also allows an account to be easily re-enabled. One issue this question exposes is that different end-points might interpret update events differently. For example, upon receiving a "delete" event from an ECS, a CSP might simply choose to suspend an account for either practical or even legal reasons. Thus one complication might be that read-after-delete confirmation techniques might not work as expected. Or even more tricky is the idea that the cloud-vendor might still want to allow logins by the user even if the cloud application is disabled -- if only because the cloud vendor wants to be able to gracefully redirect the user back to their enterprise to request re-enabling.

On another subject, should updates be bi-directional? If SaaS applications are generating value and hence data, how much identity information will need to be synchronized in the reverse, back to the enterprise clients, and bi-directionally between CSPs? The group felt that while this wasn't out of the question, but that the current priority was definitely unidirectional. This makes sense. At present, most cases seem to focus on centralized workflow initiated events such as hiring and retiring. 

As with many of the commenters above, I can't help but think we've been here many times before. Will SCIM work as well inside the enterprise as suggested by Mark Diodati? Maybe, but I do think there are some new multi-organizational twists to the old enterprise problem. Ownership and control of data is a new challenge not present in the classic enterprise scenarios. On the subject of "lightweight", Dave Kearns wrote this morning, is it really about finding lightweight solution? Patrick Harding points out, none of this matters if it isn't adopted. Good questions. Me, I just want something simple and effective. It is the latter requirement that makes this hard.