Skip to main content

XAuth is a Lot Like Democracy

XAuth is a lot like democracy:  The worst form of user identity prefs, except for all those others that have been tried (apologies to Churchill).  I've just read Eran's rather overblown "XAuth - a Terrible, Horrible, No Good, Very Bad Idea", and I see that the same objections are being tossed around; I'm going to rebut them here to save time in the future.

Let's take this from the top.  XAuth is a proposal to let browsers remember that sites have registered themselves as a user's identity provider and let other sites know if the user has a session at that site.  In other words, it has the same information as proprietary solutions that already exist, except that it works across multiple identity providers.  It means that when you go to a new website, it doesn't have to ask you what your preferred services are, it can just look them up.  Note that this only tells the site that you have an account with Google or Yahoo or Facebook or Twitter, not what the account is or any private information.

Some objections to all of this are natural; I had them too.  Below are my answers (note: I'm not speaking for Google here, just myself, but I believe these answers are consistent with what people like Chris Messina and Joseph Smarr are thinking).
  1. Objection:  The implementation relies on a single domain.  Answer:  The current implementation does this due to restrictions in browser security models.  There is no essential reason for that single domain to exist, there is no data stored on the domain's servers and no web services accessed from it.  It just stores the JS used to implement the API today.  In theory one could write a browser extension that maps "" to "", make sure to serve up the JS from a local web server, and XAuth would work fine.  A better use of time is to convince the browser vendors to support XAuth natively.  Which leads to objection #2...
  2. Objection:  This should be done by the browsers, not by a back door via a JS API.  Answer:  Yes, it absolutely should, and the best and fastest way to make that happen is to get a deployed solution and user experience supported by many sites as quickly as possible, then swap out the implementation.  It is trivial to replace the XAuth JS core with calls to a browser solution.  In fact it'd be great to figure out a good way to make this happen automatically with feature sniffing, though for that we'd need a very stable JS interface.  And for that we need... field deployment experience!  XAuth is a great bootstrap to a browser centric future solution.
  3. Objection: But the central domain name should not be managed by a single party, even in the interim:  Answer: Yes, that's true, and the parties involved are working to get it managed by a neutral third party who can be trusted not to do something bad.  Note that we can know fairly easily if some domain owner starts to do bad things as they'd have to mess around with the publicly visible JS to get information to go anywhere but the users' local computer.
  4. Objection: It should be opt-in per browser, not opt-out.  Answer:  Note that XAuth doesn't prevent opt-in semantics on the part of identity providers, it just doesn't enforce it.  All other things being equal, yes, it would be better to force the default to "off" and ensure users understand what they're doing when they turn it "on".  The last bit is hard; a choice that users don't understand is even worse; it doesn't really solve anything but hurts adoption -- and gives proprietary alternatives, which don't require opt-in, a big advantage.   Again, a browser-native alternative may be able to solve this.  An XAuth ecosystem, already in place, ready for browsers to use, is a powerful incentive for them to do this.
Eran writes: "This is a misguided attempt to solve a problem browser vendors have failed to address. It is true that getting browser vendors to care about identity and innovate in the space is a huge challenge, but solving it with a server-hosted, centralized solution goes against everything the distributed identity movement has tried to accomplish over the past few years."  (Emphasis mine.)  It is precisely my hope that XAuth will help bootstrap the ultimate goals of the distributed identity movement, and that it will actually accomplish things in a short time frame while setting the environment up for a better solution in the future.

[Updated:  You may want to refer to the original announcement of XAuth back in April, where many of these objections have already been answered.]


  1. Instead of XAuth, why not just use a two stage security platform, like a mobile phone, to provide OTPs. The user could use the same user name and password, plus a randomly generated OTP for each login and be done with it. Problem with OpenID, and XAuth by proxy, is that theft of a single ID could compromise every service attached to that ID.

  2. Since the majority of users re-use their username (email) and password across dozens of sites today, theft of a single ID already compromises every service the user uses. It's just much, much harder to recover from.

    XAuth doesn't do authentication, it just points to your authentication provider. You can then choose to use an authentication provider that does OTP.

  3. It's not something browsers "failed to address". We've had client certs since Netscape 3 and they work fine. It's an identity, you create them youself, and you can get encrypted communications for free.

    Granted, it could be easier to use. But any browser could improve their UI in that area without affecting any services already in use.

    Just my .02 (and really criticism against openid, not xauth)

  4. It is strange to call items 2-4 "answers" when
    you seem to be agreeing with the objections.
    In light of this it may be unfair to call Eran's
    post on XAuth "overblown".

  5. Very interesting topic.. However the idea of storing the users' identity provider in the browser seems a bit odd. That would mean all browsers (and older versions) would have to provide some facility to allow for such user provider registration in which case such information will most likely be stored as a session cookie (or perhaps in some other form dictated by a new RFC that all browsers have to support (highly unlikely)). If this is supported via cookies then what if cookies are disabled on the browser? Would the user be prompted to enter the authentication details of every single domain when authentication fails? The other approach that comes to mind would be to use a common trusted identity and access management (IAM) service provider that binds together the user session information across different service providers pretty much like a SSO except it is across different service provider domains -- Arun, P


Post a Comment

Popular posts from this blog

The problem with creation date metadata in PDF documents

Last night Rachel Maddow talked about an apparently fake NSA document "leaked" to her organization.  There's a lot of info there, I suggest you listen to the whole thing:

There's a lot to unpack there but it looks like somebody tried to fool MSNBC into running with a fake accusation based on faked NSA documents, apparently based on cloning the document the Intercept published back on 6/5/2017, which to all appearances was itself a real NSA document in PDF form.

I think the main thrust of this story is chilling and really important to get straight -- some person or persons unknown is sending forged PDFs to news organization(s), apparently trying to get them to run stories based on forged documents.  And I completely agree with Maddow that she was right to send up a "signal flare" to all the news organizations to look out for forgeries.  Really, really, really import…

Why I'm No Longer On The Facebook

I've had a Facebook account for a few years, largely because other people were on it and were organizing useful communities there.  I stuck with it (not using it for private information) even while I grew increasingly concerned about Facebook's inability to be trustworthy guardians of private information.  The recent slap on the wrist from the FTC for Facebook violating the terms of its prior consent agreement made it clear that there wasn't going to be any penalty for Facebook for continuing to violate court orders.
Mark Zuckerberg claimed he had made a mistake in 2016 by ridiculing the idea of election interference on his platform, apologized, and claimed he was turning over a new leaf:
“After the election, I made a comment that I thought the idea misinformation on Facebook changed the outcome of the election was a crazy idea. Calling that crazy was dismissive and I regret it.  This is too important an issue to be dismissive.” It turns out, though, that was just Zuck ly…

My faxed letter to both my Senators this morning

My faxed letter to both my Senators this morning.

Senators Grassley and Graham, this morning, engaged in an obvious act of witness intimidation. They leaked a letter to the Justice Department referring criminal prosecution against Mr. Steele for alleged but unspecified false statements to, apparently, the FBI.

This is on the heels of Senator Grassley refusing to release the testimony of Fusion GPS, refusing to allow the public to evaluate the claims of Simpson vs. selective and apparently inaccurate leaks of said information from the Republican members of the committee.

This is outrageous.

It is unacceptable. It is un-American. These Senators are trying to achieve in then court of public opinion what they have no chance of doing in a real court. They are themselves engaging in witness intimidation & obstruction of justice.

I call on you to denounce this desperate and illegal act by your colleagues and to introduce a motion to censure these two sitting Senators who have demeaned th…