There are times in the technology world where I notice something I think is big but no one else seems to be mentioning it. This in turn makes me a little nervous as I wonder if I'm crazy or if it really is a big deal. That's why I was so happy to see this post by Dan Brickley entitled "When your OpenID provider goes offline..."
My main OpenID provider is currently LiveJournal, delegated from my own danbri.org domain. I suspect it’s much more likely that danbri.org would go offline or be hacked again (sorry DreamHost) than LJ; but either could happen!
In such circumstances, what should a ‘relying party’ (aka consumer) site do? Apparently myopenid has been down today; these are not theoretical scenarios. And my danbri.org site was hacked last year, due to a DreamHost vulnerability. The bad guys merely added viagra adverts; they could easily have messed with my OpenID delegation URL instead.
In "Enterprise Speak" this is called a "single point of failure" and, as the name implies, it means a part of your system can bring everything to a halt if it fails. These are obviously to be avoided.
OpenID creates two "single point of failure" scenarios that I can see...
1. Server Goes Down: Servers go down all the time on the Internet but when that happens in today's world you only lose access to one site. In the case of OpenID every web site you visit will need the OpenID server to authenticate which means you lose access to every secure website you use if your OpenID server happens to go down. That's a pretty big penalty to pay.
2. Server Goes Away: As bad as the scenario above might be it pales in comparison to the scenario where your OpenID provider goes out of business. At that point, you're just out of luck. You've lost all access to your personal information. In fact, in the ideal scenario the whole idea of OpenID is to prevent individual sites from getting your personal info at all. So those sites will lack the ability to re-establish a link with you once your OpenID is gone (since the site doesn't have any personal info to question you about it can't verify your identity).
Mr. Brickley, being the semantic web advocate he is, suggests an automated way to fix this...
one model that strikes me as plausible: the relying party should hang onto FOAF and XFN ‘rel=me’ data that you’ve somehow confirmed (eg. those from http://danbri.org/foaf.rdf or my LJ FOAF) and simply offer to let you log in with another OpenID known to be associated with you. You might not even know in advance that these other accounts of yours offer OpenID; after all there are new services being rolled out on a regular basis.
I have to disagree with him on this. One of the things I've grudgingly accepted as a program designer is that some tasks should be left to actual people. This is one of those examples. I'm very uncomfortable with the idea of a website trying to automatically determine where I'd like to delegate authority over my information to and then choosing to delegate that authority for me.
What I'd suggest instead is that website developers be mindful of this flaw in the OpenID system and allow their users to specify an alternate OpenID account. In fact, I'd go further a say its an OpenID enabled site's responsibility to make the user aware of this flaw and strongly encourage them to get an alternate OpenID. As recent events around Yahoo have proven (aka The Microsoft Merger) even the biggest company's OpenID support can be put in jeopardy. So everyone needs to have some kind of backup.
(For the record, I don't think Microsoft will shut down Yahoo's OpenID support but its certainly possible at this point)