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

  • 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