[OpenID] New OpenID Customer Research Activity - Google research on federated login

Tue Sep 23 20:22:45 UTC 2008

>> Now, with my "MySpace" hat on, I am biased towards URL-based identity,
since our users will leverage their vanity URL as their OpenID
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.

>> 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.

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.

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.

On Tue, Sep 23, 2008 at 12:48 PM, max engel <max at 8bitkid.com> wrote:

> 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.
> 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.
>
> 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.
>
> _max
>
> On Sep 23, 2008, at 8:55 AM, Eric Sachs wrote:
>
> >> 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 buy.com is not just throwing
> away the value.
>
> 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).
>
>
> >> Would it not be possible to use AJAX to check the user's entered email
> address against the buy.com 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 buy.com 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.
>
> 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.
>
>
> On Tue, Sep 23, 2008 at 8:02 AM, George Fletcher <gffletch at aol.com> wrote:
>
>> Some thoughts after reading through the summary (
>> http://sites.google.com/site/oauthgoog/UXFedLogin) page...
>>
>>> 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 aol.com, and can then redirect them to AOL to verify their
>>> identity.
>>>
>> 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 buy.com is not just throwing
>> away the value.
>>
>> Would it not be possible to use AJAX to check the user's entered email
>> address against the buy.com 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 buy.com 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.
>>
>> Great research. It really helps to identify the problematic cases and
>> where we need to focus UI efforts.
>>
>> Thanks,
>> George
>>
>>
>> Eric Sachs wrote:
>>
>>>  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.
>>>
>>> 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.
>>>
>>> <http://sites.google.com/site/oauthgoog/UXFedLogin>
>>>
>>> We also shared a summary <
>>> http://sites.google.com/site/oauthgoog/UXFedLogin> 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.
>>>
>>> p.s. For Google's original blog post on this research, please refer to
>>> http://google-code-updates.blogspot.com/2008/09/usability-research-on-federated-login.html
>>>
>>> Eric Sachs
>>> Product Manager, Google Security
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>
> _______________________________________________
> 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/20080923/f652f8c2/attachment-0002.htm>