[OpenID] [LIKELY_SPAM]Re: OpenID based on email addresses... Just Works!

[Peter Williams]

If you think about it, in a refined OpenID Auth spec, it would be more useful to have the RP send the user input to the OP, rather than the normalized, redirected, or delegated values.

Assuming one is in "please confirm" the id in question is "registered" with some third-party validation/naming authority, one has to (a) invoke directed identity (so user can select their id at the OP, to mitigate the correlations...) (b) ask to REPERFORM the discovery step the RP already did (c) ask OP to "do extra confirmation" process X, for id class * (where Y = rfc822 registered email boxes, for example) (d) ask OP to release either its own evaluation result ...or just proxy back the validation/naming authorities answer.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Andrew Arnott
Sent: Wednesday, October 29, 2008 7:45 AM
To: david at sixapart.com
Cc: OpenID List
Subject: [LIKELY_SPAM]Re: [OpenID] OpenID based on email addresses... Just Works!

This method does use directed identity, but as such it does not provide the email address in the openid.identity field and it would be contrary to the spec to do so.  Perhaps though you were suggesting that a future version support this?  (I would be in favor of investigating this as well).
On Wed, Oct 29, 2008 at 7:20 AM, David Recordon <drecordon at sixapart.com<mailto:drecordon at sixapart.com>> wrote:
I'm a fan of this method, basically doing the directed identity flow and passing the user input (daveman692 at yahoo.com<mailto:daveman692 at yahoo.com>) in as openid.identity in the request.

--David

On Oct 28, 2008, at 9:14 AM, Andrew Arnott wrote:

I was going through the logs of my test RP<http://nerdbank.org/RP/login.aspx> and was surprised to see what looked like the efforts of someone who didn't understand how OpenID worked.  One of the attempts included just using a Yahoo! email address.  Guess what?!  It worked.

It worked because (at least in .NET), the URL may validly include a user@ portion, as has been discussed on this list recently.  It's just quietly dropped.  That left "http://yahoo.com" as the identifier to perform discovery on, which of course worked.  To the user, the experience is nearly perfect.  They see Yahoo where they must log in, choose an identifier, and then return to the RP.  The only weirdness is that although the Claimed Identifier will always be right, if for prettiness' sake the RP were to display the user-supplied-identifier as the user originally typed it in that it might not match who actually logged into Yahoo.

For instance, I can type in yourname at yahoo.com<mailto:yourname at yahoo.com> and completely log in, even though that's not my email address.  The claimed ID is mine, and that's what really matters, but it's a little quirky (from the end user's perspective) that I can type in anyone's yahoo email address and it just works.  As a new user I may think that I managed to log in as someone else.

Again, I know why all this works based on the spec and my implementation of it; I just didn't expect that email discovery would come without at least some work (perhaps to trim off the username@ part).  So I was pleasantly surprised.

Anyway, something to think about.
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081029/f488db56/attachment-0002.htm>