SCIM and the Microsoft Graph API

Kim Cameron recently blogged about his view on SCIM and the Microsoft Graph API. Kim explains his view as to why SCIM and the Microsoft Graph API, which is related to the WAAS (Windows Azure Active Directory), are complementary. That reminded me of two older posts in my own blog:

In 2010 I posted about an idea which Microsoft unveiled at a PDC (Professional Developers Conference) called system.identity.
Last year, after SCIM has been announced, I published some of my thoughts about SCIM.

Even while I didn’t focus explicitly on relationships in the second post but more on the management of entitlements, there is much about relationships in there implicitly. And when looking back at the concept of system.identity (which, from what I see, influenced WAAD and the Microsoft Graph API) it is also about a concept which is much more about dealing with relationships and the ability to model a more complex reality than simply access protocols via LDAP.

SCIM as of now has become widely accepted as a concept and has some likeliness not only to become a formal standard but a real one – one that is widely accepted and implemented. However it appears it will remain a narrowly focused standard (to avoid the term “limited”) which addresses a specific problem. That is fine.

The Microsoft Graph API on the other hand addresses a much broader scope, however focused (as of now) on WAAD. As Kim explains in his post, there is a need for a “multidimensional” protocol like the Graph API which allows dealing with an identity and its relationships.

Like Kim, I see both approaches as complementary, not competitive. You should be able to do what SCIM does with an approach like the Graph API (one that is standardized and supported by many vendors). But that isn’t the core target of the Graph API and the concept behind it. So for the fairly simple use cases of SCIM, SCIM appears to be the solution of choice. For many requirements around dealing with information about identities and their relationships, the Graph API (and maybe a standardized successor in the future) will do the job.

There is though, in this discussion, another point which should be considered: RESTful APIs and JSON are far easier to handle than “traditional” approaches in programming. The evolution of what we call the Open API Economy – you might have a look at Craig Burton’s blog and the KuppingerCole report on this topic written by Craig or the video from the EIC session on that topic – shows that the acceptance of such relatively simple interfaces is rapidly growing. So the need for having only one standard for everything diminishes. There is no doubt that we need standards. But standards are also limitations – LDAP is one example for a limited and limiting standard. I know too many cases where LDAP just wasn’t (and isn’t) sufficient for the business’ needs. Notably it never intended to serve many of these use cases. It was built as an expedient, worked well and then suffered as folks tried to pile on grossly inappropriate functions.

So my recommendation is not to artificially create a “battle of standards”. That isn’t of any value. Having a standardized Graph API in addition to SCIM (and maybe some other “lightweight” standards for specific use cases like a next-generation standard interface to XACML fully supporting RESTful APIs and JSON) makes much more sense to me. Even while I think that the name “Graph API” isn’t well chosen (you need to associate the term “graph” with the “graph theory” instead of the “graph” as in “diagram” or “chart” – so it’s more for the geeks), the concept makes a lot of sense. And SCIM (despite my critics) also has a lot of value in itself.