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

Tue Sep 23 21:41:44 UTC 2008

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.

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

_max

On Sep 23, 2008, at 1:22 PM, Eric Sachs wrote:

> >> 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.
Interesting,
>
>
>
> 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/7694ccac/attachment-0002.htm>