Martin Atkins (mart) wrote in apparentlymart,
Martin Atkins
mart
apparentlymart

OpenID with email addresses: an implementation

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 frank@example.com becomes frank.example.com. 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 http://example.com/. Do Yadis discovery on this URL, looking for the service type http://specs.openid.net/auth/2.0/signon/email. 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:

mart.degeneration.co.uk. IN TXT "openid2.provider=https://www.myopenid.com/server openid2.local_id=https://mart.myopenid.com/"

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.

Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments