* IBM VP explains IBM/Microsoft way to federated identity
Some time ago, in trying to get a better understanding of the differences between the IBM/Microsoft WS-Federation specification and the Liberty Alliance specification for federated identity, I read a white paper called “Federation of Identities in a Web Services World,” written jointly by IBM and Microsoft (link below).
I was struck by a paragraph that stated: “Within a federation of services, a business can get trusted information about a user from the user’s home organization (or information-providing service). The business doesn’t need to register and maintain that user’s identity, and the user is spared from having to get and remember a new login in order to interact with the business.”
In other words, all user data is stored at one site: the identity provider’s site. This seemed to contrast sharply with the Liberty scenario, which simply links accounts from multiple sites through a shared authentication (that’s simplified, I know, but it shows the difference). In fact, it seemed remarkably like the description of Microsoft’s Passport service (https://www.passport.net/), one of the “innovations” that prompted the formation of the Liberty Alliance.
That method didn’t seem like a plus for WS-Federation, so when the opportunity arose to speak to Arvind Krishna, IBM’s Vice President of Provisioning and Security Development, I wasted no time in asking him about it.
According to Krishna, while the whitepaper was correct it appears my conclusion wasn’t. He assured me that the Passport-like scenario was simply one of a number of different models – including the Liberty Alliance model – that WS-Federation supported.
He wanted to emphasize that WS-Federation was mainly about transparent access, flexibility and a loosely coupled arrangement between and among identity providers and identity consumers. The IBM/Microsoft approach to federated identity would also support:
* Pre-existing relationships, e.g., linking your accounts with an airline and a rental car agency.
* Pre-arranged relationships, e.g., an employer sets up a portal for employees to connect to financial services companies for benefits plans.
* Ad-hoc relationships, e.g., the Passport model of giving out credit card and shipping details to an online retailer at time of purchase.
That certainly sounded reasonable to me and assuaged my unease about WS-Federation.
As we talked, we realized that neither of us was comfortable with storing all of our identity data in any one place. Keeping it on the computer we mainly use means it’s not available from a different platform. But storing it all with a single identity provider, such as Passport, is fraught with privacy and identity theft issues. Having multiple accounts, with data relevant to each stored in a single account, means all sorts of drudge work keeping common data, such as addresses, phone numbers, etc., synchronized.
The beginnings of a possible solution began to take root in my mind, though. It festered for a while, but refused to get much beyond the “there might be an idea here” point. So next issue I’ll roll it out and you can all take a shot at it – why it might work or why it won’t and what needs to be done to make it a possibility. As a hint, think about banking services that most people don’t use.
