in FOAF

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.

I don’t know the OpenID 2.0 spec inside-out (to put it mildly!) but 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. For a confirmed list of ‘my’ URLs, you can poke around to see which are OpenIDs.

danbri$ curl -s http://danbri.livejournal.com/ | grep openid
<link rel=”openid.server” href=”http://www.livejournal.com/openid/server.bml” />

danbri$ curl -s http://flickr.com/photos/danbri/ | grep openid
<link rel=”openid2.provider” href=”https://open.login.yahooapis.com/openid/op/auth” />

Sites do go down. It would be good to have a slicker user experience when this happens. Given that we have formats – FOAF and XFN at least – that allow a user to be associated with multiple (possibly OpenID-capable) URLs, what would it take to have OpenID login make use of this?

Add Comment Register



  1. If your own domain does not go down, you can (should?) provide a list of OpenID servers which know you. This is done in a standard YADIS file [http://en.wikipedia.org/wiki/Yadis] that supports priorities, versioning, alternative identification protocols, etc.

  2. Ah, I guess Yadis finally makes it to the top of my reading list then! Hopefully the priorities/versioning/alternate stuff makes it worthwhile learning and publishing another file format….

  3. If it can inspire you, here is my YADIS file [http://alexandre.alapetite.net/id/yadis.xrds.xml] (for instance used to post this very comment), and I serve it using content-negotiation with an Apache’s type-map file (.var) [http://httpd.apache.org/docs/trunk/content-negotiation.html] at the root of my Web site, which looks like that (simplified, as I have also French, English, etc.):

    URI: index.html
    Content-type: text/html;qs=0.5

    URI: index.html
    Content-type: application/xhtml+xml

    URI: id/yadis.xrds.xml
    Content-type: application/xrds+xml

  4. This is why I encourage site operators to support associating multiple openids to a single account. I have two openid referrers using two different providers, using different ip spaces and domains where possible to provide a much greater level of resiliency than if I was to rely solely on one provider.

    I find it ironic that the creator of the openid specification has very poor support as an openid consumer. It treats users as second class, and there is no way to associate more than one openid with your account.