XAuth critiques

John Bradley john.bradley at wingaa.com
Sun Jun 13 16:59:49 UTC 2010 

xAuth is not something that OIDF should be running.

If there is a group of companies that want to set up a trust framework and crate a financial model around it that would allow a third party to run the infrastructure that might work for someone like OIX.

I however have a hard time seeing the current version of xAuth being better than each IdP running their own status indicators as some do now.

Better xAuth that allows searching by service type is where xAuth may add value,  but that comes at the cost of increasing privacy concerns and greater need to set rules for the extenders.  

It is best left for the xAuth community to sort out that value proposition independently.

John B.


On 2010-06-13, at 3:37 PM, Anthony Nadalin wrote:

> Agree opposed to OIDF running this, might even be opposed to OIX as I'm not sure it with the scope of the charter
> 
> -----Original Message-----
> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Dick Hardt
> Sent: Tuesday, June 08, 2010 1:59 PM
> To: David Recordon
> Cc: openid-specs at lists.openid.net
> Subject: Re: XAuth critiques
> 
> I am opposed to the OIDF running it. Might make sense for OIX, but I am not involved in that organization.
> 
> On 2010-06-08, at 11:31 AM, David Recordon wrote:
> 
>> I am opposed given that it's unclear how the operational costs would 
>> be covered and there is increased liability since whomever runs the 
>> domain could do something malicious with the data. At least the OpenID 
>> Foundation isn't setup to provide this sort of infrastructure today.
>> 
>> --David
>> 
>> 
>> On Tue, Jun 8, 2010 at 11:29 AM, Brian Kissel <bkissel at janrain.com> wrote:
>>> Are folks opposed to the OIDF or OIX running the domain?  Don has 
>>> suggested that in the past.  If not them, any other suggestions?
>>> 
>>> Cheers,
>>> 
>>> Brian
>>> ___________
>>> 
>>> Brian Kissel
>>> CEO - JanRain, Inc.
>>> bkissel at janrain.com
>>> Mobile: 503.342.2668 | Fax: 503.296.5502
>>> 519 SW 3rd Ave. Suite 600  Portland, OR 97204
>>> 
>>> Increase registrations, engage users, and grow your brand with RPX.  
>>> Learn more at www.rpxnow.com
>>> 
>>> 
>>> -----Original Message-----
>>> From: openid-specs-bounces at lists.openid.net
>>> [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Allen Tom
>>> Sent: Tuesday, June 08, 2010 11:24 AM
>>> To: Eran Hammer-Lahav; John Panzer
>>> Cc: openid-specs at lists.openid.net
>>> Subject: Re: XAuth critiques
>>> 
>>> I think that nearly everyone agrees that many of the UX, privacy, and 
>>> security issues that we have today with internet identity could 
>>> potentially be solved using new identity features baked into 
>>> browsers.
>>> 
>>> However, while we wait for users to have browsers that support these 
>>> features, is there something that we can deploy today? Xauth could be 
>>> an interim solution until we do have support in the browser. It is 
>>> conceivable that browsers could reuse the same Xauth JS interface.
>>> 
>>> Again - I don't see why we can't work on both server based and 
>>> browser based solutions in parallel.
>>> 
>>> Regarding the privacy issues of having a centralized domain - the 
>>> overwhelming majority of sites already deploy centralized JS that 
>>> already correlates users across domains - so in this respect, Xauth 
>>> is really nothing new. Ad networks, website analytics, and "Like" 
>>> buttons are just a few examples.
>>> 
>>> As far as I know, all of the serious proposals for using Xauth is 
>>> just to store the user's OP preference - a simple boolean flag that 
>>> indicates that the user behind the browser happens to be concurrently 
>>> logged into a particular IdP. This is already "public" information 
>>> that some IdPs already support - for instance both Facebook and 
>>> Google already support this
>>> today:
>>> 
>>> Facebook Connect Status:
>>> http://wiki.developers.facebook.com/index.php/Detecting_Connect_Statu
>>> s
>>> 
>>> Google's openid.ui.mode=x-has-session:
>>> http://code.google.com/apis/accounts/docs/OpenID.html#Parameters
>>> 
>>> The only new thing in Xauth is that RPs can just query a single API 
>>> (potentially loaded entirely from the browser's cache) to check all 
>>> IdPs where the user could be logged into. This is information that 
>>> RPs can already get by directly querying each IdP. The only 
>>> difference is that Xauth can reduce the network overhead of checking 
>>> the login status.
>>> 
>>> It is true that there are serious challenges with having a 
>>> centralized domain - who runs this domain? How is it governed? Where does the data go?
>>> These are real issues - however they're not really technical issues, 
>>> and I think they can be solved, if a "trusted third party" can run 
>>> it. I still have yet to see a serious proposal to actually run this 
>>> domain though - so perhaps this is not realistic.
>>> 
>>> 
>>> Allen
>>> 
>>> 
>>> 
>>> On 6/7/10 10:17 PM, "Eran Hammer-Lahav" <eran at hueniverse.com> wrote:
>>> 
>>>> 
>>>> If Google, Yahoo, Microsoft, and the rest of the companies 
>>>> supporting
>>> the
>>>> OpenID effort deployed the server-side half of this proposal, and 
>>>> spent
>>> a
>>>> little money on developing plug-ins for all the major browsers (with
>>> Google
>>>> and Microsoft able to also include it in the next release of their
>>> browser),
>>>> it will create the tipping point in getting some form of identity
>>> selector in
>>>> the browser.
>>> 
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

More information about the specs mailing list