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

Recordon, David drecordon at verisign.com
Fri Oct 20 13:43:31 UTC 2006


The thing is they aren't really giving them their email address.  Rather
an identifier which looks like an email address to a user and in some
cases may also be an email address.

In terms of privacy, if it is known that the OpenID Identifier scheme is
http://example.com/username then it is trivial for a RP to change that
into an email address username at example.com even if the user never
entered that directly.

On the response from the IdP, the IdP would not assert that the user
owns user at example.com.  Rather it would perform the normal directed
identity flow returning an actual URL.  Take this format of identifier
as:
1) Format users already type
2) Easy for RP to start directed identity flow
3) Pass to IdP as a "hint" for who the user needs to authenticate as

--David 

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed at cordance.net] 
Sent: Friday, October 20, 2006 1:04 AM
To: Recordon, David; specs at openid.net
Subject: RE: [PROPOSAL] Handle "http://user@example.com" Style
Identifiers

There have been several long threads in the past about using email
addresses as OpenID identifiers. The conclusion each time has been to
avoid it. I don't remember all the arguments, but among them are:

* Privacy: the last thing many users want to give a website is their
email address.
* Reassignability: email addresses are not only reassignable, but for
some domains, they are notoriously short-lived identifiers.
* Non-portability: unless you own the top-level domain, they aren't
portable.

Food for thought...

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Recordon, David
Sent: Thursday, October 19, 2006 6: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