<!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">
<small><font face="Comic Sans MS">[Please pardon me if I am spamming
the spec mailing list with general comments/issues that might have been
discussed before]<br>
<br>
It's not the problem of just making AOL users OpenId enabled, so they
can access 3rd party RPs (use <a class="moz-txt-link-freetext" href="http://www.aol.com/">http://www.aol.com/</a><loginId> or
<a class="moz-txt-link-freetext" href="http://aimpages.com/">http://aimpages.com/</a><loginId> or
<a class="moz-txt-link-freetext" href="http://journals.aol.com/">http://journals.aol.com/</a><loginId>, etc....) - as someone else
said it's a matter of educating the users (even if it takes long time
based on user's geek level - because pretty much every IDP out there
today tries to educate users about how to make sure they are not
entering their credentials at a phishing site, but it still happens). <br>
<br>
It's more of a problem with how we can accept 3rd party OpenId users at
AOL (we as an RP). Obviously for simple use cases like leaving comments
on blogs it wouldn't really matter as long as the user is identified by
someone (and someone doing rate limiting or something else to prevent
spamming - otherwise I still can't see how it reduces spam anyway) -
but when we want to take it to the next level - provide more services
to these users (photos/calendar/etc.. ) we want to limit it to only a
few IDPs whom we trust. (due to both security and business reasons). So
this is the problem we are trying to figure out how we can message the
users that we support OpenIds from certain providers (say Verisign PIP)
but not from all. Obviously we can just follow the existing model of a
free form field that says "Enter your OpenId" but most of the time we
will end up failing the users saying "we don't accept your OpenId".
Just bad user experience in our opinion. So instead we want to somehow
message the user saying these are the only IDPs we trust - whether
showing a drop down list of IDPs on the login form or something else,
we want to see a standard way of doing it so user's don't feel like
they are in an alien world from one RP to another (ofcourse keeping
aside the phishing issues). We totally agree that adding another option
to the already confusing list of account types is a bad idea. <br>
<br>
Another area where we want some more clarification (if it already
exists) or support is about how we can have a persistent handler (apart
from URI) for a given user so it would help in cases when a user's
account gets reclaimed by someone else. Instead of it being an
additional attribute that IDP can advertise as supported (which an RP
can get via the Attribute Exchange protocol), if it can be baked into
the "authentication" response, itself as a required field, it would
help in having a common way of doing a locally stored identity
discovery. If it can be generated similar to how PPID (Private Personal
Identifier) is generated dynamically by Infocard it would be a great
addition to OpenId IMO.<br>
<br>
thx<br>
=Praveen.alavilli</font></small><br>
<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:dick@sxip.com">dick@sxip.com</a> wrote:
<blockquote cite="midF22789A8-4E09-4341-9783-96EA843EA726@sxip.com"
type="cite">
<pre wrap="">On 20-Oct-06, at 12:17 PM, John Panzer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Kaliya * wrote on 10/20/2006, 11:57 AM:
</pre>
<blockquote type="cite">
<pre wrap="">I think it is a terrible idea.
1) If you put something out into the market that looks like an e-
mail it will be used like an e-mail. I have personal experience
with this.
I had a AIM handle for the Mac part of the universe <a class="moz-txt-link-abbreviated" href="mailto:kaliya@mac.com">kaliya@mac.com</a>
(it was not an e-mail address) but because it looked like one
people used it like one and I basically had to go to .mac and pay
for an account so that the wires did not cross.
</pre>
</blockquote>
<pre wrap="">This came out of the discussions we have about a smooth migration
path for our users at AOL. In our case the <a class="moz-txt-link-abbreviated" href="mailto:user@example.com">user@example.com</a>
nickname is also a resolvable email address, though it may not be
the primary mail account of the user. I'd suggest that as a best
practice, anywhere that a <a class="moz-txt-link-abbreviated" href="mailto:user@example.com">user@example.com</a> nickname is used, it
should also be a resolvable email address. And there should always
be an option to not use something that looks like an email address.
</pre>
<blockquote type="cite">
<pre wrap="">2) I think OpenID is new and needs a new way to identify folks.
And it is our job to teach people about this new way. Lots of
services give people homepages within their spaces...myspace,
AIMpages etc. so they can use those URL's if they don't have one
yet they can get one.
</pre>
</blockquote>
<pre wrap="">There's a bootstrapping problem here. It's very, very hard to
promote the use of something that requires a more complex login
flow to replace something that is very simple (albeit limited and
in its own silo). How can we cross this chasm? Our suggestion is
to support existing practice of <a class="moz-txt-link-abbreviated" href="mailto:user@example.org">user@example.org</a> in a standard way,
while being open to new practices. Once we can support both we can
gain experience and start gradually migrating people over to the
new world. At least that's my take.
</pre>
</blockquote>
<pre wrap=""><!---->
I empathize with your problem John, but I agree with Kaliya and others.
Lets take another step back and envision what the login box prompt
will say. In OpenID 1.x it was:
"Enter your OpenID"
With some text to explain what an OpenID was.
With OpenID 2.0, we have something like:
"Homesite | i-name | OpenID"
(Homesite being more user friendly then IdP)
All of these items are new things to users, and the user either has
one or does not.
If we support email addresses, then the prompt may look something
like this:
"email | Homesite | i-name | OpenID"
Now any user with an email address thinks they can type it into the
box and login. This of course is not going to be the case.
I think the most straightforward method for your users is to educate
them that AOL is now a homesite, and they can type in aol.com into
the box. This user experience then is very similar to the user typing
in aol.com into the address bar. They get sent to aol.com which will
then prompt them for <a class="moz-txt-link-abbreviated" href="mailto:user@aol.com">user@aol.com</a>.
Given that you need to educate them that they can do something new to
begin with, this seems to be the most straightforward path.
-- Dick
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@openid.net">specs@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a>
</pre>
</blockquote>
</body>
</html>