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)

  1. How to authenticate you (e.g. your password).    (1LL)
  2. Where your profile data is located.    (1LM)
  3. 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)

Advocacy Developers Convergence in San Francisco

I enjoyed the Advocacy Developers Convergence last week, where about 40 super-passionate folks — mostly developers of advocacy tools — gathered in the Presidio to discuss ways to collaborate. Among those represented were Advo Kit, CivicSpace, IndyVoter, Groundspring, Identity Commons (one of three hats I was wearing), and many, many others. Aspiration organized and facilitated the event, and Blue Oxen Associates provided the Wiki.    (1JJ)

While the scope of projects represented — most of which were open source — impressed me, I was really taken by the collective energy in the room. These weren’t your average techies. These folks cared about improving the world, and their passion was palpable. Even the most hardened cynic would have walked away from that gathering with at least a smidgen of hope about our future.    (1JK)

I wore three hats. First, I was there to facilitate Wiki usage during the event. In this regard, I basically did nothing. Most of the people there were already highly Wiki-literate, and the rest picked it up quickly. Second, I was there to help Fen Labalme talk about the Identity Commons system and to identify other potential early adopters. Third, as always, I was there both to share what I knew about collaboration and to observe and learn from others. I was particularly interested in watching Gunner’s (Allen Gunn) facilitation technique. Gunner, who recently took over Aspiration along with Katrin Verclas, used to work for Ruckus Society, and has facilitated a number of interesting events, including several international Open Source boot camps.    (1JL)

Mapping the Space; Emergent Goals    (1JM)

One of Aspiration’s stated goals for the event was to begin mapping the space of advocacy tools. That begged the question: What exactly is an advocacy tool? It was a question most of us conveniently avoided. Some tools are clearly and specifically designed for supporting the needs of grassroots advocacy, such as email campaigns, volunteer organizing, and friend-raising. Several (most?) other tools used by advocacy organizations (such as MoveOn) have multiple applications — mailing lists, contact databases, and so forth.    (1JN)

We never reached a collective solution to this problem, but we seemed to be moving in the direction that Blue Oxen has already gone in determining how to map the collaborative tool space: Map functions (or patterns) rather than tools, and show how different tools can be used for different functions.    (1JO)

The other goal for the event was to identify and pursue opportunities for collaboration among the participants.    (1JP)

Aspiration’s stated goal for the event was to begin mapping the space of advocacy tools and to facilitate collaboration among the participants. A number of interesting projects emerged:    (1JQ)

  • Several people expressed interest in incorporating the Identity Commons protocols into their tools for Single Sign-On and Data Sharing (all with user privacy built-in).    (1JR)
  • An Open Source legislative contact database that activist groups could freely use.    (1JS)
  • Face-to-face code (and other) sprints. A small group is planning a VoIP sprint somewhere on the East Coast later this summer.    (1JT)
  • Internationalization working group, basically a support group for folks internationalizing their code. One of the great things about the attendees was that international representation was reasonably good. There were folks from Poland, Uruguay, and Canada, and people dealing with many other countries.    (1JU)
  • Technical outreach to organizations. Connecting these groups with the right tools, and explaining to them the virtues of open source. A group is planning to use a Wiki to generate a Nonprofit Open Source Almanac.    (1JV)

The challenge with events like these is sustaining the energy afterwards. Face-to-face events that go well are often victims of their own success, because they create a level of energy that is simply impossible to match online. That said, there are certain things that can help assure continued collaboration:    (1JW)

  1. Individual commitment to shared goals.    (1JX)
  2. Group memory.    (1JY)
  3. Shared workspace.    (1JZ)

This group has all of the above. People were super action-oriented. Tasks were getting accomplished on the spot. Requests for information were often followed a few seconds later by shouts of, “It’s in the Wiki” — music to my ears. In general, folks who easily acclimate to Wiki usage — as this group did — are already inclined to share knowledge and collaborate.    (1K0)

Facilitation    (1K1)

