The Identity Commons i-name fundraiser got Slashdotted today. I haven’t been all that impressed by the comments on Slashdot in the past, but they were useful this time in revealing a fundamental misunderstanding about the Identity Commons infrastructure (and a problem with its messaging). Identity Commons is not centralized. This is not a non-profit version of Microsoft Passport. It was designed from the ground up to be fully distributed. See Fen Labalme‘s post for a deeper explanation and some additional comments on the Slashdot responses. (7VR)
Identity Commons: Empowering the Individual
At last month’s Planetwork Conference, Blue Oxen Associates proudly demonstrated the first Identity Commons system for Single Sign-On. Conference attendees could access the PlaNetwork Wiki (which we hosted), Living Directory (for online profiles), Neo Society (a social networking site), and the conference site itself, all with one username and password. Although I’ve mentioned this work in passing on a few occasions, I’ve neglected to explain exactly what Identity Commons is about. (1LG)
In short, we’re building a system where individuals have full control over their digital profiles. It’s an idea that was heavily inspired by the Augmented Social Network paper that was published last year. (1LH)
Here’s how the system works. Individuals have one or more global identifiers — e-names — and Identity Brokers associated with their e-names. (1LJ)
These Identity Brokers know three things about you: (1LK)
- How to authenticate you (e.g. your password). (1LL)
- Where your profile data is located. (1LM)
- Link contracts that define who can access your data and what they’re allowed to do with it. (1LN)
The latter two points are critical, because they differentiate this system from efforts such as Liberty Alliance and Microsoft Passport. Identity Brokers know where your data is, but they don’t necessarily store the data themselves. There is no central repository. Your data can be completely distributed across multiple sites. The only way sites can access your data is if you give them permission to do so via the link contracts. (1LO)
There are two components to all of this: the technology and the social/legal agreements. The latter is the hard stuff. It’s not enough to build systems that can negotiate and agree on contracts; the organizations behind these systems have to respect these contracts. That’s why Identity Commons exists. Identity Commons is a member-owned Chaordic Organization founded by Owen Davis, whose primary purpose is to work out and enforce these social and legal agreements. (1LP)
e-names and XRI (1LQ)
I’ll have more to say about social agreements another time, most likely in response to other people’s queries and comments. In the meantime, here are a few more technical details. (1LR)
E-names are based on an OASIS standard called XRI — eXtensible Resource Identifiers. Think of them as extended URIs. E-names are (mostly) persistent, globally unique, globally resolvable identifiers. E-names have multiple forms, but the ones most people will see are: (1LS)
=eekim @blueoxen*eekim (1LT)
The first form is part of a flat, global namespace (as specified by “=”). Sometime in August, individuals will be able to register global e-names as part of an Identity Commons fundraiser. The second form is an e-name associated with an organization (as specified by the “@”). That’s my actual, working e-name. (1LU)
E-names are associated with e-numbers, which are persistent, numerical addresses. (Think IP addresses, except persistent.) You can associate multiple e-names with an e-number. In other words, requests for the email address of =eekim and @blueoxen*eekim would go to the same place, because they would both be associated with the same e-number. (1LV)
You can use e-names for Single Sign-On, and you can also use them for data sharing and synchronization. For example, an e-commerce site could regularly request your latest contact information from your Identity Broker via your e-name, and it would get it — provided you give them permission. That information might be stored at another e-commerce site or at a social networking site or at a gaming community to which you belong. Neither the e-commerce site nor the Identity Broker care where that information lives. (1LW)
Why do users need to remember yet another identifier format? Why not use email addresses? That would defeat the purpose of what this system is supposed to be about. Your email address should be your information, and you should control how it is used. If you just gave your email address out indiscriminately, that leaves you vulnerable to spam, which is the status quo. If you passed out an e-name, you couldn’t be spammed — folks would have to get your explicit permission to get your email address. (1LX)
Why not use URIs? Two reasons: They’re not persistent, and they’re not user-friendly. One of the nice things about working with the OASIS XRI Technical Committee is that they are accomodating. None of the other TC members have had to worry about identifiers being user-friendly, because only software has seen those identifiers. However, they have already made some changes in their 1.1 spec to accomodate our desire for the identifiers to be more user-friendly. (1LY)
Single Sign-On (1LZ)
We’ve got the basic XRI resolution working and a Single Sign-On system working on top of that. The protocol is available on the Identity Commons Wiki. The protocol looks just like any other Single Sign-On protocol, and in fact, will most likely resemble the Liberty Alliance and SAML spec even more closely over time. Our intention is to use what’s good and available, not to reinvent the wheel. (1M0)
I wrote the Perl implementation of the client library (XDI::SPIT), and there are currently PHP and Java versions as well. One way you can contribute immediately is to develop implementations in other languages (Python anyone?). The other way is to integrate these libraries into your tools. Note that all of this stuff is technically pre-alpha. It will change. That said, the APIs should remain fairly stable. It’s good enough for people to start using immediately. (1M1)
Link Contracts and XDI (1M2)
The most important pieces of all this are the data interchange protocol and the link contracts format. Fen Labalme, the chief architect of the Identity Commons project, is working hard on this right now, with help from Victor Grey, who implemented the first Identity Broker and also founded Living Directory. (1M3)
Both of these pieces will be built on top of XDI (XRI Data Interchange), an XML application that is currently going through the standardization process. This is not something that’s being designed from scratch. XDI is based on previous work developed by One Name (now Cordance). (1M4)
How does FOAF fit into all of this? The short answer is, “It will.” Think of what we’re doing as FOAF with authentication and link contracts. To be brutally honest, I can’t accurately assess this question until I see the XDI stuff, but I see no reason why XDI won’t be able to interoperate with FOAF, and vice versa. In fact, I’ll be gathering with Fen, Victor, and some other folks tonight to start exploring that possibility. (1M5)
What’s Next? (1M6)
This is without a doubt a grassroots effort, but there’s some serious technical and intellectual weight behind it. The technical specs are based on OASIS standards, with representatives from major corporations. The global registry for e-names will be operated by Neustar, which operates the .biz and .us registries among many others. Several of the people working on Identity Commons participated in Liberty Alliance. (1M7)
Realistically, Amazon.com and Visa aren’t going to adopt this overnight. Once user demand passes a certain threshold, however, companies are going to have to start paying serious attention. Right now, users don’t have a choice. It’s give up your data or nothing. Once users realize they have a choice, I firmly believe that people will opt for privacy over the status quo. (1M8)
Our strategy for getting to that threshold is to target civil society groups. So far, response has been outstanding, and I hope that this blog entry generates additional interest. Single Sign-On and data sharing solves an immediate technical need, and the fact that it does this while respecting individual privacy is a huge bonus. (1M9)
What’s my role in all of this? Blue Oxen Associates is about improving collaboration for a better world. This system fits the bill perfectly. Not only does it promote tool interoperability, it does so in a way that will help improve people’s lives. I’m proud to be one of the project’s many contributors right now, and I’m proud that Blue Oxen Associates will be one of the first large-scale users of the system when our collaboratories go live next year. (1MA)
If you want to help, more information is available at the Identity Commons Wiki. (1MB)
Manifesto Summit; More Responses
In the two weeks since I last responded to feedback about my manifesto, there have been several other interesting comments. Before I respond to those, I want to make a couple of announcements. First, this Thursday (April 29), I’m presenting the manifesto at SRI‘s Artificial Intelligence Center at 4pm in Menlo Park, California. The talk is free and open to the public. (1E2)
Second, Blue Oxen Associates is once again helping design this June’s Planetwork Conference in San Francisco. In addition to the usual lineup of great speakers, including TrueMajority‘s Ben Cohen (the “Ben” in Ben & Jerry’s), there will be a parallel interactive component. The format will be self-organizing, in some ways resembling Open Space, and is being designed by Tomorrow Makers (Gail Taylor and company) and Blue Oxen Associates. The purpose of the interactive component is to give people some basic infrastructure to discuss and work on topics of interest and also to enable different groups to connect and intertwingle. (1E3)
I want to build on some of the interest that the manifesto has generated, and the Planetwork Conference offers a perfect venue to do so. I’d like to propose a summit at this June’s conference for everyone interested in pursuing greater interoperability between collaborative tools. If you’d like to attend, drop me an email, register for the conference at the web site, and rank the topic. I’ll followup later with more details. (1E4)
On to the comments. (1E5)
Empowering the Programmer (1E6)
Several people forwarded Bill De Hora’s response to my manifesto. Bill quoted Chris Ferris: (1E7)
“Interoperability is an unnatural act for a vendor. If they (the customer) want/need interoperability, they need to demand it. They simply cannot assume that the vendors will deliver interoperable solutions out of some altruistic motivation. The vendors are primarily motivated by profit, not good will.” (1E8)
then added: (1E9)
There’s a class of articles that tend to look to assign blame to programmers for what’s wrong with software…. I find them ferociously, willfully, ignorant on how software actually is conceived, designed, marketed, built and sold. Blaming programmers is intellectually slothful. We are, and let’s be clear about this, decades past the time the blame could be laid squarely at the programmers feet. (1EA)
A Manifesto for Collaborative Tools veered close to that, while never quite getting there – exhorting developers, with only token gesture as to how decisions about software are made. Software is a complete commercial ecosystem that extends far beyond hacking code. Ironically like its observation of the semantic web, this manifesto is unlikely to take hold because it does not address the real issue, which is the marketplace and not technique. This failure in analysis is all the more frustrating as I agree with the essential sentiment expressed (we need better tools, now). Plus the writing is wonderful. (1EB)
My essay isn’t about blame, it’s about empowerment. Bill is right in that I didn’t thoroughly discuss the role of the marketplace. That comes next. The first step, though, is awareness. I’ve learned a lot from Doug Engelbart over the past four years, but the two lessons that stand out most in my mind are: 1. Making the world a better place is a reasonable career goal; and 2. The first step towards achieving this is to think bigger. Very few people — least of all, programmers — understand or want to understand collaboration well. Start with this problem first, then we can talk about the marketplace. (1EC)
Okay, so the cat’s out of the bag. I’m a closeted idealist. But the reason my idealist side is in the closet is that I’m also a realist. Less (or at least, as much as necessary) talking, more walking. I founded Blue Oxen Associates to help achieve this goal, and so in some ways, our continued existence and progress will be a measure of whether or not this vision can be achieved. (1ED)
So, how do we deal with the vagaries of the marketplace when it comes to interoperability, especially in light of Chris’s comments? Chris provides the solution. The solution has to start from the bottom-up — the users. (1EE)
The Identity Commons model (which fits right into the overall framework I describe) is a good example of this approach. These folks want to take on Microsoft Passport and Liberty Alliance. The goal is to provide an alternative digital identity infrastructure where individuals retain control over their information. Realistically, Identity Commons will not be successful by marching into the offices of various vendors with a technical spec in hand and pleading for it to be implemented. Their approach is to target a market sector that isn’t currently being addressed — civil society. Once users there recognize the utility and desirability of the infrastructure, they’ll demand it elsewhere. (1EF)
Beyond Collaborative Tools (1EG)
A few people observed that the principles espoused in the manifesto applied to areas beyond collaborative tools. Jamais Cascio said: (1EH)
Replace “tools” with “movements” (and “tool builders” with “activists”) and Kim’s argument clearly applies to not just to those who are making the technology, but also to those who are using the technology to build a better world. (1EI)
In his OLDaily newsletter, Stephen Downes suggested that the principles “are as applicable to e-learning software as collaboration tools.” (1EJ)
There’s a good reason for this. The steps I described apply to almost any collaborative scenario, be it activism or learning. I was especially happy to see Jamais’s comments, because that is ultimately what this is all about. (1EK)
Semantic Web Evangelists (1EL)
A few people who read early drafts thought that some Semantic Web folks might take offense at some of the things I said. For the most part, folks have been very positive. W3C’s Dan Connolly, however, expressed some frustration on the #rdfig IRC channel about my claim that Semantic Web evangelists are more machine- than human-centric in their pitches. (1EM)
Argh! Which evangelists? I’m certainly spending 99.9% of my time working on the balance between effort and reward for people. (1EN)
Tim Berners Lee for one. Tim and coauthors James Hendler and Ora Lassila opened their May 2001 piece in Scientific American on the Semantic Web with a science fiction scenario where automated agents collaborated with each other to schedule a doctor’s appointment. That scenario echoed tales of Artificial Intelligence’s past. (1EO)
Now I realize I just said that we need to think bigger, that the audience for this article was broad, and that the authors wanted to open with something sexy. I also don’t mean to pass say that Tim or James or Ora are not people-centric in their philosophy or work. I’m saying that these scenarios are not actually people-centric, even though they might seem that way on the surface, for reasons cited in the manifesto. That’s a problem, because a lot of people missed the point. This is less the case today than it was three years ago, but I worry that the damage has already been done, and the end result was that some of the outstanding work that has happened over the past three years (work to which I refer in the manifesto) hasn’t gotten the credit it deserves. (1EP)
Italian Translation (1EQ)
Luigi Bertuzzi is currently working on an Italian translation of the manifesto. You can read the email he sent to me and follow his work. (1ER)
Fen Labalme on SharedID
Fen Labalme posted some comments on SharedID, an authentication service for sharing personal information across different web sites: (16M)
While this sounds promising, unfortunately SharedID is exactly the wrong thing. First off, it’s centralized (ug) – all authentications go through the SharedID site (another hideout for Big Brother?). Further, and this is a problem with FOAF in general, profile sharing is at FOAF-file granularity, which means all my info, friends, etc. in my FOAF file will get shared once the cantralized authentication happens. I’ve heard some of the FOAFsters talking about how one might have several FOAF files, but then you’ve got data replication problems. (16N)
Fen is the primary architect of the Identity Commons protocols. Identity Commons is a chaordic organization founded by Owen Davis that is designing and building an infrastructure — both technical and legal — for federated digital identities and profile sharing. How is this different from Microsoft Passport or Liberty Alliance? Identity Commons is designing its protocols so that individuals retain control over their personal information. (16O)
I think Identity Commons is a wonderful project and Fen is the perfect technical lead. He’s been working on privacy issues for 25 years and is the founder of the OpenPrivacy initiative. Blue Oxen Associates is a member of Identity Commons and plans on being one of the first sites to use the protocols. (16P)