On 02/04/2008, Paul E. Jones <[EMAIL PROTECTED]> wrote:
> Folks,
> I've seen discussion here and there on the use of the e-mail address as the
> OpenID identifier.  Perhaps this one says it best:
> http://www.majordojo.com/2007/02/what-openid-needs.php
> I share many of same opinions.  If OpenID is going to be practically usable
> by the average person, we cannot require the person to remember some very
> complex identifier.  When I signed up for Yahoo's OpenID service, it
> presented me with a hideously ugly URL that looked similar to a
> base64-encoded string.  I could not begin to tell you what it was.
> Fortunately, Yahoo allowed me to define my own, friendlier name.  Still, the
> ID is not one that the average user will remember or get right.
> While the e-mail address does not have to be the one's ID, it can certainly
> serve as an alias.  Suppose, for example, that the DNS records at Yahoo
> contained the following entry:
>   yahoo.com. IN NAPTR 100 10 "U" "OpenID2"
> "^(.+)@(.*)$!https://me.yahoo.com/\1!i";
> This would allow a Relaying Party to accept an e-mail address and perform a
> simple transformation to get the "real" URL identifier.  Of course, this
> does not mean that the existing URL or XRI identifiers are invalid, nor does
> it mean that the "email address" has to be a real e-mail address.  But, this
> form would certainly be far simpler for most people to deal use.

If your aim is to let people use an email address as an identifier,
there are a few questions to answer:

1. when a user enters an email address into an RP, how is the claimed
ID derived from that input?

2. given such an input, how does the RP go about discovering the
OpenID endpoint URL and local ID for that identity?

With answers to these two questions, the remainder of the protocol
should function as is.

I'm guessing (correct me if I'm wrong) that you're suggesting that
this DNS lookup be done as part of (1).  This seems like it would
cause confusion if the user's ISP changed their DNS, since the user
would see their email address as being the real identifier: not the
URL that it maps to.

A solution that matches closer with what the user expects would be to
map "[EMAIL PROTECTED]" to a claimed ID of "mailto:[EMAIL PROTECTED]".

For (2), I'd suggest a solution that maps the email address to either
directly to an OpenID endpoint (using the claimed ID as local ID), or
to an XRDS file.  A DNS based solution seems fine here (either your
NAPTR idea, or TXT records as suggested in replies to your post).

specs mailing list

Reply via email to