Skip to content

OpenID

HOWTO: Set yourself up with an OpenID

This post is in response to this comment on my blog (because I have no idea who that is :-). Here's my suggestion on how to get the most out of your OpenID.

  1. Get yourself an identity provider.
    I recommend using a pre-existing service rather than setting up your own. You can use AOL, Verisign (PIP), MyOpenID and a whole host of others.
  2. Edit your preferred blog or home page to configure it for delegation.
  3. When you sign into web apps, use your URL, not the URL from your provider.

I'm currently using AOL as my preferred identity provider; I also have accounts with Verisign and MyOpenID. If you already have an AIM account, you can use AOL as your identity provider without having to explicitly sign up for another service (which means that you don't need to remember yet another password).

So, assuming that you're using AOL, the next thing to do is edit your home page or blog template and add a couple of lines to the <head>:

   <link rel="openid.server" 

      href="https://api.screenname.aol.com/auth/openidServer">

   <link rel="openid.delegate"

       href="http://openid.aol.com/wezfurlong">

If you're using Verisign PIP:

   <link rel="openid.server"

      href="https://pip.verisignlabs.com/server/" />

   <link rel="openid.delegate"

      href="http://wezfurlong.pip.verisignlabs.com/" />

   <meta http-equiv="X-XRDS-Location"

      content="http://pip.verisignlabs.com/user/wezfurlong/yadis" />

   <meta http-equiv="X-YADIS-Location"

      content="http://pip.verisignlabs.com/user/wezfurlong/yadis" />

And for MyOpenID:

   <link rel="openid.server"

        href="http://www.myopenid.com/server" />

   <link rel="openid.delegate"

        href="http://youraccount.myopenid.com/" />

   <meta http-equiv="X-XRDS-Location"

        content="http://www.myopenid.com/xrds?username=youraccount.myopenid.com" />

These fragments allow an OpenID consumer site (such as my blog) to discover your identity provider and your identity with that provider. They can then initiate authentication using those credentials but then retain your original URL as your identity. This is nice because your URL is more meaningful than the various identity endpoint URLs from the providers, and also nice because you can easily switch out to a different provider if it takes your fancy.

This delegation mechanism relies on the consumer being able to parse your web page to locate those elements. Sometimes you may not be able to control some of the content on your page, so it may not be successfully parsed. You can avoid that issue by explicitly sending X-XRDS-Location and X-YADIS-Location headers, either in your PHP script, or by some magic in your httpd.conf.

Another trick is to redirect to your yadis file if the client indicates that it is looking for it:

   RewriteCond %{HTTP_ACCEPT} application/xrds\\+xml

   RewriteCond %{HTTP_ACCEPT} !application/xrds\\+xml\\s*;\\s*q\\s*=\\s*0(\\.0{1,3})?\\s*(,|$)

   RewriteRule ^$ http://netevil.org/yadis.xrdf [R,L]

(I think I borrowed this from Sam Ruby, or maybe it was Simon Willison).

What's in the yadis file? You can read all about it on openidenabled.com. Here's mine:

<?xml version="1.0" encoding="UTF-8"?>

<xrds:XRDS

  xmlns:xrds="xri://$xrds"

  xmlns:openid="http://openid.net/xmlns/1.0"  

  xmlns="xri://$xrd*($v*2.0)">

  <XRD>

    <Service priority="5">

      <Type>http://openid.net/signon/1.1</Type>

      <URI>https://api.screenname.aol.com/auth/openidServer</URI>

      <openid:Delegate>http://openid.aol.com/wezfurlong</openid:Delegate>

    </Service>

    <Service priority="10">

      <Type>http://openid.net/signon/1.1</Type>

      <Type>http://openid.net/sreg/1.0</Type>

      <URI>https://pip.verisignlabs.com/server</URI>

      <openid:Delegate>http://wezfurlong.pip.verisignlabs.com/</openid:Delegate>

    </Service>

    <Service priority="20">

      <Type>http://openid.net/signon/1.0</Type>

      <Type>http://openid.net/sreg/1.0</Type>

      <URI>https://pip.verisignlabs.com/server</URI>

      <openid:Delegate>http://wezfurlong.pip.verisignlabs.com/</openid:Delegate>

    </Service>

  </XRD>

</xrds:XRDS>

This yadis file says that I prefer to use AOL (its priority value is lower than the others) and then VeriSign PIP, preferring OpenID version 1.1 over version 1.0.

If you're using only one provider, you can just use their yadis URI rather than setting up your own (that's what those http-equiv meta elements are doing in my examples above).

Jyte.com: digg crossed with social networking

http://jyte.com/: it's kinda fun: you sign in with your OpenID and make claims about things (doesn't matter what) and vote on those claims. You can also give credit to other people, join and create groups and record contacts and relationships.

Sounds pretty standard, but what I find interesting is that there are a set of APIs for querying group membership. This could potentially allow an application to restrict access to an invitation-only group defined on jyte, and then only people who are members of those groups will be allowed through.

Another interesting area is the upcoming credit API; it will be possible to query the overall credit score of an identity. I'm wondering if a high enough credit score will be acceptable as "proof enough" that a user is not a bot, and that we could then remove the captcha step for those users.

It will be interesting to see where these concepts go as the year progresses.