Recent blog updates

Shown here are only posts related to openid. You can view all posts here.

On OpenID (un)success

You must have heard about OpenID, haven't you? OpenID is an open authentication framework that allows an entity (a web site) to verify if you are the user you claim to be. The authentication happens at the site of your OpenID provider, and the process is common to all the entities that want to verify your authenticity. An entity just receives an answer to the request it issues: is the person that currently operates the web browser an owner of the identity it claims?

Simplification of development?

In this post I'll refer to the concept itself and to the name of the approach as "OpenID" (with some caps), and an identity URL will be named without any caps: "openid".

It seems like a neat concept to cover all kinds of authentication tasks. First, it conforms with the private infrastructural use as a universal login to a series of sites (like on StackExchange network, for instance). The openid is not shown to public when used like this.

You might think that requiring all users to use OpenID aids the development of a website, since it abstracts away the authentication process. It does not. Aside from authentication you most likely need authorization, and this alone makes you implement most of the authentication infrastructure at your site.

What OpenID actually makes possible is to associate automatically your activities across several sites. When you log in to one web site, it may automatically collect your information on another site, and be sure that the account found is yours. Based on the properties of the account found, it may, for example, grant you certain privileges. For instance, you get the ability to vote on all StackExchange sites if you have large enough reputation on one of them, and this association makes this without requiring anything from the user. However, even that was problematic to the developers, which are surely among the top professionals in the Web technologies.

Better user experience?

Who benefits the most from that usage is the user. Instead of making a lot of accounts in different sites they can just make one, and log in to different places, their password never being compromised due to the protocol design. However, everyone is used to the current situation, and the users rarely realize that there are benefits of that sort... well, more about it later.

Another way to employ OpenID is to provide credible authenticity information on the content in a Web 2.0 social site. The most widespread use of it is the openid of a commentator published near their comment. Personally, I think it's largely underused (I wrote about it in my previous article about OpenID), but that doesn't matter now. It is not the problem with OpenID.

You see, OpenID has been around for quite a time. I recall LiveJournal adopting OpenID as one of mechanisms to authorize comments in 2006. According to Wikipedia, OpenID 1.0 spec was released in 2005, and still hasn't changed much, nor it has gotten much traction. What's the matter?

I guess there are two reasons. Tightly coupled, these demeanors imminently appear where the technical progress comes, and poison it. These are conservatism and stupidity of the crowd.


If you read nearly any of anti-OpenID rant (like this: "OpenID is a Nightmare"), you'll inevitably notice the dependability among the primary concerns. "How come? Our business depends on something!", they say. Well, let's look at some history.

Remember the times when there was no centralized electric energy production? People just used torches to light their homes, animal labor to plough their farms, and dug underground storages to keep food in a cold environment. That was awful. You may test how this feels if you spend a weekend without electricity in the country—if you have a supply of candles, of course.

What do the opponents of OpenID as authentication systems propose? They say that dependence on externally provided utilities weakens their system, and leads to outages. But the same happens with electricity and with transportation in cities, and people eventually learned how to deal with traffic jams, lack of electricity and other such problems. And without depending on various external entities we would still read by candlelight, and our cities would have never achieved the today's scale of millions inhabitants. Wouldn't you want that for your website?

What does it require you to do? Just accept that 0.1% of the time users would use the backup password, or use your services for free (anyway, you do not reimburse subscription costs if a user is unable to access your site because of their Internet provider, do you?). I think it will make the Internet a better place by finally decoupling different services to different vendors. Time to stop the feudal division of the Net!

Stupidity of the crowd

But the conservativeness of the vendors is the minor issue here. The other imminent component of a successful acceptance is the users. And here lies the serious problem.

Users, as a massive crowd, are just stupid. They do not get it.

What should OpenID be, for the end user? It should be an open protocol that allows you to claim authenticity of your actions performed on various websites in a universal way. Is an average "end user" able to understand what it is about—or at least just read it? Hardly.

A Web search engine? Too hard: it is a concept. Now they call it "Google" even if they actually use Bing, Baidu or Yandex. For instance, I know for sure that developers in Yandex, the largest Russian Web search engine, use "google it" in their daily conversations.

A small computer which is also a phone (a.k.a. smaprtphone)? No, too hard. They buy iPhones. A PC that looks like a tray? No, too hard too, I want an iPad.

I'm glad that my Nokia n900 smartphone (or, a small PC?) is hard to confuse with an iPhone, because it resembles a brick more than an electronic device.

An open universal authentication protocol? Uh, that's soooo hard! Instead, I'll log in with my Facebook or Twitter!

