Emergence of distributed, lightweight identity management technologies

A while back I ran across LID, a novel idea for a distributed identity based on the URL which was based on a few simple Web techniques, could be hosted anywhere with PHP or Perl access, and wasn’t control by any one organization.

Since then, this type of idea has come to be called ‘Identity 2.0′, no doubt as an outgrowth of an epidemic of irrational exuberance perhaps best characterized as ‘Bullshit 2.0′. Lame marketing monikers aside, there are a few decentralized ID management technologies out now, all of which intrigue me.

First, you have LID, the first technology I encountered which attempts to create an identity out of a URL.

Next I came upon OpenID, which is virtually identical to LID in design and execution, though it retains subtle differences.

Then, it turns out, there are so many of these ID management technologies that you need a discovery framework to detect which ones a site uses and bring them together under one umbrella, which is what Yadis does. Through Yadis I learned of two more URL-based ID schemes, i-names, and sxip.

All of these seem to have more or less the same idea:

  • User goes to a site requiring their identity (eg, logging in, providing an email address, etc)
  • User enters his LID/OpenID/Yadis/i-names/sxip identity URL (eg, apocryph.org or identity20.com/sucker.
  • Site fetches identity URL, looking for some <link type=rel> or <meta> tag or HTTP header to tell it what server/authority/whatever vouches for this ID
  • Site redirects user’s browser to said server/authority/whatever using GET or POST to send it data about what to authenticate and what URL to return to
  • Server/authority/whatever prompts user for username/password, or remembers user from cookie
  • Server/authority/whatever prompts user for permission to share identity information with requesting site, or remembers setting from previous request
  • Server/authority/whatever redirects user back to originating site, POSTing some info about the identity

So, the user only logs in once on whatever system hosts his identity, and this system releases identity information (including vouching for the identity) to various sites as the user sees fit.

There are a few problems, imho:

First, each of these technologies tries really hard to work without any client side changes, and with minimal work on the part of the identity hosts and identity consumers. This is, of course, a good thing, and keeps it simple, however to my mind it limits flexiblity.

Which leads me to my second objection, which is that these all assume a Javascript browser is available. At least one, sxip’s ‘DIX’ (short for Distributed Identity eXchange; no I am not making that up), claims the exchange protocol works over NNTP, SMTP, XMPP, but proceeds to define bindings for HTTP that involve redirects, Javascript, and users filling out HTML forms, leaving me to wonder what an XMPP binding might look like. UPDATE: Johannes Ernst of NetMesh/LID fame emailed me to point out the error in the statement above. DIX (a part of sxip) does employ some Javascript, but the other ID management protocols I mentioned, LID, OpenID, and Yadis, use much more portable HTTP redirects. I misunderstood their respective protocol specs, which was my mistake.

More generally, an identity management framework must be flexible enough to allow autonomous and semi-autonomous software agents to both control identities of their own, and consume identities of others, programmatically. For example, until AJAX can give me broadband across the planet and a rich editing environment (support for bold and italics is not rich), I’ll still derive some value from thick-client GUI document composition tools. If my blog authenticates me with my ‘identity 2.0′ distributed identity management technology, how can a thick-client GUI document programmatically post my blog entires via ATOM or XML-RPC or whatever? Is the ‘Web 2.0′ community really so arrogant as to assume everyone in the future will use a browser for everything?

I suspect not. Much like SOAP in the early days, which we were assured could run over anything yet no one implemented it over anything but HTTP, I suspect the low-hanging fruit for these still-emergent technologies is HTTP and web browsers, and not some thick-client blogging tools. However, if they fail to consider longer-term uses of the technologies that are being built, I fear the resulting systems will not be sufficiently flexible to generalize to the wide range of applications that a comprehensive identity management system was supposed to deliver.

Tags: , , , , , ,

Leave a Reply