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

Using Email Addresses as OpenID Identifiers

23rd Oct 2008

After a long time of having mixed feelings about it, I've recently become fond of the idea of allowing email addresses as OpenID identifiers. The EAUT project is writing a specification for mapping email addresses to HTTP URLs, which then allows Yadis and traditional OpenID service discovery to be carried out on the HTTP URL in place of the email address.

Their current approach to using this with OpenID puzzles me, however. It seems that they've put the email-to-URL mapping right at the beginning of the process, conceptually "before" OpenID, meaning that OpenID never sees the email address. It would seem far more sensible to me to put the email-to-URL mapping in the discovery phase, so the user's OpenID identifier is their email address.

This enables a nice signup experience on RPs: In the best case, the user provides an email address whose provider supports OpenID, in which case you can authenticate the user and validate his email address all in one transaction. If the email provider doesn't support OpenID, you do traditional email validation, and at the validation URL ask the user to choose a local password. When the user returns and signs in a second time, their provider might well now support OpenID in which case the "upgrade" experience from local account to OpenID account is far less clumsy, because you already know which local account belongs to the user.

For me, this optimized enrollment/upgrade flow is the main selling point for email addresses as identifiers, and is the only motivation I have to set up EAUT for my vanity domain. I think it'd be a shame to miss out on this by doing email-to-URL mapping too early and taking the OpenID protocol out of the loop. At it's core, OpenID supports any URI scheme if you can define a suitable discovery mechanism for it, as we've seen with XRI support.