See what's happening here? OpenID on its own doesn't have a chance. It did not succeed and it will never will, because it's a concept rather than a product. To make it succeed, popular web services should promote themselves as products—and use OpenID as a backend. This way web site developers wouldn't care if you log in with Facebook, Twitter or any other kind of services, they'll just attach to OpenID part of them.

On the contrary, services that call themselves "OpenID providers" (such as do a lot of harm to OpenID acceptance. They sell concepts, they sell backends to people, to whom they're unsellable. Backends should be sold to programmers, products—to people.

Facebook, Livejournal, Blogger, Telnic, Linkedin — a lot of sites store identity information, but only one of the listed serves as an OpenID provider, and, by unfortunate coincidence, outside of Russia it is mainly to host blogs of teenage girls.


"None of us is as stupid as all of us," said Joel Spolsky three years ago, but the idea had surely been there for centuries. There is too much abstraction there; OpenID is a concept, as well as a concrete protocol. The crowd doesn't want concepts, it wants products. And developers want the products to comply to concepts. Then, make all products comply to OpenID, and the Internet would be a better place. Will you?..

So, while the wide acceptance of OpenID would surely make the Internet a better place, the effort required is beyond anyone's reasonable expectation. Including mine.

Read on | Comments (0) | Make a comment >>

OpenID as a public authentication mechanism

A lot of people use OpenID as a universal login to multiple sites. In fact it's what it officially aims.

OpenID is a safe, faster, and easier way to log in to web sites.

OpenID official site

Too boring to be the best use for such a cool system. However, many people see this as its primary usage. (For example, Bill The Lizard, Stack Overflow moderator, expressed it in his edited--with abuse of moderators' powers, of course ;-)--comment here).

If the system is used as a universal login, then revealing your OpenID is not secure, since compromising it leads to very unfortunate consequences: you may lose control over a lot of services at once. So the OpenID should stay private and do its job to verify your identity amongst the other records in a database of a particular service.

Authentication via OpenID

According to Wikipedia, "authentication" is "confirming the identity of a person, tracing the origins of an artifact, ensuring that a product is what its packaging and labeling claims to be, or assuring that a computer program is a trusted one".

In more simple words, it's an act of verifying that it was you. That it was not George W. Bush, not any other guy, but only you who logged in to a particular site, and left a particular content there.

In fact, "login" is also an authentication. But it's key feature is that it's private, while sometime you might want to publicly announce yourself as an author of the content (comment, post, etc).

And this "public authentication" is quite natural with OpenID. You log in to the site that supports it; the site makes a promise to display the very same id you logged in with near your real name. Given that this promise is kept, all the content you leave is signed with your OpenID.

Note that such a mechanism is not possible with just using OpenID as a "universal login". When using it as a universal login, the OpenID stays private and is not revealed to public. But then it can't be used for verification of the user profile you have on such a site. Within this scheme you can try to "sign" your content by one of the following:

  • Add OpenID to a freetext field in your profile. Usually a profile on a social site (forum, social network etc) contains some fields (named like "userinfo") where you can put anything you want. So you could put your OpenID there to authenticate yourself. But that is not reliable, since anyone can put a link to your OpenID to his or her profile, and one can't determine if any of these profiles is true.
  • Put a link to your profile to an OpenID page. Usually OpenID providers make a promise to display a certain page if someone uses your OpenID as a web address. These pages usually also have a freetext field, into which you can enter links to the profiles on the other sites that you own. But then anyone could put a link to your profile, and it's not possible to determine who is actually correct.
  • Do both of the above. But then your login is compromised anyway.
  • Do both of the above, but secretly use another OpenID to log in. But then you don't need the original OpenID at all!

The shortcoming of "add to userinfo" approach described above is that you have to list all the places, where you left something, on your OpenID page. All comments to blogs, all profiles you own--maintaining such a list is tiresome. However, if all engines, which support OpenID, revealed them, then doing this just wouldn't be necessary.

So, having analyzed the above ways to refrain from publishing your true OpenID, I thought that OpenID should become more than just a mean for identification. It could be also used for authorization, and just displaying it would suffice.

OpenID and

This is how I use OpenID in my blog. When you comment, the engine displays the OpenID (I have made a proper warning in the description of this blog, but I think I should make it more visible). And if you trust my engine, you can trust that all the comments left here are made by the very same persons that own the OpenIDs.

Of course, the promise is not backed with anything, and I can display random OpenIDs in the comments to my blog. But I'm no villain. And anyway you have to trust your OpenID provider--so why can't you trust a blog either? :-)

Read on | Comments (2) | Make a comment >>

More posts about openid >>