[OpenID] Combining Google & Yahoo user experience research

[Eric Sachs]

Nick, I may have missed it in this thread, but did you indicate which UI
options are working better then others for your users?
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 www.google.com/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).

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.

Is that closer to the style you are researching?

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.


On Tue, Oct 14, 2008 at 4:56 AM, Nate Klingenstein <ndk at internet2.edu>wrote:

> Allen,
> 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...
>
> 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.
>
> Take care,
> Nate.
>
> On 14 Oct 2008, at 06:56, Allen Tom wrote:
>
> 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.
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081014/830b29d3/attachment-0002.htm>