Over the past couple of days I’ve come across a plethora of OpenID mentions, most notably in episode 3 of the .net magazine podcast in which the panelists discuss Microsoft’s recent announcement that they too will be supporting OpenID.
The increased hits my brain got with the OpenID keyword tweaked my interest and at around 1am last night I implemented the phpMyID identity provider on my personal website. The fact that I was able to do so with relative ease made me very happy. I began evangelizing at work today, telling people of the virtues and sheer awesomeness of OpenID. I even illustrated on my white board how you could log in to a number of different sites using the same central authentication service. Then it happened. I tried logging into claimID and it didn’t work. I tried again, and again I had an error. I’d previously managed to log in to Ma.gnolia so I went there and tried. It also failed. That got me wondering what was wrong, and so I visited my own site to see if something was wrong with the authentication service only to find that the whole site was down. My hosting service was experiencing some difficulty and as a result not only was my site unavailable, so was my OpenID identity provider!
Right then I realized that for all of it’s awesomeness and democratizing power, OpenID has one major problem. Its greatest asset, it being centrally managed, is also its greatest weakness. In the traditional login model authentication is handled at the site you wish to access. If the authentication is broken, chances are the site is down and the point is moot. But with OpenID, if your authentication provider (in my case my site) is down, then you can’t access anything–assuming adoption of OpenID really takes off.
It’s therefore imperative to OpenID’s success that there be contingency plans and services in place for this sort of thing. Secondary authentication services that you can resort to, or maybe the retaining of traditional logins in case your OpenID provider is offline for some reason. Otherwise, OpenID and Achilles’ heel may one day be synonymous.★
I’d have to say that this is the main reason I haven’t implemented OpenID yet.
I had a similar issue when I signed up with my OpenID. I tried voting in a Jyte poll and could not login because I had made an error in the sign up process. I’d hardly like entire applications to go down if my OpenID server is not working.
Login failing for Jyte is an inconvience, if I start using OpenID to login to my email that’s a major problem. So, I’m not planning on implementing anything important until there’s a better contingency plan.
There are a couple of solutions to this single point of failure. One that has been discussed on a couple of blogs recently, would be for relying parties to enable you to tie multiple OpenIDs to a single account at the given service (like Magnolia and ClaimID currently do). Of course this would require that you manually link those OpenIDs at each service, which is certainly less than idea.
The other option is to do OpenID delegation using XRDS, which allows you to specify multiple delegates in a priority order (my XRDS for example — http://willnorris.com/xrds.xml). In my case, if MyOpenID is down for whatever reason, the relying party would automatically fail over to livejournal. Of course there is still a single point of failure — the server hosting my XRDS file (but we all know that DreamHost is rock solid. *cough*).
There is a bit of discussion happening right now about how to represent the fact that multiple OpenIDs refer to the same person and should therefore be interchangeable. If this can be achieved in some kind of decentralized way, it may be possible to eliminate the single point of failure.