The ‘x’ in xAuth stands for…

…xhausting!

OK! So being at a conference (Cloud Computing Expo in NYC, where Oracle is making big waves with announcements in the PaaS space) where I had no wi-fi or power meant that I was trying to follow the big xAuth announcement via Twitter on my iPhone over 3G – note exactly the easiest thing. And after participating in a flurry of twittersations yesterday, I spent time this morning catching up on all the first take blog posts on it. It’s clear that the other word that the ‘x’ could stand for would be “xtremely polarizing” (fine, that’s two words, but since when has that been an issue for Colbert on ‘The Word’!).

I like to think I am a realist, and my initial take on the xAuth idea was that it was a good idea necessary to solve the usability issues holding back the widespread adoption of federated consumer authentication. The usability issue in question is the old NASCAR issue (you can read a good overview of the issue here, but the image below speaks a thousand words) which either causes clutter and user headache, or favors the big players in the IdP space.

Faced with this, you can understand why application developers get all clingy about the old “username-password” form – it’s simple and well understood by users, no matter the security and identity management challenges it creates.

To me the solution is conceptually simple: when I land on a page that supports IdP based authentication, there should be a way for the UI to display just the icons for IdPs that I use. This could be based on (1) my previous usage history across the web, (2) an explicit list I have set up somewhere, or (3) preferences I set up on the RP site the first time I went there. Solution (1) obviously has huge privacy implications, and becomes a non-starter in most discussions for that reason. So I was intrigued when it seemed like xAuth might be tackling approach (2).

Since then my enthusiasm has been dampened a bit after digging a little deeper. And the take from folks I trust in such matters has been cautiously pessimistic. The idea of a central service that any RP can ping to find out what IdP choices to display to a user appeals to me, but the big thing missing from xAuth.org (the proposed central service) are the user protections and controls that I feel are necessary.

• First off, participation must be Opt-In, not Opt-Out (there seems to be universal agreement on this, except from the RPs – as Pamela points out).
• Secondly, the setup should be an explicit white list with layers: Here are the 4 IdPs I’d use by default across the web, but here are 2 more I will consider for specific RPs or classes of RPs (which I could select from a pre-defined list of participating RPs at xAuth.org), and so on.
• And finally, this needs to converge with the Identity in the Browser movement, so as to solve the shared computer as well as the privacy issues (pertinent to unintentional information sharing with the RP) that emerge from this model.

I don’t like dismissing any proposal right off the cuff because of flaws that may not have been worked out yet, so I am hopeful that the energy and discussion I am seeing on xAuth right now continues to push it (or a suitable alternative) in the right direction. At least it has the identity community abuzz, and given the hole that this weeks postponement of Catalyst Europe left in our schedules, that’s a good thing.