On 02/04/2008, Paul E. Jones <[EMAIL PROTECTED]> wrote:
>  > A solution that matches closer with what the user expects would be to
>  > map "[EMAIL PROTECTED]" to a claimed ID of "mailto:[EMAIL PROTECTED]".
> The average user is not going to know what "mailto:"; is.

The mailto: transition would be something done internally by the RP.
The RP could (and probably should) display email addresses without the
"mailto:"; prefix to the user.

This is similar to the way RPs store persistent XRIs as the user's
claimed ID but are encouraged to display the reassignable XRI.

>  > 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).
> NAPTR queries and transformations are straight-forward.  It's just a regular
>  expression transformation from something that looks like an e-mail address
>  to the real OpenID ID.
>  But, again, I don't really care how it works. But, for the benefit of those
>  who are not so technically capable, I believe it's got to be super, super
>  trivial.  NAPTR would work extremely well, I think, and would be fast.  Any
>  OpenID OP could provide an e-mail style identifier and it would certainly be
>  a motivator for anybody providing e-mail service to also OpenID enable their
>  subscriber's e-mail addresses.

I don't think there is a need to introduce an HTTP identity URL here.
If you're going to use an email address as an identity, then use an
email address as an identity.

specs mailing list

Reply via email to