<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.E-mailStijl18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:924993476;
mso-list-type:hybrid;
mso-list-template-ids:-1883222300 68354063 68354073 68354075 68354063 68354073 68354075 68354063 68354073 68354075;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:18.0pt;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:54.0pt;
text-indent:-18.0pt;}
@list l1
{mso-list-id:2129883863;
mso-list-type:hybrid;
mso-list-template-ids:-764525558 68354049 68354051 68354053 68354049 68354051 68354053 68354049 68354051 68354053;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:53.4pt;
text-indent:-18.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="NL" link="blue" vlink="purple">
<div class="Section1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">Eric,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">First of all I would like to complement on the work and really addressing this issue.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">I would like to share the issues we have been working on and wonder if this passed your discussions as well:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">We also tested with different ways and are positive on the process where we just ask the RP’s username in the first step. (So only leave the
password box from your proposal). This could be e-mail or any other unique identifier.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">In the end the RP always need to make a link to the user and his federated ID within his authorization DB. This link is made during the “help
me login step (during registration)”. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">Therefore the RP will always know what second screen needs to be shown (Redirect to IDP, Show legacy password/ sms screen) By doing so the end-user
will never type in his IDP password in the legacy password box. The login process can be a 2 step process.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">Looking at the authentication market another development we see is the discussion about a 4 corner scheme within the identity space.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">This model is taken from the banking industry but should be used in every network oriented service (Like payments, postal service, fax, telephone
etc) The most important thing of this model is that besides the end-user and the RP. There will be an IDP and Acquirer role. You can find a link to a presentation on this here:
<a href="http://nl.youtube.com/watch?v=Nu3W3ECxlM8">http://nl.youtube.com/watch?v=Nu3W3ECxlM8</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">I think the main goal for the OpenID foundation should be to work on such a scheme definition.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">Kick<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">-------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">Kick Willemse<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">Manager Product Management & Developemt</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">e-mail:
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><a href="k.willemse@diginotar.nl"><span lang="EN-US" style="color:blue">k.willemse@diginotar.nl</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">weblog:
<a href="http://www.papierloos.nl/"><span style="color:blue">http://www.papierloos.nl</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">DigiNotar B.V.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">Vondellaan 8<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">1942LJ Beverwijk<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">telefoon: 0251-268888<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Van:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> general-bounces@openid.net [mailto:general-bounces@openid.net]
<b>Namens </b>Eric Sachs<br>
<b>Verzonden:</b> woensdag 24 september 2008 1:59<br>
<b>Aan:</b> max engel<br>
<b>CC:</b> OpenID List<br>
<b>Onderwerp:</b> Re: [OpenID] New OpenID Customer Research Activity - Google research on federated login<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span class="apple-style-span">>> Do you have any information on how many steps a user was usually willing to put up with?</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span class="apple-style-span">In our research document (<a href="http://sites.google.com/site/oauthgoog/UXFedLogin">http://sites.google.com/site/oauthgoog/UXFedLogin</a>) there is a section titled "Comparison Summary for Sign Up." It
compares that traditional approach with the one we are suggesting, but admits that our approach adds a third page. We had some research where there was a fourth step, and in each case we got audible sighs of annoyance from the users, and specific complaints
about the "# of steps." So 3 pages seems to be the maximum before really hurting usability. The research that Allen Tom from Yahoo showed last week also seemed to fit with that conclusion.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-style-span">However, if the site was one that required E-mail validation, then that theoretically removes some additional work the user has to do. But users seemed to be so trained on that process, that they just accepted
it as a requirement. So they did not give us "points" for removing that step which made them willing to do more work in other places. In general though, websites that require E-mail validation report that it causes an additional 15% dropoff, especially if
their E-mail messages end up in spam folders. So it may be that adding a 4th page will lose the RP fewer users then that 15% dropoff, and thus overall it would be worth it. That type of statistic would need to be measured on a live site though, as opposed
to using usability research.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-style-span">However, even if that is true, RPs would still prefer to both avoid that 15% dropoff AND avoid any additional dropoff from a 4th (or additional) pages. So if we want to convince them to support advanced features
which require more steps, such as login with a vanity URL, then we probably are going to need some live sites who can share trustworthy statistics that show this feature is worth it.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Sep 23, 2008 at 3:07 PM, max engel <<a href="mailto:max@8bitkid.com">max@8bitkid.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Do you have any information on how many steps a user was usually willing to put up with? Also, I definitely agree on the TOS injection, that is feedback we are are getting from RP's as well. It would be great to come up with some standard behaviors for
that piece.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also, I wonder if an RP would trust e-mail more if it was coming from a Portable Contacts endpoint being declared in the XRDS as opposed to just being a data field passed by the OP...<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers, Max<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sep 23, 2008, at 2:56 PM, Eric Sachs wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">>> So, in essence, this solution is geared towards RP's that mandate needing an e-mail address and don't trust an OP's assertion of ownership, thereby forcing them to only accept e-mail-based OP's.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A better way to put it might be that it is geared towards RPs who measure the # of user actions in the signup flow as the definition of success. Until we have some other good statistics to show them from live RPs, that seems to be the
primary measure that they use to grade the different options. That is why we added such a long section to our UI research which describes the specific # of steps in different scenarios. And along those lines, that is one of the reasons many of them are interested
in the idea of the IDP showing the terms of service of the RP just to reduce the # of steps further.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">>> I agree that many sites do want e-mail, but this is a data field that can be gathered after authenticating against a non-email-based OP. Also, sites that don't require e-mail address validation after initial sign-up probably can trust
an OP's claim about a user's e-mail address.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We thought so as well. But what we then learned from talking to existing websites that have experimented with federated login is that without the immediate E-mail validation by the IDP, the RP has no way to determine whether the user has
a pre-existing legacy account. So they need to both ask the user if they do (and to enter the legacy E-mail/password), as well as to send the background E-mail validation. If they don't add this step, a lot of users end up with multiple accounts and get
really confused. If they do add these steps, then our "grade" goes down.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I am hoping to find an RP for a mainstream website that is willing to try this new login box style, but to accept not only E-mail address inputs, but also OpenID domains/vanity-URLs. Then hopefully they could report the % of accounts that
use each of these 3 types, as well as the % success rate for the signup flow of each step. My personal guess is that anyone who is technical enough to type in a vanity URL will be willing to perform the extra steps for legacy account matching & E-mail address
validation. However that is only a guess.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On Tue, Sep 23, 2008 at 2:41 PM, max engel <<a href="mailto:max@8bitkid.com" target="_blank">max@8bitkid.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">So, in essence, this solution is geared towards RP's that mandate needing an e-mail address and don't trust an OP's assertion of ownership, thereby forcing them to only accept e-mail-based OP's. I agree that many sites do want e-mail,
but this is a data field that can be gathered after authenticating against a non-email-based OP. Also, sites that don't require e-mail address validation after initial sign-up probably can trust an OP's claim about a user's e-mail address.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I do have concerns about pushing RP's to adopt this sort of federated model, because it creates a hierarchy of OP's. That worries me, as does the potential fragmented user experiences between user's who use a URL-based OP and those coming
from an e-mail provider...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">_max<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Sep 23, 2008, at 1:22 PM, Eric Sachs wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">>> Now, with my "MySpace" hat on, I am biased towards URL-based identity, since our users will leverage their vanity URL as their OpenID<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica","sans-serif"">Roughly half of Google Accounts are not gmail users, so we actually share that same bias :-) The proposal in this research basically means that we would only be able to help half our users
with federated login, and that is really unfortunate.</span><o:p></o:p></p>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">>> I'd love to see RP's move towards similar design patterns like this to help users get acclimated to Federated Login, but do want to make sure that it would be extensible to non-email based OP's.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica","sans-serif"">There are certainly RPs who are not as worried about E-mail, and for those our best (but early) results have been to change this "next generation" login box to replace "Enter your E-mail
address" with "Enter your E-mail address or OpenID domain." We specifically left out the visual logo of OpenID and appended the term domain. Those changes seem to reduce the % of regular users who were confused, but did catch the attention of highly tech
savvy users who were aware of OpenID. However it still requires them to know the domain of their OpenID IDP, and so that restricts further the % of savvy users who can make use of that advanced feature. We tried a few options for leading the user to a drop
down of IDPs, but they all had surprisingly high negative impact on regular users. Another problem the live RP sites today who act as OpenID IDPs have found that after a user signs up with their site using OpenID, they then have to prompt them to find out
if they have a legacy account on that site which should be migrated. Advanced users might not mind that, but for average users every additional step in the account signup process causes a significant drop off.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica","sans-serif"">However even beyond the UI problem, the bigger problem is that most RPs are unwilling to give up on having an E-mail address for their customers, and they don't trust one OpenID IDP to
assert that a user owns an E-mail address at a different provider. If an RP of that type wants to support IDPs that are not E-mail providers, then their account signup process will require the user to both prove ownership of an OpenID URL, and then prove
ownership of an E-mail address via a second flow. If we wanted to reduce that usability problem, we could try to get E-mail providers to allow their users to publicly specify a different OpenID IDP which was their identity provider. That might be enough
for an RP like an online magazine to allow an IDP like MySpace or Google to assert the E-mail address of a school alumni E-mail address. But this is a pretty advanced use case, so while we hope it will possible to do this some day (so that we can help the
other half of our user base), we have been more focused in the near term on the simpler model around E-mail address.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal">Interesting, <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Sep 23, 2008 at 12:48 PM, max engel <<a href="mailto:max@8bitkid.com" target="_blank">max@8bitkid.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">My main concern is that the federated model doesn't support IDP's who use URL's for users. Now, with my "MySpace" hat on, I am biased towards URL-based identity, since our users will leverage their vanity URL as their OpenID, but I imagine
that blogs, etc. are all in a similar situation where we want to acclimate our users to thinking of themselves as URL's.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While EAUT is definitely a great service for IDP's that are e-mail based, designing a federated login system around "Enter your eMail Address" does worry me.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'd love to see RP's move towards similar design patterns like this to help users get acclimated to Federated Login, but do want to make sure that it would be extensible to non-email based OP's. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">_max<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sep 23, 2008, at 8:55 AM, Eric Sachs wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">>> 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. This causes a security leak for the user even if <a href="http://buy.com" target="_blank"><span style="color:#7799BB">buy.com</span></a> is
not just throwing away the value.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, we did see that in user's who came back the "second time." However the RP can detect that case, and warn the user of the mistake they are making which should also help train them in the future both on this RP, and others. The IDP
can also try to warn the user on the first identity verification step to avoid making that mistake, but that is not as a good a "trainable moment." Along these same lines, we saw that by adding icons for IDPs to a login box, the pretty sizeable % of users
immediately tried to enter their IDP E-mail/password directly into the login box. Allen Tom from Yahoo shared some data last week that showed they saw the same thing. I don't think there is a 100% perfect solution here, but the worst case is that RPs don't
support federated login at all and end users just choose to use the same login/password as their E-mail provider across lots of other sites (and our stats indicate that most sadly do).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
>> Would it not be possible to use AJAX to check the user's entered email address against the <a href="http://buy.com" target="_blank"><span style="color:#7799BB">buy.com</span></a> data base to see if they've registered and if so, hide all the options and
just show the user the login button? Or maybe replace the "Help me login" and "I have a password" options with text that says, "you are already a member of <a href="http://buy.com" target="_blank"><span style="color:#7799BB">buy.com</span></a> via your AOL
identity. All you have to do is click the login button?" I suppose that might scare some users because they would think their account doesn't have any password at all.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">This was an idea we considered and is on our list to evaluate, but we don't have any usability data on it yet. Technically there were some concerns about how well this would interact with browser auto-fill
of login box information. It would be great if a live RP tried out a model like this and reported back the results.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Sep 23, 2008 at 8:02 AM, George Fletcher <<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Some thoughts after reading through the summary (<a href="http://sites.google.com/site/oauthgoog/UXFedLogin" target="_blank">http://sites.google.com/site/oauthgoog/UXFedLogin</a>) page...<o:p></o:p></p>
<p class="MsoNormal">Fortunately, even though they are confused, nearly all users did enter their E-mail address and clicked the login button. As long as they do that, it does not matter whether they chose Yes or No in the UI, nor does it matter whether they
typed a password. Buy.com just needs to know that their domain is <a href="http://aol.com" target="_blank">
aol.com</a>, and can then redirect them to AOL to verify their identity.<o:p></o:p></p>
<p class="MsoNormal">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. This causes a security leak for the user even if
<a href="http://buy.com" target="_blank">buy.com</a> is not just throwing away the value.<br>
<br>
Would it not be possible to use AJAX to check the user's entered email address against the
<a href="http://buy.com" target="_blank">buy.com</a> data base to see if they've registered and if so, hide all the options and just show the user the login button? Or maybe replace the "Help me login" and "I have a password" options with text that says, "you
are already a member of <a href="http://buy.com" target="_blank">buy.com</a> via your AOL identity. All you have to do is click the login button?" I suppose that might scare some users because they would think their account doesn't have any password at all.<br>
<br>
Great research. It really helps to identify the problematic cases and where we need to focus UI efforts.<br>
<br>
Thanks,<br>
George<br>
<br>
<br>
Eric Sachs wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Last Week the OpenID Foundation held the first meeting of their Content Provider Advisory Committee to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites
in a larger number of market segments. The meeting included representatives from many mainstream content websites including The New York Times, BBC, AARP, Time Inc., and NPR. I attended from Google, and thought the team who pulled together the meeting did
a great job arranging it.<br>
<br>
Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.<o:p></o:p></p>
</div>
<p class="MsoNormal"><<a href="http://sites.google.com/site/oauthgoog/UXFedLogin" target="_blank">http://sites.google.com/site/oauthgoog/UXFedLogin</a>><br>
<br>
We also shared a summary <<a href="http://sites.google.com/site/oauthgoog/UXFedLogin" target="_blank">http://sites.google.com/site/oauthgoog/UXFedLogin</a>> of our usability research that explains how this helps a website add support for federated login for
some users without hurting usability for the rest of the website's user base. This research is not yet finalized, and we are still working with a bunch of companies to gather more feedback to tune this research. If you have any feedback, feel free to get
in touch with me. However more generally we hope people will continue to contribute to the user experience discussions that are happening regarding many different use cases for OpenID, and not just the one covered in this research document.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
p.s. For Google's original blog post on this research, please refer to <a href="http://google-code-updates.blogspot.com/2008/09/usability-research-on-federated-login.html" target="_blank">
http://google-code-updates.blogspot.com/2008/09/usability-research-on-federated-login.html</a><br>
<br>
Eric Sachs<br>
Product Manager, Google Security<o:p></o:p></p>
</div>
<p class="MsoNormal">------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>