April 19, 2010
@ 03:38 PM

There's an interesting post on ReadWriteWeb about a burgeoning technology effort supported by a number of web companies titled XAuth: The Open Web Fires a Shot Against Facebook Connect which states

A consortium of companies including Google, Yahoo, MySpace, Meebo and more announced tonight that it will launch a new system on Monday that will let website owners discover which social networks a site visitor uses and prompt them automatically to log-in and share with friends on those network. The system is called XAuth and serves to facilitate cross-site authentication (logging in) for sharing and potentially many other uses.

Facebook and Twitter, the dominant ways people share links with friends outside of email, are not participating
...

What XAuth Delivers

It's like Facebook Connect, but for every other social network.

The gist here is that XAuth will make it easier for sites around the web to find out what social networks you are using, let you log in to those easily, access your permitted information from those networks in order to better personalize your experience on their site and easily share their content back into your social network. It's like Facebook Connect, but for every other social network. Any website can register as an identity provider with XAuth, too.

What About OAuth?

If you're familiar with OAuth, you might be wondering what the difference is between that system of secure authentication and XAuth. Here's one way to explain it: XAuth tells a webpage "this is where the site visitor does social networking." Then, OAuth is the way the user logs in there, granting the site permission to access their info without seeing their password. In other words, XAuth tells you where to ask for OAuth from.

Google's Joseph Smarr, recently hired because of his high-profile work on distributed identity systems across the web, says that XAuth is a provisional solution to the limitations of the cookie system. If you visit ReadWriteWeb, for example, our servers aren't allowed to check the cookies left on your browser by the social networks you use because they are tied to URL domains other than ours.

The first thing that is worth pointing out is that XAuth is not like Facebook Connect. Facebook Connect enables a website to associate a user’s Facebook identity, social graph and activity stream with the site. XAuth enables a website to discover which services an end user is a member of that support associating a user’s identity, social graph and/or activity stream with third party websites.

A practical example of this is the various sharing options at the bottom of this blog post (if you’re viewing it in the browser on your desktop PC)

This is a fixed list of options that where I had to write special Javascript code to handle each service. There are a few issues with this approach. The first is that people end up seeing exhortations to share on services they don’t use which is just visual noise in that case. Another is that, each of those widgets involves a Javascript call to the domain of the service which impacts page load times. In fact, I used to have a Reddit widget but took it out because their server was too slow and noticeably impacted rendering of my blog. Finally, I tend to keep the list small because I don’t want my blog posts to suffer from the NASCAR problem so some services that may be popular with my audience audience are left out (e.g. I have no widgets for sharing on Google Buzz, Slashdot or Digg).

How the XAuth specification attempts to solve this problem is fairly straightforward. Services that want to participate include some Javascript from http://xauth.org which writes some data to the local storage (not cookie) for that domain when the user visits the social network. At that point there is now an indication on the user’s machine that they are a member of the aforementioned social network. Then when the user visits a site such as my blog, I also include the same Javascript from but this time I ask it if the user is a member of the social networks I’m interested in. Once the list of sites is returned, I then only have to render sharing widgets from the sites I support which the user is a member of.

In general, I think XAuth is a legitimate attempt to solve a valid problem. However it should be made clear what problems XAuth doesn’t solve. For one, people like me who have an account on Facebook, Twitter, Digg, Google, Windows Live, Reddit,  Delicious, etc will actually have a more cluttered experience than we do today. I know I’m always a little confused when I visit a site that uses Clickpass since I can never remember if I’ve associated that site with my Facebook, Windows Live, Yahoo! or Google account. Similarly XAuth will potentially exacerbate the problem for the subset of people who are members of lots of social media sites. Another thing to be made clear is that this isn’t a replacement for delegated authentication and authorization technologies like Facebook Connect, Twitter’s @Anywhere or OAuth WRAP. Sites will still need to support all of these technologies if they want to reach the widest audience. This is just about hiding options from users that do not matter to them.

The one thing I’d keep an eye on is that XAuth provides a token that uniquely identifies the user as part of the results returned to the requesting site instead of a simply stating the user is a member of a specified social media site. This enables the requesting site (e.g. my blog) to potentially make some API calls to the social network site for information specific to the user without asking for permission first. For example, pre-populating the user’s name and display picture in a comment box. Since Facebook has already announced such functionality I guess people don’t think it is overstepping the bounds of the user relationship to enable this feature on any website the user visits without the user explicitly granting the sites permission to their profile information. It will be interesting to see if implementations of this feature steer clear of some of the creepiness factor of Facebook’s Beacon program which led to massive outcry in its day.

Note Now Playing: Jamie Foxx - Winner (featuring Justin Timberlake & T.I.) Note


 

Monday, 19 April 2010 16:37:45 (GMT Daylight Time, UTC+01:00)
Dare-great write-up, as always! One quick clarification: you say that "XAuth provides a token that uniquely identifiers the user", but this is not currently true, nor is it necessarily true in the future. XAuth just provides a mechanism to share some bit of info from each provider, but for instance Google and MSFT both just share a "1" to indicate "someone is logged in" but it's not a GUID or anything with PII. It's true that if providers wanted to share more (e.g. provided a user wanted to opt-in to share more info automatically in exchange for greater convenience), XAuth could facilitate this, but it's also possible that it will remain primarily used for service-level discovery and there won't be any automatic sharing of anything personal. Thanks, js
Comments are closed.