Ever since the release of Facebook Connect, countless blog-post have been written on the subject of identity management and "delegated sign-in" for the web.
To fans of the open version of this idea, OpenID, the release of FB Connect must have been a bit of a shock. Not only does it do exactly what OpenID was meant to do, it also adds some very useful features: Friend-lists and messaging.
This means that not only can you use your Facebook identity to log in, you bring your entire social network with you as well as a communications mechanism for actually making use of this network.
To make matter worse, it offers a very simple user-interaction model, as compared to most existing OpenID experiences.
The final insult to the injury is that, contrary to OpenID, Facebook isn't federated, meaning that only Facebook provides Facebook Connect, nobody else. You cannot manage you own identity yourself somehow, and then use Facebook Connect to get you in to other sites using that identity.
But the plot thickens: Now there is "Sign in with Twitter". This lets you use your Twitter account to log in elsewhere. Twitter of course already has friend-lists and messaging, as these are the basis with its entire service. The result is basically a direct competitor to Facebook Connect.
What is more: it is based on open standards. Just not OpenID, but a related standard called OAuth. OAuth allows you to grant a third party access to your content (to be more precise: grant access to API which can access your content at some service provider's site) without giving your password away to this third party. In that sense it is a more generic standard. "Your content" could be your identity information...
That is pretty much how Sign In With Twitter (SIWT) works. Yet OAuth isn't federated and neither therefore, is Sign In With Twitter. You need a Twitter account in order to use it, and you cannot yourself manage your identity and then use it together with SIWT to get access to sites.
It is hard not to see this as a pretty big "No" vote from Twitter to OpenID. They could easily have made your Twitter account become an OpenID (and they still could do of course), but instead they choose simplicity and brand-recognition over a totally open solution. People know whether they have a Twitter account or not. Most people however, have no clue what an OpenID is, how to get one, why it matters, etc. This is main thing Facebook Connect got right.
As Eran writes here, even most current OpenID implementations (Yahoo, Google) are already emulating this. "Sign in with a Yahoo ID" uses OpenID in the background, but it only allows you to log in using a Yahoo OpenID. Got your own? Too bad, it won't work! Whether or not it is OpenID in the background is irrelevant. It is basically their own system, just like SIWT.
The reality here is clear: OpenIDs are URLs, just like your favourite website has, and very few people grasp that concept: "How can a URL be my identity? I have a URL? Scary!". Both Google and Yahoo's OpenID implementations rely on smoke and mirrors to translate something the user knows (their Google log in credentials) to something they don't (their Google OpenID URL). Of course there is a standard for doing this, which has largely gone ignored.
Even with these patches though, OpenID by itself does not provide friend lists or a messaging system. You can argue that OAuth doesn't either, since it only gives access to an API. What that API does is different for every service provider. However, most OAuth enabled sites and those like it (Flickr being a good example), provide these features in one way or another. This is usually a large part of the reason for these sites to provide OAuth in the first place. Completely custom for each site, but available.
To a site developer, implementing 4 or 5 siloed sign-in providers, likely with the option of getting in on the user's social network and having a clear way of messaging the user sounds good. Really good even. Being "open" as in "federated", is nice but delivers little immediate value for the developer.
Messaging and friend lists in a totally generic fashion, based on top of OpenID, does not exist at this point. Some examples of the concept do, but they only work on a specific silo (Google+Plaxo anyone?). So after everything, you are still stuck with implementing different mechanisms for each silo and you still have to get past the "I'm a URL?" issue.
All these things combined make me believe that OpenID, in its current form, is going to lose this battle. There will not be a grand unifying identity mechanism for the web. Like with most standards on the web, there will be a couple of very big silos with their own "openish" solution and a whole bunch of smaller fry that will try and be compatible with all them.
That's a sad thing, but still better than where most of the web is stuck today.
