XAuth critiques

[John Panzer]

Allen -- Thanks for this detailed and well reasoned response.  I think that
working through the user experience issues is one of the big challenges
facing decentralized identity.  Parallel approaches on both the server based
and browser based fronts, with good information exchange about what user
experiences work in the field and what don't, should be both possible and
highly desirable IMHO.

I hope, and trust, that the political and administrative issues with getting
a neutral party to run a domain can be solved.

John

On Tue, Jun 8, 2010 at 11:23 AM, Allen Tom <atom at yahoo-inc.com> wrote:

> 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_Status
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100608/e2e4bae2/attachment.html>