User-centric identity brings federation close to home

Agreements between peers can add up to an effective federation

Federation doesn’t have to be a behind-the-scenes interaction between big companies. Lately, an idea called “user-centric identity” has gained traction. It revolves around a few core principles, most notably the idea that users should be allowed to choose which identity credentials to present in response to an authentication or attribute request.

A number of user-centric identity systems are available now, and more are in the works. These range from simple, URL-based systems such as OpenID and LID (Light-Weight Identity), to such commercial offerings as Sxip and Microsoft InfoCard. Harvard’s Berkman Center, IBM, and Novell jointly announced a new user-centric system, the Higgins Project, in February.

The idea of choice appeals to most people, but what are the implications of this change?

Suppose I work for WidgetCo, which has federated its employee portal with RetireCo, a provider of 401(k) investment services. Under a standard federation scenario, I would log in to the employee portal, and when I linked out to RetireCo, WidgetCo would send a SAML token asserting my identity to RetireCo’s server. If RetireCo needed other data about me, it could request it from WidgetCo.

In this scenario, my involvement is limited to logging in and clicking the link. In fact, the only things that tie those actions to the transfer of my identity data are the policies and security of the employee portal. There’s nothing in the structure of the federation that requires my involvement; WidgetCo and RetireCo could exchange information about me anytime they wanted, and I would be none the wiser.

User-centric identity models solve this problem structurally by inserting the owner of the identity data into the transaction. In the user-centric model, when RetireCo needs identity information, the request comes to me. I then choose which credential to present, much like you choose which credit card to present when asked to pay for a purchase.

I might choose to use my WidgetCo identity, or possibly some other credential acceptable to RetireCo. I could set up defaults or rules to process the request automatically. But, in any case, I would choose who has access to my identity attributes and how that identity data is presented.

This change doesn’t just benefit the user. There are real advantages for RetireCo and for WidgetCo as well. For instance, in the classic federation scenario we imagined earlier, if WidgetCo mistakenly sends my identity attributes to RetireCo, resulting in a financial loss, WidgetCo has to accept some of the responsibility. But in the user-centric scenario, any such request has been approved by me -- significantly reducing the risk to both companies.