There has been quite a bit of discussion about SXIP’s recent OpenID Infocard token profile: Johnny Bufu, Peter Williams, and I had some email exchanges, Eve commented on Eric’s blog, and Dick made some comments about his view on the IPR status.
All this is great, exciting, or anything else you might want to use for describing conditions of euphoria. And I do acknowledge the work that Dick, Johnny, and Mike put into this effort. However, the big questions that are still unanswered (at least for me) is: who cares? And: are we hurting ourselves?
The Bigger Picture
If I take a look at the deployment rate of new-identity-protocol relying parties, i.e. mostly OpenID and Infocard, the picture is rather sobering: there is little activity[1] and currently also few signs that this might change. One of the interesting results of the recent OpenID project at Sun was that successful web property owners have little or no interest in outsourcing their identity system, or even only the authentication part of it (which is the only established role of OpenID or Infocards at this time).
The same kind of behavior can also be seen on a larger scale where the big application and service providers like Google, Facebook, or Yahoo! have little or no real interest in a truly federated/distributed internet-wide identity system, since it is not compatible with their respective business models[2].
So overall, it seems safe to assume that any effort directed at convincing web property owners to adopt a particular identity system is an uphill battle. Especially, if they have to invest time and money into equipping their web server with a compatible relying party.
OpenID Tokens, Anyone?
Now, what would be required to use the OpenID Infocard token profile? In addition to the entire OpenID infrastructure (OpenID Auth 2.0 et al.), you would also need a – more or less – complete Infocard infrastructure. In addition, you would need to make sure that the respective parts are tightly synchronized [3].
In addition, none of the OpenID specifications have passed extensive peer review in
an open standards process, have IPR issues plastered all over them, and
are – pretty much – all in beta (or pre-alpha) at this time.While these issues have been discussed in the past, it still seems reasonable to point out in this context.
Rolling out a complete and fully supported Infocard infrastructure is somewhat easier, since Microsoft is providing de facto reference implementations for the card selector and the relying party. Also, the IPR situation is less confusing, since the OSP covers – as far as I can see at this time – a pretty large chunk of the complete Infocard identity system.
Who cares now?
For a potential deployer, the question is now: “If I have an (almost) shrink-wrap identity called Windows CardSpace, why should I start to dabble with the deployment and replace the built-in SAML tokens with OpenID tokens?” Besides the technical difficulties, there is also the issue that an OpenID token based Infocard deployment only allow what is called “auditing mode“. Add to that, that most clients will probaby not have Infocards with the OpenID tokens installed, my initial questions come up again: who cares? And: are we hurting ourselves?
Most end-users do not care at all. In an Infocard-world, they just want to use the Windows CardSpace selector to login. If a given site does not support self-signed cards or a managed card they already have, chances are that they will simply go away.
The relying parties do not care either: most of them want to attract users to their sites. If there is a simple SSO/identity system they can deploy and buy support for, they probably will as long as it fits their business model. Many successful Liberty deployments attest to that. If it involves unreleased or unsupportable technology, potential patent disputes, or simply a lot of additional work, they will likely shy away from such a solution.
There are also no benefits to the IdPs: having to run a combined OpenID/Infocard infrastructure might attribute only to a little administrative overhead, but it does not really add a lot of additional benefits either.
Are We Hurting Ourselves?
My answer to this would be a decisive: “yes”. While the OpenID Infocard token replaces the HTTP redirect with the much more phishing resistant Infocard scheme, it will lead to some significant confusion in the marketplace. Educating customers and end-users might help to some extent, but explaining the differences between auditing and non-auditing mode is going to be very difficult. This is why Kim is rather careful about not advocating it: it breaks his own 7 laws.
At the end of the day, relying parties will have to decide what they want to do – and it seems to me that the decision for or against a particular identity system (such as Liberty, Infocard, or OpenID) will not be based on tokens, but rather on the entire package, including vendor support, reachable customers, and overall acceptance.
tag: identity, OpenID, Liberty Alliance, SSO, InfoCard
[1] Especially when comparing this with the rate of IdP rollouts for these protocols.
[2] In fact, I would argue that the interoperability debates of the 90s – WindowsNT/Active Directory, eDirectory, LDAP, etc. – were focused on the same issue of identity. At that time, it was the software suppliers fighting over identity WITHIN the enterprise, since control over the user database was the key to influence a lot of strategic decisions.
[3] To be fair, this is true for all complex interoperability scenarios.