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!

Qualcomm's Todd Beets on Identity Management

Todd Beets, Senior Enterprise Architect at Qualcomm is interviewed by Oracle's Hormazd Romer about Oracle Identity Management. See the video here:



Todd talks about a new phase of their identity services offering where Qualcomm can offload the responsibility of managing identity from within applications and move identity management to a shares services infrastructure -- letting developers focus on business logic!

Canada backpedals on sharing ID database with U.S. - What is the difference between sharing and copying?

The Globe and Mail posted an interesting article entitled "Canada backpedals on sharing ID database with U.S.".

Here is a great example of the differences between sharing access to information and copying information between organizations. It seems the original plan was to let the U.S. "house a database of personal information about Canadians who hold special driver's licences aimed at better securing the border." Plans changed after criticism from both federal and provincial privacy commissioners.

Once in the control of the U.S., the data "could be disclosed to other organizations for any other purpose as authorized by law." While there are obviously good intentions by all parties, the problem is, that once out of the control of Canadian authorities, it would be difficult for them to audit how the U.S. used the data. And in the event of any problem, the multi-jurisdictional issues, would be difficult at best. Sharing entire databases requires enormous trust between governments for this to happen.

The Canadian Border Services Agency now says the data will be housed in Canada where the agency will be responsible for its security. What is the difference? Well, a couple come to mind:
1. The data remains in Canadian jurisdiction and its use subject to Canadian law.
2. The CBSA is now in a position to audit each use of the data by the U.S.

In this scenario, the CBSA is acting as an "authoritative" data source. By collecting and retaining the information, it is appropriate that the authority maintain control over the data's use as it has the responsibility for loss, breaches in security, and most importantly the quality of that data.

The sad thing, is that proposals to share CDs of databases are nothing new. I seem to recall an incident in the UK not too long ago.

Because of this issue alone, it is my personal belief that federated identity systems are going to become critical to improving personal privacy down the road. To date, the focus of federated system deployments has been on single-sign-on approaches linking different sites that each hold permanent copies of our personal information. But as federation technologies become more widely deployed, they can and should be used to share identity information, on-demand, where the transfer can be secured with user consent, and where request for information can be audited.

Copy and Sync Bad for Privacy

I read an article by Rosie Lombardi in InterGovWorld that turned out not to be what I thought it was about on first reading the title "Secret identity: Solving the privacy puzzle in a federated model".

The article turned out to be a discussion not of classic web federation, but one of different approaches to using LDAP in a federated government setting. In the article, Rosie lays out the case for the copy-and-sync meta-directory approach, vs. the case for dynamic access via virtual directories. While the article was not about classic web federation using SAML or InfoCards, the article makes for a very interesting case study in federation, because the author is talking about two very different approaches using the same protocol.

Note: for those that don't know, I came to Oracle as the head of development for OctetString--a virtual directory vendor. I am obviously biased, but I hope you will see my observations are much more general than just about LDAP.

As I read the case for copy-and-sync, another article came to mind from Robin Wilton at Sun. He writes about the recent HMRC security breach in the UK where government entities were copying citizen data between departments and in the process lost one of the copies. As it turned out, their approach of copying information created huge exposure for the UK Government.

Any time entire data sets are being copied eyebrows should be raising. Instead of minimizing information usage, information was being propagated. Control was being distributed, enabling the possibility of mistakes as more systems and hands have access to valuable personal information. In fact, the people with the least control are usually the persons identified within the data -- the persons whose privacy should be protected!

On the other hand, Rosie makes a good case that when you take the minimal approach of federating information on the fly (such as with Virtual Directory), your security may be minimized to the lowest level security provider of the federation. In response, I would contend that bad data is still bad data whether it is obtained through copy-and-sync or through dynamic querying. The fault lies not with the approach but with the data itself. The protocol and approach matters little at this point, bad data is always bad data.

The positive news is that obtaining data dynamically from a provider of personal information means that data is the most current available and not dependent the frequency of the last update. Control is maintained by the information provider and each usage is auditable. Consent is also more easily verified as it is possible to check each specific use of information and whether consent is needed and obtained.

Whether the protocol used for federation was LDAP, SAML, or WS-Trust, the issues remain the same. Those building federated applications need to be able to trust their providers. They have to be able to assess the quality of their sources. There are no easy answers right now. Just as with PKI trust in the past, trusting information transferred comes down to assessing the quality of information and procedures and the quality and stability of the physical infrastructures. Liberty Alliance has launched a new initiative called the Identity Assurance Framework (IAF) where they hope to begin to solve this problem. Check it out.