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

Fri Sep 26 07:31:04 UTC 2008

I agree. XRDS is the core of the digital identity framework.
The distributed information about that identity is described there.
Even Authentication is just a service there, and ideally, the claimed ID 
to be verified should be the ID wrtten in this XRDS, not something the 
AuthN service returns in 2.0 spec. (XRI version of OpenID actually works 
in this manner, I believe, but URI based OPs do not work like that, I 
suppose.)

As to the XRDS editing capability, YES. This is very important. Some of 
my OP (Linksafe, 2idi) allows this though the U/I is scarely at best. I 
wish if I could do the same for my .mac ID etc. as well.

More on this later...

=nat

George Fletcher wrote:
> For the case of exposing my preferred services via an OP, wouldn't my 
> OpenID XRDS file suffice? I always looked at the XRDS returned via 
> discovery on my OpenID as the place to put "personal service 
> discovery" information. This would allow the RP to find all of my 
> preferred services (e.g. portable contacts service) and the interact 
> with that service via OAuth to provide me additional services. Whether 
> I use the same OP at the Portable Contacts site to authenticate 
> shouldn't matter.
>
> The key here is that the OP has to allow the user to specify 
> additional services that should be exposed vis their XRDS file.  This 
> should also work for directed identity and pseudonymous identifiers, 
> as long as the OP supports XRDS discovery on the pseudonymous identifier.
>
> Thanks,
> George
>
> Eric Sachs wrote:
>> >> 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 
>> <mailto: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 <mailto:general at openid.net>
>>     http://openid.net/mailman/listinfo/general
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>   