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

  • 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