Gunner is both high-energy and easy-going. He’s got a goofy, infectious grin and is quick to drop gut-busting witticisms. It would be easy to ascribe the effectiveness of his events to his personality, but that would be largely inaccurate. A well-meaning and amiable person can easily kill the energy of a group by under- or over-facilitating. Gunner has a strong fundamental understanding of self-organizing systems and very good instincts for when to sit still and when to perturb.    (1K2)

Every good event I’ve attended with large groups of people followed MGTaylor’s Scan Focus Act model, and this was no exception. The beginning of these events are always about discovery and Shared Language. Discovery (or “scan”) is inherently messy and unsettling, but when done correctly, “action” naturally emerges. Most bad events I’ve attended are bad because they try to skip this first step.    (1K3)

Each day consisted of several breakout sessions with groups of three to five people, followed by report-outs, yet another pattern of effective face-to-face events. The agenda for the later breakouts emerged as the event unfolded.    (1K4)

The first day began with a game called A Strong Wind, which was an excellent way both to build energy and to get a sense of who was there. Following that and at the beginning of the subsequent days were In Or Out exercises, a way to get a sense of everybody’s mood and to build individual commitment to the collaboration that would follow. The first day, Gunner asked people to describe their moods in one word. The second day, he asked for colors that described their mood. The third day, he asked people to describe the most beautiful place they knew, be it a geographical location (e.g. California) or a situation (e.g. time spent with family, friends).    (1K5)

As a way to accomodate a number of demos, Gunner organized a Speed Geeking session on Tuesday morning. I’m not sure yet whether I liked it or not. On the one hand, I enjoyed the interaction and the energy. On the other hand, it was incredibly draining for the people giving demos (including me), who also missed out on the demos happening simultaneously to theirs. I think the Planetwork Forum model of eight demos — four minute presentations (PowerPoint highly discouraged) and two minutes of Q&A — followed by two hours of unstructured socializing/networking is more effective, but I’m not ready to discount Speed Geeking entirely.    (1K6)

Good Folks    (1K7)

The most important prerequisite for good events and good collaboration is having the right mix of people. I really like MGTaylor’s strategy for achieving this: The larger the group, the more likely you are of having that mix. This group was relatively small (40 people), and I suspect that Gunner and Katrin’s people instincts played a huge role in making sure we had a good group.    (1K8)

I hate to single people out, because I really liked and was very impressed by everybody there. Nevertheless, I can’t help but mention two people. First, I was glad to finally meet Kellan Elliott-McCrea, the author of Laughing Meme, in person. Time and again, I meet folks whose blogs I enjoy regularly and whose work I admire, and I constantly walk away even more impressed with their authenticity and their decency. It’s how I felt when I first met Ross Mayfield and when I met Seb Paquet, and I felt it again when I met Kellan.    (1K9)

Second, I was glad to meet Mark Surman, who’s based in Toronto. Mark founded the Commons Group several years ago, which is very similar in spirit to Blue Oxen Associates. I meet a lot of like-minded people, but it’s a rare treat to meet someone doing similar work. Mark and his group are doing great stuff. They’re an organization folks should keep their eyes on.    (1KA)

Tim Bray on Purple Numbers

I’ve long been a fan of Tim Bray‘s work, and although we had never crossed paths before, I had always assumed it would be instigated by me making some comment about something he had done or written about. (A few months back, I emailed him about ballparks in the Bay Area, because we seem to share a love for the sport, but that doesn’t count.) So I was surprised and pleased to see that Tim had made first contact and had (temporarily, as it turned out) implemented Purple Numbers on his blog. Not surprisingly, this is starting to generate some talk in the blogosphere. In particular, see:    (1G9)

Chris has done an excellent job of quickly addressing many of these issues. I’ll just toss in a few thoughts and references here and will look forward to more feedback.    (1GE)

Stable, Immutable IDs    (1GF)

