In a previous post on emerging ID management technologies I came to a few conclusions about these lightweight URL-based technologies that were subsequently corrected in an email conversation with Johannes Ernst.

My confusion originated from a combination of the bias I had towards these technologies based on the initial use case for URL-based identity schemes (authenticating blog comments without site-by-site registration or a centralized repository like TypeKey), and (in my opinion) the way they are presented in the form of examples focused on blog comments, ecommerce, and site registration.

Of course, these are all great applications of a lightweight ID management technology, so I can’t fault the groups involved for advocating their techologies this way, but it obscures what I think is the fundamental abstraction which the lightweight URL-based ID management technologies offer: the ability to present a URL as representative of one’s identity, then authenticate one’s authority to use that URL for that purpose. Sure, there’s alot of stuff built on top, like user-controlled sharing of vCard data, multiple identities, even messaging, but we’ve seen all that before. It’s the URL with distributed authentication abstraction that I see as so powerful.

To demonstrate how powerful this relatively simple concept is, consider the way the problem of ID management is handled today on the Internet. From Amazon.com to Google to blogs to newspaper sites, you’re constantly required to create an account on that site to fully participate. The reasons for this vary from nefarious spamming to accountability to marketing, but a common theme is typicaly some sort of unique ID (an available username, or perhaps your email address), a password, and zero or more additional bits of info.

Often the email address is verified before the account is active, but every now again again you find a laissez-faire site that doesn’t care.

At any rate, this sucks and making it go away is a prereq of any successful ID management technology. To see how the URL-based ID management systems are valuable, imagine if, when visiting a site, you had only specify your email address, and the site could by some plumbing call back to your mail server and affirm that the user agent (browser, whatever) that submitted your email address to that site is in fact authorized to do so on behalf of that email address.

Further imagine that, through some additional tech plumbing, you could control what sites could send you email to that address, could with your permission retrieve more information about you from your mail server, and you could provision email addresses for your various activities, and link them or keep them separate as you desired.

If you replace ‘email address’ with ‘URL’ in the above example, you’ve got the current crop of lightweight URL-based ID management technologies. It’s important to understand, however, that this is by no means limited to authenticating against sites with your web browser, interactively. As Johannes pointed out, the fundamental abstraction is the URL and cryptographic evidence that a given requestor has authority to represent itself as that URL.

So, in the trivial case, this plumbing allows me (or software acting on my behalf) to say “I am the person/place/thing represented by http://apocryph.org/anelson”. Note that the actual content at this URL is of secondary importance; what really matters is that the URL is unique. There are plenty of ‘anelson’s running around the Internet, but only one ‘http://apocryph.org/anelson’.

The recipient of this assertion (an e-commerce site, a blog posting API, a corporate search engine, a Jabber server, whatever) then uses this plumbing to callback to the server hosting my identity at ‘http://apocryph.org/anelson’ (though with LID and OpenID at least, the server hosting the identity can be different than the server hosting the URL, but that’s not important to this example), and asks that server if I (where ‘I’ may be defined by a cookie, a session ID, whatever) do indeed control the identity at ‘http://apocryph.org/anelson’. The server can respond ‘yes’ or ‘no’, or (and this is the piece I was missing) I (where ‘I’ is me or a software agent acting on my behalf) can provide cryptographic evidence that I control the ID URL.

This second bit is key; it means that the URL-based ID management protocols don’t assume any particular topology, and it is also an example of decentralized public key cryptography employed in a much more accessible way to the masses, who can remain blissfully unaware of all the crypto details under the covers and still benefit from its use.

Recently, the principals behind LID, OpenID, sxip, and Yadis, together with various industry players, formed the Open Source Identity Selector (or, OSIS) project. The goals of the project are:

the OSIS project brings together heads of open-source projects related to digital identity, in order

1. to enable those projects to work independently, but aligned, so overlap of work is avoided, and the parts developed by different projects can fit
2. to deliver an open-source identity selector as a joint effort of multiple projects, which is intended to be at least as functional, and fully compatible, with Microsoft’s CardSpace (formerly known as InfoCard) identity selector that will be shipped with Windows Vista.

This effort to collaborate on ID technologies and integrate with Microsoft’s CardSpace distributed ID management system seems to point to a real growth in these technologies. OSIS is working towards rich server- and client-side implementations, which could bring URL-based ID management to a wider range of users.

It seems possible that this family of interoperable technologies could succeed where Passport et al have failed, through a decentralized model, open specs, diverse implementations, and serious interoperability. insha’allah.