<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">[Sorry for the strange
posting format.&nbsp; I got on the list after seeing
the emails. --George]<br>
<br>
First, I'm new to the list and don't want to resurface an old and long
debated topic.&nbsp; <br>
<br>
To me this proposal is about how to make finding the
user's IDP simpler using something the customer is already familiar
with. Therefore, the email address format in not an
identifier, but rather a way to hint to the RP both my IDP and an
identifier to use at the IDP.&nbsp; The desire being to address current user
behavior which doesn't include specifying a URI as a login mechanism.&nbsp;
I don't use URI's at Flickr, Apple, Yahoo, Google, AOL or Microsoft.&nbsp;
Trying to educate "the masses" to remember a new identifier, that for
some is meaningless (i.e. the user might not have a blog or other URL
that they are used to remembering or sharing), is difficult.<br>
<br>
As another option, the RP could present UI that has a drop down of
"common IDPs" and
then based on the selected "common IDP" provide another text entry for
that IDP's form of identifer. However, that somewhat defeats the
purpose of trying to have a very simple form entry mechanism which
customers can get used to seeing and feel comfortable with.&nbsp; It also
places a burden on the RP to keep their UI up-to-date.<br>
<br>
</font><font face="Helvetica, Arial, sans-serif">Of course, my
expectation is that this syntax would be optional; the user can always
specify their full URI identifier.</font><br>
<font face="Helvetica, Arial, sans-serif"><br>
I agree that this kind of an identifier is not portable, but I'm
guessing that most users wouldn't know how to tweak their blog to add
the necessary OpenID 1.1 HTML code to change their IDP.&nbsp; Most users,
just use flickr for photos and if flickr supported OpenID, could
potentially use some URI defined for them by flickr as an OpenID
identifier.&nbsp; This identifier from flickr would not be very easily
portable.<br>
<br>
Thanks,<br>
George<br>
<blockquote type="cite">
  <pre>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: <a href="http://openid.net/mailman/listinfo/specs">specs-bounces at openid.net</a> [mailto:<a   href="http://openid.net/mailman/listinfo/specs">specs-bounces at openid.net</a>] On Behalf
Of Recordon, David
Sent: Thursday, October 19, 2006 6:46 PM
To: <a href="http://openid.net/mailman/listinfo/specs">specs at openid.net</a>
Subject: [PROPOSAL] Handle "<a href="http://user@example.com%22">http://user@example.com"</a> 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 "<a   href="http://openid.net/mailman/listinfo/specs">user at example.com</a>" 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 <a   href="http://www.lifewiki.net/openid/ConsolidatedDelegationProposal">http://www.lifewiki.net/openid/ConsolidatedDelegationProposal</a>
proposal, in case one, openid.identity would be set to
"<a href="http://openid.net/identifier_select/2.0%22">http://openid.net/identifier_select/2.0"</a> and then instead of
openid.portable being empty, in this case "<a   href="http://openid.net/mailman/listinfo/specs">user at example.com</a>" 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,
<a href="http://user@example.com">http://user@example.com</a> 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</pre>
</blockquote>
</font>
</body>
</html>