Dare Obasanjo points out a couple of reasons why globally federated identity system have – at least today – a very hard time breaking into the the walled silos of service providers: Facebook immediately comes to mind, but so do others like Google, Yahoo!, etc. The most important reason for *not* accepting foreign credentials is the potential risk to the business model involved.
To some degree we have seen exactly the same behavior when we were trying to convince stakeholders at sun.com to sign up for accepting OpenIDs: their most commonly voiced concern was that they would potentially loose the ability to properly evaluate account attributes (for role assignment, general user management, etc.). Add to this the need of many advertisement driven service providers to also use their account databases for target marketing, and you can immediately see the significant risk to their business model.
These issues and concerns are central to the (current) failure of general adoption of an OpenID 2.0 based attribute exchange[1]: nobody relying on advertising income will agree to outsource their attribute collection. They might be willing to accept foreign authentication mechanisms (such as e.g. OpenID 1.x or InfoCard), but is only viable when combining this with an in-house account database that links these different accounts.
Am I talking about account linking? Hmm, seems that I heard that at some place over and over again… The significant benefit that the Liberty framework offers is that it does not only focus on the technical aspects of federation, single sign-on, and attribute sharing. Instead, it also deals at least as much with the business and policy issues surrounding such deployments. And – by the way – most of these non-technical issues are already solved.
tag: identity, OpenID, Liberty Alliance, federation
[1] Assuming that the IPR issues and patent threats around OpenID AX are ever resolved. Obviously another – already proven – way to implement attribute exchanges for identity protocols is SAML.