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 "xauth.org" to "127.0.0.1", 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.]

Google I/O, Salmon, and the Open Web

Last week was intense, and I'm just now coming up from air from the backlog.  We launched a huge expansion to the Buzz API at Google I/O.  My contribution was to ensure that PubSubHubbub real time updates flow for the new feed URLs as well as the older ones; as part of this, we also enabled "fat pings" to the hub from Buzz.  "Fat pings" in this case means that we're doing an active push of each full update from our back end systems through to the hub, so the hub never needs to call back to the feeds to retrieve updates.  This is a more complicated approach, but reduces the overall server load and makes consistency guarantees easier for globally distributed systems.

Just before Google I/O, I went to IIW10 and talked about Salmon, LRDD, Webfinger, and OpenID Connect.  The air at IIW was thick with new specifications and updates.  I would've liked to have participated more, but I was helping to roll out PubSubHubbub for Buzz and getting ready for the "Bridging the Islands" Google I/O talk I was to give with Joseph Smarr the next day.

And then, my laptop crashed.  I blame Chris Messina -- Joseph and I were stealing some of his slides, and I was editing his slide deck when the system froze up and refused to boot.  Turned out later that accessing that file somehow corrupted the disk encryption driver.  That's right, Chris Messina's slide decks are powerful enough to destroy laptops.

Fortunately, we recovered and had a great session (some audience notes here).  Here's a screencast of the cross site Salmon mention demonstrated in the session.  This shows a user on Cliqset mentioning a couple of buddies using other services (StatusNet and a scrappy startup called Atollia), having information flow between the sites, and having mentions be pushed the other services.  The big take-away here is that these services don't need to pre-register or federate with each other any more than they need to federate to send email back and forth; it all Just Works.

Blogger Template Designer in draft!

Awesome new template designer from the Blogger team, now on draft.blogger.com.  I've converted this blog to one of the new templates, it's a huge improvement.  It's very easy to play around with different looks, the new templates look great, are a lot more on the way.  Nice work!

Salmon Protocol RFC draft Now Available

For the past couple of weeks, I've been banging on code and xml to work out a coherent draft spec for the Salmon Protocol. Although Salmon is intended to primarily be a glue protocol, tying together a bunch of disparate existing pieces into an understandable and coherent framework turns out to be a lot of work. Now starts a slog through a bunch of issues (including a backlog on Magic Signatures which need to be addressed) and updating the demo code and libraries to stay in sync with the spec.

Please join the salmon-protocol group if you're interested in working on the Salmon specification and/or writing code that implements it.

In case you're counting, Salmon references 10 other specifications in addition to Magic Signatures.

Webfinger now available for Google public profiles

If you've seen ReadWriteWeb's "Email as Identity", you know that Brad just turned on Webfinger for anyone with a public Google profile.  What this means is that, if (and only if) you've enabled your public Google profile at http://www.google.com/profiles/{username}, you can now use Webfinger to look up information you've added to your profile.  Here's the one for john.panzer for example.  By default this exposes only generic service endpoints, not actual information about the user.  But you can link it to private or public feeds, services, or basically anything you want to associate with your online identity.

A next step for Salmon is to let users add a link to their public key from their Webfinger discovered info.  Then given an email address it will be trivial to look up their preferred public key.  It'd look something like this via the discovery tool:

links {
  rel: "magic-public-key"
  type: "application/magic-public-key"
  href: "data:application/magic-public-key;,RSA.mV...ww.AQAB"
}

Google Buzz and Salmon

You may have heard of a small launch this morning:  Google Buzz is being rolled out to all GMail users right now.

There's an obvious connection to the Salmon Protocol; DeWitt just put up a blog post giving the big picture for Buzz and open protocols on the Social Web blog, and technical details on the Google Code blog from Brian Stoler. Most importantly, there's a Labs Buzz API.  Here's the take-away:

We'd like to take this opportunity to invite developers to join us as we prepare the Google Buzz API for public launch. Our goal is to help create a more social web for everyone, so our plan for the Buzz API is a bit unconventional: we'd like to finalize this work out in the open, and we ask for your participation. By building the Google Buzz API exclusively around freely available and open protocols rather than by inventing new proprietary technologies, we believe that we can work together to build a foundation for generations of sites to come. We're ready to open the doors and share what we've been working on, and we'd like for you to join us in reaching this goal. - Join the Conversation

This is one of the motivations behind Salmon as an open, non-proprietary, standards-based, and interoperable protocol.  This goes two ways:

1. Since Buzz can pull in feed based data from anywhere, we want Buzz comments and likes on that data to flow back upstream to sources like Flickr and blog posts.
2. As services consume the public Buzz streams, we want to make it easy for them to also send salmon back upstream to Buzz as well.

And of course we plan to do this in an way that's decentralized and isotropic, with no most favored site. Buzz is no more central than any other service that talks the necessary protocols.  Come join us on the Buzz API Group to talk more about Buzz and how it's leveraging open, decentralized standards.

Magic Signatures

Just wrote up a detailed Internet-Draft for the Salmon signature mechanism; since it's an outgrowth of the "magic security pixie dust" for Salmon I'm calling it Magic Signatures for now. It approximately matches the Magic Sig demo as well. Feedback welcomed!

(Updated: Just changed the text at http://www.salmon-protocol.org/salmon-protocol-summary as well, hopefully it makes a bit more sense now.)