Set up OpenID Delegation on Drupal
I finally decided I wanted to set up an OpenID ID attached to the URL of my personal website, apocryph.org. I just set up an account on MyOpenID, installed the Drupal OpenID URL module, and configured it to point to my MyOpenID URL.
I set OpenID Server to ‘http://www.myopenid.com/server’, OpenID Delegate to ‘http://codebloc.myopenid.com/’, and OpenID XRDS Location to ‘http://codebloc.myopenid.com/xrds’. And that was it. Now http://apocryph.org is a valid OpenID. Too easy.
Ideas for OpenID bindings for REST, SOAP, HTTP
I happened to be reviewing the 10th draft of the OpenID 2.0 Authentication spec, when I noticed this nugget in section 5.2.1 of the draft:
[HTTP redirect] method is deprecated as of OpenID Authentication version 2.0 though is still required for implementation to aide in backwards compatibility.
In place of the HTTP redirect used by OpenID 1.1, is this, in section 5.2.2:
A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated using JavaScript.
The <form> element’s “action” attribute value MUST be the URL of the receiving Web site. Each Key-Value pair MUST be included in the form as an <input> element. The key MUST be encoded as the “name” attribute and the value as the “value” attribute, such that the User Agent will generate a message as specified in Section 4.1.2 (HTTP Encoding) when the form is submitted. The form MUST include a submit button.
This disturbed me somewhat, as it couples OpenID 2.0 auth fairly tightly with HTML and interactive user agents. You may recall my earlier rant decrying OpenID 1.1’s tight browser coupling, which I only recanted when Johannes Earnst showed me how wrong I was. Now, it seems, what I thought to be true about OpenID 1.1 is in fact true of OpenID 2.0.
I emailed Johannes about this, and he suggested I post to specs@openid.net. I did, and startied a thread that ended up going off in another direction, but confirmed my interpretation of the OID 2.0 language.
The gist of the explanation for the change was that OpenID 2.0 is much richer than 1.1, and thus will involve larger message exchanges, and thus the 2K limit imposed by using HTTP redirects and therefore GETs will become a problem, ergo HTTP POST populated by submission of an HTML form is the only option left that is compatible with major browsers without extensions or plug-ins.
The reasoning is sound, and under the circumstances I might’ve made the same call. Clearly, there’s alot of value in using OpenID with REST/SOAP/other technologies, but the OpenID community is moving in a direction that requires REST/SOAP/other bindings be described in separate standards.
So, with the encouragement of Dick and others on the specs list, I’ve put together some thoughts on what OpenID bindings for REST/SOAP/HTTP might look like. I’ve created a page on the OpenID wiki to capture these thoughts.
Follow up from Johannes Ernst on group membership and lightweight ID management
A few weeks ago, I emailed Johannes Ernst, asking him how (if at all) he saw lightweight URL-based ID management technologies like LID being used to express group membership semantics. As he promised, he’s put together a long post on group implementation in LID, which answers my questions.
On the plus side, I’m encouraged to see that this type of use case has been on the minds of the ID management players for at least a year, and that they recognize at least as clearly as I do how powerful this concept could be. However, it’s not implemented yet, which means I don’t get to play with it. Too bad; the possibilities for (creative) destruction boggle the mind.
PeopleAggregator is a great idea
Like everyone else, I’ve recently heard buzz about PeopleAggregator. Though on the surface it’s simply a standards-based social networking service, upon further investigation it’s much more.
First, it’s embracing the URL-based lightweight ID management technologies I’ve posted about previously, which is another step in the direction of de facto standardization. Second, it’s building tools and standards for decentralized hosting and portability of all sorts of user information, not just identity and social network. The presentation materials on the site now specifically call out file and media storage as additional use cases.
What’s important is that PeopleAggregator isn’t just offering to host these services; that’s been done before. PeopleAggregator is trying to catalyze a distributed, decentralized, open network/grid/mesh by which identity, social network, and data can be created, manipulated, and exchanged in both human- and machine-consumable forms.
I can’t wait to learn more. Perhaps I won’t have to build the Grand Unified Storage Architecture all by myself after all…
Weekend project idea: LID/OpenID/Yadis ASP.NET Membership Provider
Another weekend project idea is to investigate the implementation of an ASP.NET Membership Provider that supports LID/OpenID/Yadis identities. There’s an existing OpenID implementation for .NET, implemented in Boo, but you have to wire it up to your app yourself. A membership provider would be more drop-in, assuming the lightweight URL-based identity idioms can be shoe-horned into the fairly narrow membership provider API.
Refining my understanding of new ID technologies LID/OpenID/Yadis
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
- to enable those projects to work independently, but aligned, so overlap of work is avoided, and the parts developed by different projects can fit
- 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.
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.orgoridentity20.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.