A few weeks ago, a handful of web companies lead by Meebo and Google (with moral support from Yahoo!) announced their support for a new protocol called XAuth. The idea is very simple and seemingly appealing – create a sort of shared-cookie service for sites to use to store and find which identity providers a user prefers, solving the OpenID NASCAR problem. It is a similar idea to existing commercial products such as JanRain’s RPX.

I’ve heard about this proposal a few months ago and have been rolling my eyes ever since. Why? Because this is – to borrow from one of my son’s favorite book – a terrible, horrible, no good, very bad idea. It is a dangerous and over simplified hack aimed at solving a complex problem – how to manage online identities and improve the usability of distributed identity providers.

The XAuth proposal is a privacy and security nightmare. It relies on the use of a single, shared domain name which is currently under the control of one company – Meebo. While I have nothing against Meebo, other than proposing and promoting this, I certainly don’t trust it to manage the web’s identity preference layer. I heard suggestions of handing control over to the OpenID Foundation, but I don’t trust it either. If it is controlled by a single entity, it fails the most basic test of distributed identity services.

In addition, XAuth is a cookie-like mechanism that suffers from all the same problems, and as such, is an easy target for abuse and manipulation. And guess what – it is an opt-out mechanism per browser.

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.

As for the name, I resent the association between XAuth and the OAuth brand, using a cloned logo and a very confusing name. This is especially true considering it has nothing to do with OAuth, and everything to do with OpenID. And by the way, the name is already taken.

I think I’ll move to Australia.

Update: This post sparked a response from Google’s John Panzer (someone I highly respect, and respectfully disagree with) as well as an interesting thread on the OpenID list. A couple quotes I complete agree with:

From Peter Watkins:

The current XAuth implementation has sites using br elements to access the XAuth service/JS code. Web browsers send Referer headers with br, so whoever runs xauth.org is in a position to see information about what Extender and Receiver sites a user accesses. Currently auth.org has pretty good settings — cache control headers telling browsers they can cache the page for a week. But that could change. Move responsibility into the browser and that problem is solved.

Also, xauth.org could start delivering JS code that reports information to the xauth.org mothership in addition to simply “working”. Say the local government tries to compel xauth.org to deliver additional code to specific IP addresses (not that Google has *ever* had any trouble with any government legal pressure, right?). xauth.org could deliver pristine, trustworthy JS to everyone else. How would the government targets, let’s say political activists maybe, be able to tell their privacy was being subverted? Move the function to the browser and that hole is closed.

This is by no means a comprehensive list (shoot, it’s been less than 24 hours since I startd reading up on XAuth), but I think it’s enough that you can’t say there are no privacy issues that going to an in-browser model would solve no privacy issues.

From Philip Hallam-Baker:

As often happens in these debates, we have a proposal that has an acknowledged issue that we are being told isn’t an issue because the developers don’t see it as an issue.

I really take offense when I raise an issue and someone says ‘that does not matter to anyone’ or ‘that issue has been dealt with’. The one issue that I have never found it difficult to get the industry to agree on is the necessity of ensuring that no party gains a proprietary leverage in a communication protocol.

I don’t see how the promise that the issue will be fixed in future changes anything. Either the centralization is easy to eliminate from the protocol or it isn’t. And if it is easy to eliminate then why introduce it in the first place?

The starting point for identity in my view is that I have to entirely own my name. There cannot be any entity that can use the investment I make in my name to extract rent at a future date. No corporation, no not-for-profit, no non-profit, no industry group. Nothing.

(Image adapted from the book “Alexander and the Terrible, Horrible, No Good, Very Bad Day” by Judith Viorst, illustrated by Ray Cruz.)