Pulling For Change

This past spring, several organizations began a discussion on the SAML TC about the possibility of adding subject and attribute management functions to SAML. The proposal was the subject of a some debate. Why was this an important requirement? Why not use SPML or other protocols? After considering several possibilities, a new concept emerged called "Change Notify" which suggests converting identity management operations from state-based explicit adds/modifies/deletes to pull based operations that could enable identity changes to be exchanged between partners in federated scenarios.

Before we talk about the new proposal, let's cover some of the discussion about why the state-basedm, push solutions wouldn't work.

Yes, Updates Happen

There was agreement that there are lots of scenarios where updates of some kind are needed. A web retailer, after completing a sales process with a user, might want to have some method to update a shipping address at a customer's IDP after the user indicated the address was out-of-date. An Identity Provider might want to notify relying parties with retained data of important changes. An enterprise might want to notify a cloud service provider that the employee has changed roles or has been retired.

Some of you may be asking, but why is this an issue? Shouldn't applications avoid retaining data from Identity Providers? There is often a need for some data to be retained. Applications may need to retain data because of complexity with other integrated systems. It might be needed for offline processing (where backend calls to the identity provider aren't practical or possible). Consider that business applications often generate application specific data that is tied to individuals (purchase history, reputation, to name a few) and is not associate with data originating at an identity provider. Because of this, even in a so-called "zero data" scenario where applications retain no federated data about users, there is still one key update that cloud applications often need: the de-provisioning update. How does an enterprise, acting as an Identity Provider, notify a web service provider that an employee has retired?

Why Traditional IDM Protocols Won't Work

We realized that traditional "push" approaches of adds/modifies/deletes would probably not function well because traditional enterprise approaches assume an updater has full knowledge of the target identity to be updated. Yet, by design, federated systems work at arms reach. Identity Providers have many relying parties and thus support many federated relationships.

Conversely a service provider can have many organizations, each with their own identity provider as clients. Or, even more complex, individuals may have a relationship with a service provider having nothing to do with their employer. Cell phones come to mind as an industry where there is often both an employee and personal relationship with a telephone company. Because of this, the state of an personal information and relationships in a federated system are not assured, and thus they cannot be assumed to be fact. Traditional "state" based approaches will run into issues such as adds of entries that already exist, or modify operations failing because an entity no longer exists.

Are we saying that state based protocols aren't useful? Quite the contrary. State-based protocols work very well inside the enterprise environments. They can also work in some federated scenarios where there is tight agreement between business partners. But assumptions about "state" begin to break down when you consider that federated business entities are working independently of each other.

Pulling For Change

It was interesting timing that Bob Blakley, Gerry Gebel, and my colleague Nishant Kaushik blogged recently on Pull vs. Push. While our requirements were focused on how to share ongoing updates to federated entities, there seems to be some natural alignment in thinking going on. For it was a "pull" oriented solution proposed to the SAML TC in July just prior to the Catalyst conference. The Change Notify specification allows one party to notify another about a change without actually pushing raw data. Rather then "push" a transaction, the initiating party simply pushes a notification. The receiver can then simply "pull" data using a protocol of its choosing. A few important observations:

1. There is no rigid assumption of state between parties
2. The modify operation is converted into a simple "read" by the pulling entity.
3. The change notification is relatively lightweight and doesn't need to carry data values other then references to the entity being modified.
4. The technique can be applied to almost any federation protocol.
5. There is flexibility to switch protocols.

The initial Change Notify proposal can be found here.

Since publication to the SAML TC there has been some broader interest in building a lighter weight profile supporting a simple HTTP binding, REST, or JSON. While SAML adds a lot of messaging security, there is argument to be made that Change Notify can run in lighter weight implementations. These comments seem reasonable. I'm looking for your thoughts on how we can broaden this proposal in a multi-protocol way. Would people like to discuss the proposal at the next west coast IIW? Feel free to comment!