[PROPOSAL] Handle "http://user at example.com" Style Identifiers

David Fuelling sappenin at gmail.com
Wed Nov 8 18:25:42 UTC 2006


Hi All,

Sorry to re-open this can of worms, but I'm just getting a chance to chime
in.  I actually think David Recordan's idea re: email address to URL
resolution would be a great idea!  

My vote would also be to allow an Email address to map to an Identity
Provider URL.  **** NOTE:  The email address does not map to a Claimed
Identity nor to a Verified Identity **** (This is key!) 

Assuming I'm reading David R's proposal correctly, I think the only
difference between the two proposals is that in mine, the IdP doesn't need
to know what email address was entered (remember, the email is NOT the
identity -- it's just a mapping).

Here it is....

<proposal>

1.) User enters an email address into an RP's OpenId login box.
2.) Behind the scenes, the RP resolves the email address to an OpenId URL
via [Resolution Procedure] below.
3.) If the email address resolves to an Identity Provider URL, then the RP
continues the OpenId protocol as if the user had entered the Identity
Provider URL.
4.) If the email address does NOT resolve to an Identity Provider URL, then
the RP SHOULD display a page that says something like: "We're sorry, your
email address doesn't not yet support Open ID.  Please try a different
identifier type."  On the same page should be some verbiage to help educate
the user about what OpenID identifiers are, and possibly how email addresses
map to them.  Additionally, this could be a page to educate the user about
XRI's, and the other parts of OpenId that are appropriate.

###
[Resolution Procedure]:  An email address resolves to a valid OpenId IdP
URL, per the following procedure.

A1.) For a given email address of the form 'local-part at domain.tld' and a
corresponding domain of the form 'http(s)://domain.tld/, a RP SHOULD attempt
OpenID URL discovery (See OpenId Auth 2.0 section 7.3 - Discovery) on the
following URL's that are resolved out of the specified email address:

1.) http://<domain>.<tld>
2.) http://www.<domain>.<tld>

The above URL's MUST be resolved by replacing the <domain> and <tld> values
with corresponding values from the specified email address' 'domain' and
'tld' parameters.  In addition, resolution of the above 2 alternate URL's
should be done via a HEAD request to all of the URL's first, followed by a
GET request to all of the URL's if no URL produces a valid Yadis Resource
URL via the HEAD method.

A2.) Per the OpenId spec, if URL Discovery fails, then HTML-based discovery
should be attempted on the same URL's, in the same manner as above.

</end proposal>


SIDE NOTE: For those who argue against email addresses in the OpenId login
form on the grounds of confusion, these 2 email proposals should be no less
"confusing" than trying to educate a user that the Identity URL they type in
(e.g., http://aol.com) is not their identity.  Both will/would take some
education.

Thanks!

David Fuelling
Sappenin at gmail.com

> -----Original Message-----
> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
> Of Recordon, David
> Sent: Thursday, October 19, 2006 9:46 PM
> To: specs at openid.net
> Subject: [PROPOSAL] Handle "http://user@example.com" Style Identifiers
> 
> In meeting with a large service provider this week, an issue around end
> user usability came up.  The concern they expressed was that users are
> know how to enter usernames or email addresses to initiate the login
> process.  While directed identity allows the user to enter
> "example.com", they feel that it still is a bit of a stretch at this
> time for any major deployment of OpenID.
> 
> The proposal we came up with was within the spec describing what to do
> if someone were to enter "user at example.com" in a Relying Party's OpenID
> login form.  The idea is that the RP splits the string on the "@" and
> then treats "example.com" as the IdP Identifier.  This thus doesn't
> actually require any changes to the protocol itself.  Any Relying Party
> can do this today, but they desire to see this as part of the
> specification itself so they wouldn't be doing anything special.
> 
> Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
> proposal, in case one, openid.identity would be set to
> "http://openid.net/identifier_select/2.0" and then instead of
> openid.portable being empty, in this case "user at example.com" would be
> sent to the IdP.  While not perfectly mapping to the definition of the
> openid.portable field, it doesn't seem like that much of a hack to do
> this.
> 
> While I certainly am not looking to re-kindle the "Why a URI?" debate,
> http://user@example.com is also technically a valid URI.  It is used in
> many cases by browsers to provide a username when making a web request.
> 
> So while this is a little funky, I really think the increased usability
> offered by describing what a RP should do when a string like this is
> entered seems to outweigh the potential conceptual confusion.
> 
> Thoughts?
> 
> --David
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs




More information about the specs mailing list