Several people have pointed out that the IDs need to be stable. In other words, as the paragraphs move around or as new ones are added or deleted, the IDs stick to their original paragraphs. This was a fundamental motivation for Engelbart’s statement identifiers (SIDs), which we have renamed node identifiers (NID).    (1GG)

Both Purple (which needs updating) and PurpleWiki handle this correctly. You’ll notice that the addresses are stable on my blog and on Chris’s, as well as on all of the PurpleWiki installations (e.g. Collab:HomePage, PurpleWiki:HomePage). It’s because we use plugins for our respective blog software that call PurpleWiki‘s parser, which manages NIDs for us.    (1GH)

By using PurpleWiki to handle the purpling, blog content has NIDs unique to both the blog and the Wiki, which allows us to do fun stuff like transclude between the two. We get a similar effect with perplog, the excellent IRC logger written by Paul Visscher and other members of The Canonical Hackers. For example, check out Planetwork:Main Page and the chat logs over there.    (1GI)

Mark Nottingham noted that even if the NIDs are stable in the sense that they are attached to certain paragraphs, the paragraphs themselves are not semantically stable. This is a point on which I’ve ruminated in the past, and we still don’t have a good solution to it.    (1GJ)

History and Other Worthy Projects    (1GK)

I’ve written up my own brief history of Purple Numbers, which fills in some holes in Chris’s account. In it, I mention Murray Altheim‘s plink. Plink is no longer available on the net, because it has been subsumed into his latest project, Ceryle. Everything that I’ve seen about Ceryle so far kicks butt, so if you’d like to see it too, please drop Murray an email and encourage him to hurry up and finish his thesis so that he can make Ceryle available! You can tell him I sent you, and you can forward him the link to this paragraph; he’ll understand.    (1GL)

Matt Schneider is the creator of the PurpleSlurple purple numbering proxy, which will add Purple Numbers to any (well, most) documents on the Web. PurpleSlurple deserves a lot of credit for spreading the meme.    (1GM)

Mike Mell implemented Purple Numbers in ZWiki for last year’s Planetwork Conference (see ZWiki:ZwikiAndPurpleNumbers), which in turn influenced the evolution of Purple Numbers in PurpleWiki. Mike and Matt have both experimented with JavaScript for making the numbers less intrusive.    (1GN)

The latest version of the Compendium Dialogue Mapping tool exports HTML maps with Purple Numbers.    (1GO)

In addition to Murray, Matt, and Mike, several other members of the Blue Oxen Associates Collaboration Collaboratory have contributed to the evolution of Purple Numbers, especially Peter Jones, Jack Park, and Bill Seitz. In addition to his contributions to the technical and philosophical discussions, Peter wrote the hilarious Hymn of the Church Of Purple and excerpts of the Book of the Church Of Purple.    (1GP)

Finally, many good folks in the blogosphere have helped spread the meme in many subtle ways, particularly those noted connectors Seb Paquet and Clay Shirky.    (1GQ)

Evangelism and The Big Picture    (1GR)

Okay, that last section was starting to sound like an award acceptance speech, and although none of us have won any awards, one thing is clear: The contributions of many have vastly improved this simple, but valuable tool. I’m hoping that momentum picks up even more with these recent perturbances. I’m especially heartened to see experiments for improving the look-and-feel.    (1GS)

I want to quibble with one thing that Chris Dent said in his most recent account. (When we have distributed Purple Numbers, I’ll be able to transclude it, but for now, you’ll just have to live with the cut-and-paste):    (1GT)

When he [Eugene] and I got together to do PurpleWiki, we were primarily shooting for granular addressability. Once we got that working, I started getting all jazzed about somehow, maybe, someday, being able to do Transclusion. Eugene was into the idea but I felt somehow that he didn’t quite get it. Since then we’ve implemented Transclusion and new people have come along with ideas of things to do that I’m sure I don’t quite get, but are probably a next step that will be great.    (1GU)

