This blog can't be viewed on LiveJournal. Instead see

OpenID with email addresses: an implementation

26th Oct 2008

I've been talking to a bunch of folks about using email addresses as identifiers, and it seems that right now there's little agreement on what the correct approach is. Some would like to make a generic mapping from email address to URL, which has the advantage that you can do anything to such an email address that you can do to the URL it maps to. However, I've also had some folks say they'd rather not have a URL for every email address, and they'd rather do something simpler with less indirection.

Since the EAUT folks are already exploring the former approach, I figured I'd have a go at the latter. A proposal I heard from a few folks is to just do Yadis discovery on the URL formed by taking the email domain and putting http:// in front of it and / after it. Hard-coding URLs always feels wrong to me; in this case, DNS feels like a much more natural place for this information. However, I acknowledge that for many people -- especially in the "vanity domain" camp where most of OpenID's early adopters are to be found -- putting stuff up on your website is easier than adding DNS records. With this in mind, I've devised a compromise. My approach, therefore, is this:

  • Take the email address and turn the at sign into a dot, so becomes Do a DNS lookup on this for discovery information (see below).
  • If no information is found, take the bare domain and do a DNS lookup on this for discovery information (again, see below).
  • If no information is found, take the bare domain and put http:// in front of it ant / behind it, giving Do Yadis discovery on this URL, looking for the service type The URL of this service is an OpenID endpoint supporting email addresses.
  • If no information is found, fail.

The other part of the debate is -- assuming for the moment that DNS will be used -- how the information will be represented in DNS. My experience with hosted DNS providers is that they tend to only allow users to create A, CNAME, MX and TXT records, so as contraversial as it is I went for simply encoding the information in a TXT record, as SPF did. The format, then, is TXT records containing key-value pairs inspired by the OpenID 2 link element values. My record looks like this: IN TXT "openid2.provider= openid2.local_id="

The parser for this stuff considers only records whose values start with the string "openid2.". I've also extended these arguments with a new setting called openid2.redirect, which is used instead of the previous two to achieve the same thing as issuing an HTTP redirect has on traditional OpenID discovery: it acts as a normalization mechanism. Notice above that I've added OpenID support to my email address using delegation, just as I did with my HTTP-based identifier. I think it's important to preserve the ability to do delegation, since I think this is one of the main reasons that OpenID saw so much uptake among early adopters. RPs aren't going to bother updating to support email addresses if none are OpenID enabled, so we once again need a simple bootstrapping mechanism to get some working identifiers out there to foster adoption.

I've added support for this into an experimental branch of Net::OpenID::Consumer. I don't have a working demo up right now, but I hope to be able to get one up soon so folks can try it out.


  • I agree


    Yup, gets my vote, I following your logic.


    By ext_41672 at 09:06 am on 27th Oct 2008
  • +1!

    Martin - good post, and I agree that it's important to keep it simple. I'm not quite sure if I agree that first transforming into is a good first step, as that will probably fail for most OpenIDs. The simplest approach is to just use perform standard OpenID 2.0 discovery on

    It would be nice to make a slight modification to the protocol to ensure that whatever string the user gave to the RP is preserved so that the OP gets it in the authentication request.

    Preserving the ability to delegate would be nice, as I would still like to be able to sign in with my personal email address (on my own domain) withut having to run my own OP.
    By ext_102622 at 11:31 pm on 5th Nov 2008