Email Addresses as OpenIDs

One of the criticisms leveled against OpenID is that it uses HTTP URLs to identify users, and that users don’t understand URLs-as-identifiers (especially those who are not very technical). User Experience research confirms this.

Email addresses, on the other hand, are widely understood to identify people. So why can’t we use email addresses as OpenIDs? The reason is that, in OpenID 2.0, the way you perform discovery on an OpenID makes it necessary for that OpenID to be an HTTP URL: discovery information is obtained either through an X-XRDS-Location HTTP header sent by the server when accessing the OpenID (which is an HTTP URL), or by parsing through the document itself that is returned when accessing the OpenID HTTP URL.

Last time I wrote about LRDD and OpenID. In LRDD, there are three ways to obtain meta-data about a URI: The first two are similar to how OpenID works today (following HTTP response headers, and parsing through documents returned by HTTP servers). The third way, however, is new: it involves fetching a host-meta document from the host identified in the URI, and then following links in that host-meta document.

At no time do we need to actually access (fetch) the URI on which we’re trying to perform discovery. This means we can now perform discovery on non-HTTP URIs, as long as those URIs clearly indicate a host. Email addresses have this property ( includes a host – – in addition to a user indicator). Note that we’re only concerned with User Discovery here – an email address identifies a user, not an identity provider.

So let’s assume that the URI we would like to perform discovery on is (syntactically speaking, this is not a URI – we’ll get to that in a moment). We can use the very same mechanism as described in my last post to perform discovery on it:

First, we extract the host from the email address, in this case, it’s Then, we fetch the host-meta for that host from, which might look like this:

<?xml version='1.0' encoding='UTF-8' ?>
<XRD xmlns=''


    <Link rel=''
          href='' />
    <Link rel='describedby'
          template='{%uri}' />

Just as before, because the RP knows it’s performing User Discovery (as opposed to Provider Discovery), it skips past the first <Link> element and uses the <URITemplate> element to find the location for the metadata for the URI it’s performing discovery on. In this case, the metadata for would be located at (I’ll explain in a moment why the “acct:” bit is there.) The XRD fetched from that location might look like this:

<?xml version='1.0' encoding='UTF-8' ?>
<XRD xmlns=''>


    <Link rel=''
          href='' />

And there we have it – we have discovered the OpenID endpoint ( for an email address! What’s so beautiful about this is that this process was identical to the User Discovery process explained earlier – email addresses just happen to be non-HTTP URIs, but LRDD-based discovery works for those just as well as it works for HTTP URIs.

There are two more things to note: One, the WebFinger proposal Eran has been writing about explains how metadata in general (i.e., not only the location of OpenID endpoints) can be discovered for email-like identifiers. So OpenID discovery for email addresses can be viewed as an application of the WebFinger protocol.

Two, I mentioned above how is not, technically speaking, a URI, but we need a URI throughout the protocol. is a URI – but it’s a URI that means “email address”. The above mechanism works for other “email-like” identifiers as well, such as XMPP (i.e., IM) or Google Wave identifiers – we don’t want to restrict OpenID discovery to email addresses. WebFinger had exactly the same problem, and came up with a new URI scheme: “acct:”.

So, to summarize, OpenID User Discovery for email addresses and other email-like identifiers might work like this:

  • The RP starts with a user identifier (either because the user typed their email address into a login form, or because the RP received an OpenID assertion about the claimed id
  • The RP fetches the host-meta for, and looks for a <URITemplate> of rel-type “describedby”.
  • The RP applies the URI to that <URITemplate>, and obtains a URL from which to fetch the meta-data for
  • The XRD obtained from that URL (which is for subject points to the OpenID endpoint.

Finally, this leads one to wonder what other kinds of identifiers might be used for OpenID? I think the answer should be “any URI on which LRDD-like discovery can be performed”. In fact, I think the next version of the OpenID spec should not concern itself with discovery at all, and just assume that some other standards (such as WebFinger or LRDD) will explain how an OpenID endpoint can be discovered for a given URI (whether that is an HTTP URI or not).

12 thoughts on “Email Addresses as OpenIDs

  1. Personal i-name (=name) do a fine job of identify users, they are supported by OpenID 2.0 and have nothing to do with HTTP URLs.

    • Without arguing about the merits of i-names “doing a fine job”, the fact is they have yet to win any real adoption, require a learning curve (which email address does not), and cost money.

      • To Eran and Dirk’s points — the idea of using email addresses is to use a format that people are ALREADY familiar with and don’t have to learn.

        If people couldn’t grok URLs are identifiers for people, I highly doubt i-names will see any greater kind of adoption of success.

        In this case, identity technology must be adapted to what people ALREADY do and ALREADY know. The form of email addresses is common, understood, and widely accepted in account flows. It makes very little sense to try to fight the tide of existing adoption.

  2. So, how do we deal with OPs that whose users’ credentials are that of email providers? Does this not put a burden on potential OPs to provide email to it’s users? Is that the price of admittance?

    • Many people think of their email addresses as their digital identity. It would be interesting to see how this changes as the MySpace/Facebook generation takes over the Web. I’ve been meaning to do a survey and ask the following question: “What would you put on your business card next to your name/phone number: (A) your email address, (B) your [Twitter/Facebook/MySpace] URL?” Then correlate this with age, social network usage, etc. Anyone want to beat me to it?

      I’ll go out on a limb and predict that today, email addresses would still dominate this question of what people see as their digital identity, but that it will change in the future. Ideally, whatever you see as your digital identity (be that your email address, MySpace page, etc.) should be usable to identify/authenticate yourself across the Web.

  3. I would absolutely agree with this method of discovery.

    Taking this a step further, we could have a TXT DNS record for the email domain to identify the openId URI. Example, would query the DNS for and receive a TXT record value of “openid://”. That would allow every provider to use a custom URI that wouldn’t interfere with existing URI’s(like

    Also, I’d put an email way before I’d ever put a social network link. I’ve had them all, but I don’t use social networks on a regular basis like I do my cell phone and email.

    The question I have now is how would we get the providers and consumers(relying parties) to adopt this method of discovery as opposed the the current URL method?

  4. I’m working on a reimplementation of OpenID that supports email address format, data sharing between identity servers and a mechanism to allow consumers to store information on the identity servers.

    Server Demo –
    Client Demo –

    I’m currently trying to write the server so that it can also provide authentication for OpenID accounts, but I’m stuck on the check_authentication request. I’m following the specs, yet it still refuses to authentication properly with consumers. If anyone could help out that would be great.

  5. I guess that the domain is good enough. I mean, the OpenID must be ‘’ or just ‘’
    Why do you need the username? If you really need it’ll come with the answer from the OpenID server, if not, you’ll get a unique id (for example md5(username)

    With this, we avoid the main objection against email address as OpenIDs, the spam.

  6. In the meantime, while OpenId libraries does not allow acct: URI’s – what would be the best way to use WebFinger to lookup the user’s preferred OpenId? I am thinking about something like this:

    1) User enters “” as his login name

    2) Server does WebFinger lookup

    3) Server scans returned XRD document and locates the user’s preferred OpenId. Let’s say “”.

    4) Server uses standard OpenId 2.0 library to verify the supplied OpenId URI.

    The problem lies in step 3: what “rel” attribute should be used to pinpoint the user’s preferred OpenId. I would suggest something like this (in lack of better proposal):

Comments are closed.