Links

Ben Laurie blathering


XAuth: Who Should Know What?

Note that I am not speaking for my employer in this post.

I’ve been following the debate around XAuth with interest. Whilst the debate about whether centralisation is an acceptable stepping stone to an in-browser service is interesting, I am concerned about the functionality of either solution.

As it stands, XAuth reveals to each relying party all of my identity providers, so that it can then present UI to allow me to choose one of them to authenticate to the RP. Why? What business of the RP is it where I have accounts? All that should be revealed is the IdP I choose to reveal (if any). This seems easy enough to accomplish, even in the existing centralised version: all that has to happen is for the script that xauth.org serves is to include the UI for IdP choice.

This is not just privacy religion (or theatre): as the EFF vividly illustrated with their Panopticlick experiment, it is surprisingly easy to uniquely identify people from signals you would have thought were not at all identifying, such as browser version and configuration information. Indeed, a mere 33 IdPs would provide enough information (if evenly distributed) to uniquely identify every person in the world. Meebo had no difficulty at all coming up with 15 of them for page one of many in their introductory blog post

15 IdPs on page 1 of many

4 Comments

  1. Why are people still coloring around the edges with this localstorage nonsense and not building identity directly into the browser, as Eran notes? I suppose it’s a natural consequence of the fact that browsers are an open standard that nobody’s making any money off of directly, leading to a tragedy of the commons where nobody cares what happens on the web. Obviously meebo has some financial incentive, but they can only do so much compared to some of the larger players. Perhaps even more damning is the complete lack of imagination and silliness of these incremental solutions. I bet even meebo could theoretically write browser plugins for identity that are much better than this Xauth “solution,” but they haven’t exactly shown much potential for such real solutions.

    Comment by Ruben — 11 Jun 2010 @ 20:55

  2. But then we’re back to square one with the NASCAR problem all over again.

    I suppose another way to rephrase what you’re saying is: the requestor invokes XAuth — which first presents a chrome-based (?) UI to the user to pick which services to reveal to the requestor. This would only work if there were already data stored in the XAuth datastore, of course.

    In the event that no data were available in the XAuth store, then the requestor would need to show an unoptimized NASCAR anyway — in which case they might as well avoid using XAuth since now the user would have had to cancel out of an irrelevant dialog.

    Furthermore, XAuth seems much more useful to me once we get into service discovery — which has the same fingerprinting aspect of IDP discovery (as did the :visited hack until it was recently patched).

    To Ruben: I think you vastly underestimate the challenge of getting a solution like XAuth — which relies on HTML5 capabilities to be adopted even without the need to modify or install software in the browser. XAuth will work on the iPad; the solution you described won’t. And any solution that we want to see widely adopted needs to work incrementally to prove out the value, but provide a bridge to the future once we’ve proved the case to browser makers.

    The biggest problem with “building identity directly into the browser” is that no one knows what it should look like — and how it should fail when you’re not using your browser. I did some mockups last fall that provide one vision for how this might work, but I haven’t seen anyone rush to build it yet:

    http://factoryjoe.com/social-agent

    Comment by Chris Messina — 13 Jun 2010 @ 21:38

  3. Chris: I don’t really understand what you mean: why do we get the NASCAR problem? If XAuth can fix that problem, then it can fix it regardless of who provides the selection UI. If it turns out the dialog is irrelevant (don’t really see how that could occur, the user has to select _something_), then it needn’t be shown.

    Comment by Ben — 16 Jun 2010 @ 13:15

  4. Chris, I’m well aware of the challenges of Xauth, as I noted with the localstorage dependency. The fact that Apple doesn’t allow browser plugins on the iPad/iPhone is a testament to their crippled hardware and software, that’s about it. I agree about starting incrementally, which is why I mentioned browser plugins as the best place to start. Using plugins for identity won’t work if you’re using a browser at your internet cafe or your friend’s place but you shouldn’t be installing your identity at those locations anyway, you’re always going to need fallbacks for such edge cases. I’m glad to see you’ve already been thinking about putting identity into the browser, now please do something about it and put it into Chromium, ;) just don’t make it Google Accounts only as that’s a non-starter. I already store a handful of non-critical passwords in Chromium and did so for years in Firefox, to the extent that I forgot what those passwords even were, better to go the next step and make identity a built-in feature of web browsers.

    Comment by Ruben — 16 Jun 2010 @ 18:08

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress