Yadis and URL-Based Identity
Johannes Ernst has taken another swing at the YADIS (Yet Another Decentralized Identity Interoperability System) with Brad Fitzpatrick and David Recordon of SixApart. Johannes is the head of Netmesh – the people behind LID – the Lightweight Identity System. Brad and David are the driving force behind OpenID, an even lighter-weight identification system than LID. Both LID and OpenID focus on the URL as the anchor object for an identity, and in past months have worked to find an abstraction layer that would allow sites and organizations that consume identity to use a single means of discovery to authorize users who have OpenID or LID-based identities. Yadis is still painfully thin in terms of specification, but it seems probable that in the next couple months the details will be nailed down sufficiently to enable implementations that let identity consumers consume identities from either LID or OpenID users, or from other ID systems as well.
It’s not clear that the people behind Yadis have coordinated at all with Kim Cameron of Microsoft, but Yadis, sketchy though it is, sounds a whole lot like the identity metasystem Kim’s been advocating. Microsoft’s metasystem tends toward behind being large, comprehensive and quite complicated, and Yadis in comparison is much more humble and practical, but they both point to the same need; rather than a “better mousetrap” for SSO and identity, a “plug-and-play” bus needs to be agreed on that will enable those who consume identities to integrate multiple competing identity systems in one implementation.
Identity System Discovery
The this behind YADIS is not about implementing a particular identity scheme. It’s not an identity framework itself. Rather it’s a discovery mechanism. A Yadis-equipped website – say your blog – would use the Yadis discovery protocol to determine what identity capabilities the submitted URL supported. Right now, the only two that are addressed are LID and OpenID. Yadis provides a mechanism for a user to configure their identity URL(s) for LID, OpenID, or both.
It’s possible (and probable) that other identity systems will be plugged into this process, meaning that a Yadis-enabled identity consumer (like our blog server) would have an increasing number of possible ID systems to choose from for its users. The basic requirement for Yadis is that the submitted identity claim be expressed as a URL. If a given identity system can satisfy that requirement, then conceivably it could clip into the Yadis “plug-and-play” framework. It’s not incumbent on an identity consumer to support any particular ID system. The website may inform the user upfront which ID systems it supports, or generate appropriate error messages when the discovery process fails to find a suitable ID framework for the submitted identity URL.
If Yadis succeeds, then, it provides a way for websites to support multiple ID frameworks, and to let all the different identity mousetraps compete within a single framework. New, Yadis-compliant ID systems can be introduced, without the website having to re-engineer it’s login systems. All that would have to be changed is the configuration on the back end --- adding the new system to the “supported” list and specify the trust controls for it. In this way, Yadis enables a “marketplace” for identity frameworks, and provides a means by which multiple frameworks can co-exist, competing and ordering themselves in the ecosystem according to their value.
There’s a tension between simplicity and self-configuration for the identity owner (the end user), and the identity consumer (the website). Identity consumers would prefer an identity URL to be a pointer to a specific capabilities document. For example, if the identity URL was “http://idhost.com/users/joe/xid”, then the URL might easily resolve to an XML document detailing all the configuration info that identity. The problem is that the user needs to have a single URL, and will want the URL to point to a web page, so that humans – say those reading a business card – can navigate to user’s home page. So if we have a single URL and that URL must resolve to an HTML page, then we have two options: a) use a naming convention for deducing the extended URL for retrieving capabilities, or b)embedding meta information in the HTML home page for the URL. Yadis currently has chosen b), with the additional option of asking the web server for a preferred MIME type of “application/x-meta-identity”. If the web server is configured to support this, regular browsers will resolve “http://idhost.com/users/joe” to the expected “index.html” page. Identity consumers would be asking for “application/x-meta-identity” rather than “text/html”, and would thus receive the expected capabilities document directly. That’s nice, but remember that one of the basic benefits of URL-based identity is that it can be set up and configured by the user, without any special adjustments by the hosting provider. In the case above, the web server would need to be configured to send the capabilities document for the appropriate requests to “http://idhost.com/users/joe”.
Convention over Configuration
David Heinemeier Hansson of 37signals.com and Ruby on Rails fame advocates the idea of “Convention over Configuration”, and it applies here. We don’t emphasize configuration for the name of the HTML file to return for a web site URL like “http://www.domain.com” – by convention it’s “index.html”. Configuration can be applied to serve another page or resource, but the convention has served us well. Like “index.html”, it would make like easy for Yadis implementers, on both the user and the identity consumer side, if a set of simple conventions could be established. For example, if we keep the identity URL “http://idhost.som/users/joe” the way it is, and assume by convention that the URL “http://idhost.com/users/joe/yadis-config” is the derived URL for retrieving the Yadis capabilities document for this identity, we can skip an addition step called for right now, which is the slow and error-prone process of fetching and scraping the user’s home page to suck out the appropriate <link> tags to get things going. Similarly, if the convention prescribes for ““http://idhost.com/users/joe/yadis-key” as the derived URL for retrieving the public key for this identity, interested users (and servers) can go directly there when needed to retrieve the key, rather than having to wander through a set of configuration parameters. Again, in cases where the convention creates a problem, configuration can still be used. For the benefit of the masses, though, conventions offer the best solution, and configuration should be seen as a fall-back/specialization position.
XML vs. HTML vs. Text
In terms of specifying configurations for one’s identity, the OpenID proponents are interested in keeping things as “HTML-centric” as possible – link tags in the <head> section of the HTML doc specify the server and delegate to be used for the identity. This is understandable. For their constituency, editing HTML may not be easy, but it’s at least a fairly familiar process. Johannes Ernst advocates returning simple text documents, with straightforward “line-by-line” directives. This, too makes sense as there’s nothing simpler than having just a simple text document to edit.
My preference would be to bite the bullet and establish a simple XML document format for identity configuration. In my experience, users (including myself here) would be prone to mess up the HTML edits necessary for OpenID style configuration. In the OpenID case, the vast majority of OpenID-equipped users are those with LiveJournal accounts. LiveJournal conveniently configures their home pages for them – no editing necessary. But again, if one of the driving requirements is that a user should be able to setup and configure their own identity URL without any outside help, the “HTML-editing” strategy for configuration is problematic. Or at least no better for the user than editing a plain text file, or an XML file.
I believe users can edit simple XML files to define their configuration for their identity URLs. A simple text editor is all that is needed, and it’s easy to conceive that “helper” web pages will emerge that allow users to enter their options into a “control panel” form and download the result as a properly formed XML identity configuration file. (Note to self: something to gin up some evening.). The same can be said for editing HMTL documents, but the process is much more complex when you have to edit someone else’s home page cleanly as part of the process.
On the consumer side, an XML configuration file wins hands down. Having written several different prototypes with OpenID and LID, I can say that snarfing out the right configuration parameters from an OpenID or LID URL isn’t rocket science, but it’s a hassle, and bound to become a major hassle as the demands on configuration (think security options) get more complex over time. Identity consumers are servers, and as such, feel much more comfortable parsing and managing XML documents than either HMTL or plain text. Give me a well-formed XML document, and I can suck out what I need quickly, accurately, and in just a few lines of code. It wasn’t hard to write a simple plain text parser for LID’s capabilities document, but isn’t this why we have tools like XML in the first place?
Most importantly, XML provides serious headroom in terms of additional semantics that can be supported in the future Considering that it adds very little complexity to the user experience, it not only makes the identity consumers’ job much more straightforward, but enables the addition of new features and semantics with little effort. OpenID’s HTML model and LID’s plain-text model will not scale in terms of new semantics. XML configuration files will.