Let's let OpenID do what it's good at -- verifying ownership of URIs -- and use it to fix the horrible user enrollment user experience that exists today. As a nice side-effect, we'd increase the value proposition for RP implementations, which can't be a bad thing.


  • EAUT Allows for This Already

    Martin -- very interesting post! However, using the current EAUT spec, RP's will be able to capture the email address of a user logging-in with EAUT (since the user types this into the login form at the RP). The OP already (arguably) knows the email address anyway, so using EAUT as-is gives the RP what it needs in terms of the email address.

    From a privacy perspective, using an email address as the user's *actual* OpenID merely helps advertise the user's email address to the general public when the OpenID is displayed, or used elsewhere, which might increase spam for that user. Thus, it would seem better to simply map email-address to a URL (via current EAUT), and use the resulting URL as the OpenID (you can't determine an email address from a URL alone, which maintains privacy).
    By ext_129897 at 10:50 pm on 24th Oct 2008
    • Re: EAUT Allows for This Already

      By not using the email address in the OpenID transaction you're asking the wrong question. EAUT doesn't define a reverse mapping from URL back to email address, so when you get back the positive assertion from the OP you can't infer what email address it verifies unless you hard-code the reverse mapping into your RP.

      There is of course a privacy concern with displaying the user's email address to the public. However, there's nothing to stop an RP from simply not displaying email-based identifiers. Since RPs are going to have to change anyway -- to add support for EAUT in the first place -- they can change the way they display OpenID identifiers in the process. Some have argued that even displaying HTTP-based OpenID identifiers is bad for privacy because it enables correlation. Personally, I wouldn't be sad if providers started to hide users' OpenID identifiers by default.

      By Martin Atkins at 10:58 pm on 24th Oct 2008
      • Re: EAUT Allows for This Already

        I don't think your first comment-paragraph is correct. The user will present an email address to login to a EAUT-enabled RP (e.g., the RP should capture this email address, then use EAUT to determine the URL that the email address maps to. The RP will utilize this URL as the claimed identifer, and send it along to the OP (doing regular OpenID auth). No reverse mapping is needed -- the RP has all of the information it needs.

        In a worst case, if a user EAUT-maps their email-address to the URL of their OP (i.e., OpenID Delegation), then the OpenID auth response will still return a Claimed-Identifier, thus allowing the RP to correlate the email address to the OpenID in question (be it URL, XRI, or whatever).

        I agree there's a debate about whether or not to use email-addresses as actual OpenID's (i.e., the 1st-Class vs 2nd-Class citizen debate), but can you agree that there's not much difference between our two "proprosals" when it comes to the user's login experience, and the ability of an RP to operate properly?
        By ext_129897 at 05:56 pm on 25th Oct 2008
        • Re: EAUT Allows for This Already

          This is fine as long as the RP can retain state between the initial login and the result. If the RP recieves an unsolicited positive assertion -- or, in practice, if the OP gives an assertion for the wrong identifier -- you're then out of luck. You can't figure out what email address belonged to that URL, so the only thing you can do is fail.

          By Martin Atkins at 08:54 pm on 25th Oct 2008
          • Stateless RP's?

            Your concern about an unsolicited positive assertion is valid, although I'm asking myself how/when that would ever happen (this is beyond my level of OpenID knowledge). Can you comment on that? My understanding of OpenID stateless mode is that the RP simply doesn't store associations past the current request, but that these are generally RP initiated. Am I wrong there?

            To your second point, if the RP can at least remember the email address while it's waiting for a claimed identifier, then even if the OP responds with the wrong identifier, EAUT could be used to automatically figure out if there's a correlation between the two. If that correlation fails, then it seems like the result would be the same for my version of EAUT (emails are mapped to OpenIDs) and your version (where email-addresses are OpenIDs), since the email-discovery mechanism is the same for both: EAUT.
            By ext_129897 at 01:25 am on 27th Oct 2008
            • Re: Stateless RP's?

              Right now the only common situation where an unsolicited positive assertion arises is when providers send back an assertion for a different identifer than was in the request.

              The subtle difference between EAUT-first and EAUT-in-discovery here is that in the former case there's no way to figure out what email address belongs to the URL in the unsolicited positive assertion, so you'll need to do traditional email validation on the email address the user entered. In the latter case, if the OP switches identifiers it can choose to send back an email address, and as long as discovery on that email address works out you've got a verified email address despite the unsolicited nature of the assertion.

              When I mentioned state in my message I wasn't referring to associations. What I meant was the RP remembering what email address the user entered to correlate it with the assertion later.

              By Martin Atkins at 06:06 am on 27th Oct 2008
  • Makes sense

    Martin, I agree with your suggestions that it makes sense to fold EAUT into OpenID as a discovery mechanism. However, wouldn't that come with the cost of requiring the OPs to support email addresses as well? In its current form, it seems to me that EAUT doesn't require the OP to even be aware of an email address being used to login (assuming the OP is different from the email service provider.)
    By ext_129953 at 12:23 pm on 25th Oct 2008
    • Re: Makes sense

      I would agree. I don't see why the OP needs to know that an email-address was used to login. The OP arguably already knows the email-address of the user logging in anyway, so it would seem redundant to change the spec to force OP's to do anything extra.
      By ext_129897 at 05:59 pm on 25th Oct 2008
    • Re: Makes sense

      Indeed. But in most cases the email provider doesn't support OpenID right now anyway, so they're going to have become and OP first! Even if they do already support OpenID, they'll have to add support for EAUT anyway, so it's not like supporting email addresses as identifiers is a no-op.

      (and sure, there's that centralized fall-back service right now, under my proposal that'd become little more than just a way to outsource traditional email verification. Given that it's a centralized service I don't find it all that interesting to be honest, and I have my doubts as to whether it's a good idea to throw a forth-party into the user experience rather than the RP just doing traditional email validation in this case.)

      By Martin Atkins at 08:59 pm on 25th Oct 2008
      • Re: Makes sense

        I think this is less of an issue that you're thinking it to be.

        It's really trivial to support EAUT, especially if a mapping service is used (keep in mind that there's no centralized mapping service with EAUT -- any email domain can specify any mapping service). The mapping-service option is meant really as a mechanism that domain owners can use to delegate their EAUT responsibilities to a 3rd party that's really good at doing EAUT. So in reality, there might be millions of companies/organizations acting as mapping services, or maybe thousands, or maybe just one (my guess is that the mapping service would go the route of email service providers today -- several big ones for most of us, and then smaller ones here and there, with individuals operating their own just because they can).

        I think it's plausible to imagine a world where email providers never become OP's, and merely publish a EAUT XRDS file which delegates to a EAUT mapping service (i.e, they don't really need to put a lot of effort into implement EAUT). In that world, email service providers don't need to support OpenID per se, but can still allow their users to use their email addresses as OpenID (using my version of EAUT, or yours).

        It's an interesting time...
        By ext_129897 at 12:58 am on 27th Oct 2008
        • Re: Makes sense

          Consider also that if the mailto: URLs are sent in the OpenID transaction it becomes possible to outsource the whole shebang: just have an OpenID provider that can authenticate arbitrary email addresses by initially sending them an email and subsequently using a password or other means, and then any domain can publish that provider's endpoint as its own endpoint and instantly their domain supports OpenID.

          I will concede that this only does mapping for OpenID, not for arbitrary HTTP-based services, but it does address the use-case of allowing email addresses to be used as OpenID identifiers.

          By Martin Atkins at 01:14 am on 27th Oct 2008