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

[Eric Sachs]

>> I'm reluctant to endorse an approach which assumes that the user's OpenID
Provider is also their email provider, and I'd prefer to find a solution
that does not relegate email-less OPs to be second class providers.Max and I
exchanged some E-mail earlier in this thread about some ways I have
experimented with letting "advanced" users enter an OpenID domain or OpenID
URL into the login box instead of an E-mail address.  Its is harder to get
good usability data on that, because average users cannot get through that
process, but in a lab setting almost any "advanced" user with OpenID
knowledge can get through it but still complains about the steps involved.
 I am talking to a bunch of RPs to try to find one that would experiment
with this login UI, but to also include this "advanced" option for a URL
based identifier.  I don't have any committed yet, but there are some
possibilities.

>> This approach prevents the possibility of issuing RP-specific disposable
email addresses to help prevent spam
I am not sure why this approach prevents that, however if the IDP gives out
an RP-specific E-mail, then the RP does not have an automated way to
determine if the user has a legacy account with that RP, so it will have to
perform an extra step to prompt the user and ask if they have one.  I expect
some combo IDP/E-mail providers might offer the option for RP specific
E-mails, but some RPs have definitely told us they plan to evaluate the % of
users for each RP who finish the signup process.  If the RP find that an IDP
who uses this technique has a significant additional dropoff in the signup
rate, then the RP is likely to stop using that IDP.  That won't be true of
all RPs, but the big websites are pretty sophisticated and I've heard this
comment a bunch of times.  We may all hate that fact, but we don't have a
way to force every RPs to trust specific IDPs.
One compromise I have discussed with some RPs is to establish a legal
agreement between the RP and the IDP where the RP commits to erasing the old
global E-mail address of the user if the IDP sends both the old E-mail
address and a new RP-specific E-mail address.  As a further step, the IDP
could even require the RP to digitally sign all the mail sent to that
RP-specific address with a standard like DomainKeys/SPF/etc.  That gets
pretty close to an OAuth like model for the RP to get a non-transferable
right/capability to send mail to the user.  I didn't get enough responses
yet to evaluate how likely this would be to work.

>> and also makes it problematic for the hybrid OpenID+OAuth protocol, as an
OP/SP could only provide services for users who use the OP/SP's email.
That is going to be true even in the case where the IDP is not the user's
E-mail provider, because the user likely has other OAuth enabled services
which are hosted by someone other then that IDP, such as their blog, photos,
calendar, etc.  To give a specific example, a hybrid Google IDP/SP could not
issue tokes for a user's MySpace data, and a MySpace IDP/SP could not issue
tokens for a user's Flickr data.  I think the more general point is that it
would be nice if the industry defined a way for a user to give all their
IDPs (E-mail provider, social network, blog, etc.) a list of the OAuth
enabled endpoints that they are subscribed to, and which they they are
willing for the IDP to send the RP.  That would allow a Google IDP to tell
an RP that the user's OpenSocial endpoint is at MySpace, or that the user's
photo album endpoint is at Flickr.



On Tue, Sep 23, 2008 at 8:53 PM, Allen Tom <atom at yahoo-inc.com> wrote:

>
> Eric - thanks for publishing the results of the Google OpenID usability
> study. I believe that the biggest obstacle preventing OpenID from being
> widely adopted are the usability issues which can be painfully experienced
> by anyone trying to use OpenID for the first time, and which are nicely
> documented in your usability study.
>
> I'm reluctant to endorse an approach which assumes that the user's OpenID
> Provider is also their email provider, and I'd prefer to find a solution
> that does not relegate email-less OPs to be second class providers.  The
> proposed solution also makes the email address the defacto universal
> identifier, rather than the OpenID url, making the OpenID protocol just a
> browser based email verification system.
>
> This approach prevents the possibility of issuing RP-specific disposable
> email addresses to help prevent spam, and also makes it problematic for the
> hybrid OpenID+OAuth protocol, as an OP/SP could only provide services for
> users who use the OP/SP's email.
>
>
> George Fletcher 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.
>
>
>  I also believe that presenting a username/password combo is a bad idea,
> from a security perspective. Based on our own usability studies, Yahoo users
> will type in their YahooID/Password.
>
> That being said, most newer websites allow users to sign in using their
> email address, and will reset the user's password via email. As Simon
> Willison mentions in his OpenID talks, allowing OpenID for login is
> equivalent to allowing a password to be reset via email, just with a much
> better user experience.
>
> Allen
>
>
> _______________________________________________
> 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/20080924/3893f144/attachment-0002.htm>