There are many things I don’t quite get, but Transclusions are not one of them, at least at the level we first implemented them. That’s okay, though. Ted Nelson felt the same way about my understanding of Transclusions as Chris did, although for different reasons. (And, I suspect that Ted would have had the same opinions of Chris.) I mention this here not so much because I want to correct the record, but because it gives me an excuse to tell some anecdotes and to reveal a bit about myself.    (1GV)

Anyone who knows Doug Engelbart knows that he complains a lot. The beauty of being an acknowledged pioneer and visionary is that people pay attention, even if they they don’t think much of those complaints. When I first began working with Doug in early 2000, I would occasionally write up small papers and put them on the Web. Doug would complain that they didn’t have Purple Numbers. At the time, I recognized the value of granular addresses, but didn’t think they were worth the trouble to add them to my documents. I also didn’t think they were the “right” solution. Nevertheless, because Doug was Doug, I decided to throw him a bone. So I spent a few hours writing Purple (most of which was spent learning XSLT), and started posting documents with Purple Numbers.    (1GW)

Then, a funny thing happened. I got used to them. I got so used to them, I wanted them everywhere.    (1GX)

A few people just get Purple Numbers right away. Murray was probably the first of those not originally in the Engelbart crowd to do so; Chris followed soon thereafter, as did Matt. The vast majority of folks get the concept, but don’t really find them important until they start using them. Then, like me, they want them everywhere. Getting people past that first step is crucial.    (1GY)

A few nights ago, I had a late night conversation with Gabe Wachob (chair of the OASIS XRI committee) on IRC. (This eventually led to a conversation between Chris and me, which led to Chris’s blog entry, which led to Tim discovering Purple Numbers, which led to this entry. Think Out Loud is an amazing thing.) Gabe knew what Purple Numbers were, but hadn’t thought twice about them. I had wanted to ask him some questions about using XRI addresses as identifiers, and in order to do so, I gave him a quick demonstration of Transclusions. The light bulb went off; all of a sudden, he really, truly got it.    (1GZ)

Richard Gabriel, one of our advisors, is well known for his Worse Is Better essays (among other things). I think Purple Numbers are an outstanding example of Worse Is Better. They fulfill an immediate need, and they cause us to think more deeply about some of the underlying issues. I’d like to see Purple Numbers all over the place, but I’d also like to see a group of deep thinkers and tinkerers consider and evolve the concept. It’s part of a larger philosophy that I like to call The Blue Oxen Way.    (1H0)

This last point is extremely important. Chris has thankfully been a much more enthusiastic evangelist of Purple Numbers than I have, and in the past he’s called me “ambivalent” about Purple Numbers. That’s not so far from the truth. It’s not that I’m any less enthusiastic about Purple Numbers themselves — I am a card-carrying member of the Church Of Purple, and the current attention and potential for wider usage thrill me. However, I’m cautious about evangelizing Purple Numbers, because I don’t want people to get too caught up in the tool itself and forget about the bigger picture. It’s the reason I didn’t mention Purple Numbers at all in my manifesto.    (1H1)

At the Planetwork forum two weeks ago, Fen Labalme, Victor Grey, and I gave the first public demo of a working Identity Commons Single Sign-On system. We were tickled pink by the demo, which to everyone else looked just like any other login system. The reason we were so excited was that we knew the system used an underlying infrastructure that would eventually enable much greater things. The demo itself, unfortunately, didn’t convey that to anyone who didn’t already understand this.    (1H2)

I’m probably a bit oversensitive about this sort of thing, and I’m constantly seeking better balance. But it’s always in the back of my mind. When I talk to people about Blue Oxen Associates, I usually spend more time talking about the sociological aspect of collaboration rather than the tools, even though I have plenty to say about the latter. Can Purple Numbers make the world a better place? I truly, honestly, believe that they can. (This is a topic for another day.) But when I see groups that excel in collaboration (or conversely, those that stink at it), Purple Numbers are usually the furthest thing from my mind. Much more important is the need to identify and understand these patterns of collaboration (of which tool usage is an important part).    (1H3)