<div dir="ltr"><span class="Apple-style-span" style="border-collapse: collapse; ">>> I'm reluctant to endorse an approach which assumes that the user's OpenID Provider is also their email provider, and I'd prefer to find a solution that does not relegate email-less OPs to be second class providers.</span><div>
<span class="Apple-style-span" style="border-collapse: collapse;">Max and I exchanged some E-mail earlier in this thread about some ways I have experimented with letting "advanced" users enter an OpenID domain or OpenID URL into the login box instead of an E-mail address. Its is harder to get good usability data on that, because average users cannot get through that process, but in a lab setting almost any "advanced" user with OpenID knowledge can get through it but still complains about the steps involved. I am talking to a bunch of RPs to try to find one that would experiment with this login UI, but to also include this "advanced" option for a URL based identifier. I don't have any committed yet, but there are some possibilities.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span><div><span class="Apple-style-span" style="border-collapse: collapse;">>> This approach prevents the possibility of issuing RP-specific disposable email addresses to help prevent spam</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">I am not sure why this approach prevents that, however if the IDP gives out an RP-specific E-mail, then the RP does not have an automated way to determine if the user has a legacy account with that RP, so it will have to perform an extra step to prompt the user and ask if they have one. I expect some combo IDP/E-mail providers might offer the option for RP specific E-mails, but some RPs have definitely told us they plan to evaluate the % of users for each RP who finish the signup process. If the RP find that an IDP who uses this technique has a significant additional dropoff in the signup rate, then the RP is likely to stop using that IDP. That won't be true of all RPs, but the big websites are pretty sophisticated and I've heard this comment a bunch of times. We may all hate that fact, but we don't have a way to force every RPs to trust specific IDPs.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">One compromise I have discussed with some RPs is to establish a legal agreement between the RP and the IDP where the RP commits to erasing the old global E-mail address of the user if the IDP sends both the old E-mail address and a new RP-specific E-mail address. As a further step, the IDP could even require the RP to digitally sign all the mail sent to that RP-specific address with a standard like DomainKeys/SPF/etc. That gets pretty close to an OAuth like model for the RP to get a non-transferable right/capability to send mail to the user. I didn't get enough responses yet to evaluate how likely this would be to work.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;">>> and also makes it problematic for the hybrid OpenID+OAuth protocol, as an OP/SP could only provide services for users who use the OP/SP's email.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;">That is going to be true even in the case where the IDP is not the user's E-mail provider, because the user likely has other OAuth enabled services which are hosted by someone other then that IDP, such as their blog, photos, calendar, etc. To give a specific example, a hybrid Google IDP/SP could not issue tokes for a user's MySpace data, and a MySpace IDP/SP could not issue tokens for a user's Flickr data. I think the more general point is that it would be nice if the industry defined a way for a user to give all their IDPs (E-mail provider, social network, blog, etc.) a list of the OAuth enabled endpoints that they are subscribed to, and which they they are willing for the IDP to send the RP. That would allow a Google IDP to tell an RP that the user's OpenSocial endpoint is at MySpace, or that the user's photo album endpoint is at Flickr.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></div><div><br></div><div><br><div class="gmail_quote">On Tue, Sep 23, 2008 at 8:53 PM, Allen Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
<br>
Eric - thanks for publishing the results of the Google OpenID usability
study. I believe that the biggest obstacle preventing OpenID from being
widely adopted are the usability issues which can be painfully
experienced by anyone trying to use OpenID for the first time, and
which are nicely documented in your usability study.<br>
<br>
I'm reluctant to endorse an approach which assumes that the user's
OpenID Provider is also their email provider, and I'd prefer to find a
solution that does not relegate email-less OPs to be second class
providers. The proposed solution also makes the email address the
defacto universal identifier, rather than the OpenID url, making the
OpenID protocol just a browser based email verification system.<br>
<br>
This approach prevents the possibility of issuing RP-specific
disposable email addresses to help prevent spam, and also makes it
problematic for the hybrid OpenID+OAuth protocol, as an OP/SP could
only provide services for users who use the OP/SP's email.<div class="Ih2E3d"><br>
<br>
<br>
George Fletcher wrote:<br>
<blockquote type="cite">
<pre>I do have a security concern with this approach in that most likely the
AOL user will enter their AOL password because of the past experience.
</pre>
</blockquote></div>
I also believe that presenting a username/password combo is a bad idea,
from a security perspective. Based on our own usability studies, Yahoo
users will type in their YahooID/Password.<br>
<br>
That being said, most newer websites allow users to sign in using their
email address, and will reset the user's password via email. As Simon
Willison mentions in his OpenID talks, allowing OpenID for login is
equivalent to allowing a password to be reset via email, just with a
much better user experience.<br>
<br>
Allen<br>
<br>
</div>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br></div></div></div>