<div dir="ltr">Nick, I may have missed it in this thread, but did you indicate which UI options are working better then others for your users?<div><br></div><div>I have only talked to a few RPs with a similar situation to your own, and the most common approach was to split the login process into two steps, where the first page asks for the identity provider (which might even be the local website), and then the user is redirected to their IDP's authentication page. However a key change was removing the password field completely from the first page, otherwise many users do mistakenly type their IDP's password there. In fact, if you go to <a href="http://www.google.com/a">www.google.com/a</a> you'll see we use that approach for our GoogleAppsForYourDomain service. The first login page can then include buttons/dropdowns/selectors for IDPs, as well as a text entry box for a user to just enter the domain name of their IDP (and try to using any other hints from the browser or browser history to suggest the IDP).</div>
<div><br></div><div>This style allows the IDP to also identify the user to the RP with an opaque identifier to avoid using any PII. And if the IDPs want to reduce phishing, then individual IDPs can deploy a second factor auth mechanism.</div>
<div><br></div><div>Is that closer to the style you are researching?</div><div><br></div><div>In terms of Google's research (and I believe Yahoo's) we were focused on sites that had specifically chosen not to implement federated login because of usability problems. I don't expect those UI guidelines to work for every website, especially for websites who have decided to deploy federated login for other reasons (like the ones you listed), and are willing to use a more complex UI. And those UI guidelines are complete overkill for a website who is willing to just use a single IDP and completely eliminate its own legacy login system.</div>
<div><br></div><div><br><div class="gmail_quote">On Tue, Oct 14, 2008 at 4:56 AM, Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">
Allen,<div><br></div><div>If your use case has now become, in its entirety, email verification, rather than federated authentication or transport of trusted attributes between domains, then I think our needs have diverged significantly. We of course handle and perform email verification daily using Shibboleth deployments, but it's a small facet of what we need to do. If that becomes what OpenID is intended solely to do in the future...</div>
<div><br></div><div>I think you'd still be interested in trusted attributes about users from other providers at some point in the future, but if not, that's a substantial difference in requirements that it's very good to reveal now.</div>
<div><br></div><div>Take care,</div><div>Nate.</div><div class="Ih2E3d"><div><br></div><div><div><div>On 14 Oct 2008, at 06:56, Allen Tom wrote:</div><br><blockquote type="cite"><p style="margin:0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font:12.0px Helvetica">I think there's a very interesting opportunity to use OpenID as a browser based email verification protocol. The emphasis is on verifying the user's email, not signing in.<span> </span></font></p>
</blockquote></div><br></div></div></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>