There has been a blog post floating around recently which discusses the many pitfalls of OpenID. The article breaks the problems down into seven areas: security, privacy, trust, usability, adoption, availability and patent. There are some valid points and some not so valid points., many of these issues are simple policy issues. They can be resolved by implementation decisions by the OpenID provider. Let’s dig in a bit…

1. Security

The main problem here is that of phishing. You’re trusting that the site you’re at will faithfully send you to your OpenID provider and not some man-in-the-middle masquerading as your provider. However, as I’ve shown before, VeriSign PiP doesn’t allow referring websites to redirect to the VeriSign site in order to log you in. You already have to be logged in. So as long as users know of this behavior of the VeriSign PiP OpenID provider, they can’t be phished by phony redirects.

2. Privacy

This one breaks down to recyclying of user ids and providers being able to track every site you use your OpenID at. Also, there’s the issue of if your provider gets hacked and all your login history gets exposed. Gary Krall, the technical director of VeriSign PiP, has told me how they don’t recycle user ids for this very same reason. And there’s no reason that other providers can’t do this as well. The usage history (which I talked about here) is kind of a mixed blessing. This allows you to see if your OpenID has been compromised, but also allows your provider to track your every move when using your OpenID. Sure all this information may be in a central location, but is this really any worse than what we have now? How often do you reuse the same username and email (and maybe even password) when registering from site to site? How much information can a google search already return on your activities? And I would expect OpenID providers to take more precautions and be much more secure than some run of the mill web 2.0 website that I have an account at.

3. Trust

Here it’s the problem of trust and identity and which is required for which. This is another case where the provider could verify your real identity when issuing OpenIDs, but they simply don’t. This may be a case where people are trying to make OpenID deal with more than its designed to. OpenID is meant to facilitate you being able to prove you own an identity similar to an email verification loop. It’s not supposed to be able to prove that the identity is actually you. That would most likely require an offline action.

4. Usability

Here the claim is that using OpenID is no easier than using a password manager and that using OpenID is actually a double login since it doesn’t fill out your account information for you at each website. In this case, OpenID is more convenient because its very existence absolves the need for a password manager. And again, the OpenID provider can help provide the referring website with account information as I’ve shown before. Sure it can never completely fill out the account information for all websites it may encounter, but there’s simple no way to do this. It’s simply not possible to have every mapping of every field in your provider to every other field in every website you may encounter.

5. Adoption

Basically, there are many more OpenID providers than OpenID enabled websites. The blog post is trying to claim that if your website supports OpenID then users will just use OpenID to sign in. And since the users don’t have an account, they aren’t locked into your website and so won’t be compelled to come back. However, I have about 140 accounts in my account manager app and I consistently only go to maybe 10 or 20 of the sites. Just because I create a username and a password at a website does not compel me to go back to that website. If the site has good content and is well designed then I’ll go back. Contrary to their point, if the website supports OpenID I’d be more likely to go back to that site since I don’t have to create and manage yet another username/password pair.

6. Availability

This addresses the problem of needing your OpenID provider up and running every time you need to use your OpenID. If it goes down temporarily or permanently, you can’t log in. This is a valid point, but again if the provider does things right, this won’t be a problem.

7. Patent

Now this could get bad. There are several patent claims on OpenID which threaten its longevity. This is a problem that will play out in court (if it gets that far) and that no OpenID provider can fix.

So to sum up everything here, out of the box OpenID has several problems. However, if the OpenID provider implements it right and uses some offline methods, it can be as good or better than other authentication methods out there.