Equals Drummond

When I told a friend that I was “adding yet another hat” by taking on the Interim Executive Director role at the Information Card Foundation, he said I had so many hats it reminded him of this children’s book. I haven’t read it (and probably won’t — my kids are into Da Vinci Code and Ender’s Game now).

Quite a few of those hats came from helping start  non-profits in the Internet identity industry. However this is the first time I’ve stepped into the E.D. role, and all those hats are part of the reason. I really do feel it’s time to move the industry towards convergence. I believe a selector-based identity model can get us there, and I’ll be reaching out to all the communities I’ve been part of — and others I haven’t yet been part of — to help get us there.

Look for lots of new things coming out of the ICF in the next few months.

Paul’s done a post about his writeup of password cards on the Higgins wiki. IMHO this is  a long overdue idea for how an identity client (”selector” in information card terms) can overcome the chicken-and-egg adoption problem.

Selectors are like browsers – the more of them people start using, the more sites become card-enabled. It won’t work the other way around. So the trick is issuing i-cards that provide real end-user value before sites start issuing them for login, cross-domain claims transfer, etc.

More about that soon.

I’m going to start referring to her as the Venn Queen. Eve Maler has done another Venn diagram, this time to show the relationship of whole areas of the “user-centric” sphere of activities. Going into Digital ID World next week, I’ll use this to help orient conversations around why there needs to be a simple, consistent way for users to control and manage identity and data sharing relationships no matter what site, application, or type of relationship is involved. We just need to build it! (hint: OpenID + relationship cards + XDI =

So much for the naive thought that I’ have time at the Burton Catalyst conference last week to finally blog about two subjects near and dear to my heart that I knew would be covered at the conference. It backfired because they were too topical — all available time was consumed by related conversations.

I did manage two posts about the first one — launch of the Information Card Foundation — about which there will be much more to say in the coming months.

But the other one — relationship cards — is long overdue. I first promised to blog more about r-cards after both doing a demo and hearing Bob Blakley’s fantastic talk on The Relationship Layer at Spring IIW in May. Then Joe Andrieu and Eve Maler both posted about them and asked me to add more details. Then I fell into an abyss of work (actually building this stuff) from which I have yet to climb out.

But Bob’s new talk on The Relationship Layer at Catalyst last week, followed by Eve’s talk on The Care and Feeding of Online Relationships, plus the upcoming VRM (Vendor Relationship Management) Workshop at the Harvard Berkman Project on July 14-15, compels me to finally post about why I believe r-cards may be what finally pushes Internet identity across the chasm.

—-

First: what is a relationship card (”r-card”)? At the most general, the definition I would offer is:  “a digital object instantiating a mutually authorized data sharing relationship between two or more parties on a network”. The abstraction is intentional: the generic concept of an r-card, like the generic concept of a folder, a link, or a network, can take different forms in different implementations.

To take a step more towards the concrete, the concept of an r-card was conceived at the Higgins Project as a new kind of information card (i-card). For their part, i-cards were first conceived by Kim Cameron and team at Microsoft, where they have been promoted as a key element of Microsoft’s vision of an identity metasystem. These memes subsequently took hold at Higgins, among other places, where the concept of an i-card was generalized to the definition that currently appears on Wikipedia:

An i-card is a rectangular icon displayed in the user interface of an identity selector (sometimes also called an identity agent) that represents a digital identity–a set of claims about some entity (typically a person, but it could also be an organization, application, service, digital object, etc.).

The i-card metaphor is based on familiar physical identity credentials like business cards, credit cards, library cards, association cards, driver’s licenses, badges, etc. However, just as computer file folders are similar to but more powerful than real-world file folders, i-cards are similar to but more powerful than real-world identification cards. The i-card metaphor is identical to the information card metaphor used in numerous identity selectors.

So what distinguishes an r-card from a plain-vanilla i-card? The capability to instantiate an ongoing data sharing relationship. In other words, a standard i-card invokes a one-time exchange of a set of digital claims using a security token. An r-card, by contrast, exchanges a set of claims and associated policies that enables both parties to continue to share other information over time, e.g.:

• Updates to the initial values of the claims
• New claims
• Permissions and controls over communications via other channels
• Changes to the r-card itself

A simple analogy would be: a standard i-card is like showing your driver’s license to a bartender to prove you are of age: you use it once and put it away. An r-card is much more like giving a business card to an associate or a customer: it is an invitation for an ongoing relationship via the address(es) and other information shared on the card.

—-

But while instantiating a private data sharing channel by exchanging a digital object is cool — sort of like RSS on steriods — for some reason that aspect alone doesn’t capture the real power of r-cards. Case in point: after a live participatory enactment of how r-cards work with audience members during the first day of IIW in May (all based on business cards, scissors, and string — no computers involved), several audience members came up to me and said, “Why didn’t you show this years ago? Anyone can understand the value of r-cards. They are the most compelling use case we’ve ever heard for all this Internet identity stuff.”

After that experience, even I was trying to grok what it was that made r-cards so intuitive and attractive. I was having trouble putting it into words until I was listening to Bob Blakley’s talk on The Relationship Layer again at Catalyst last Wednesday morning. At the midway point, he put up an “intermission” slide with five bullets summarizing the first half of his talk. Two of them hit me like they were shot out of a gun:

Relationship is the context which protects the security and the privacy of identity information.

Identities are built in the context of relationships.

This Copernican revolution Bob was proposing — that relationship is really the sun around which identities orbit — suddenly made me look at r-cards in a new way. It wasn’t just that r-cards enabled bidirectional data sharing. It was that r-cards create the context for a relationship. And by doing so, they call forth all social dynamics of real world relationships that are often missing on the Web today. Dynamics like:

“I am more inclined to trust you because we both know if you break that trust, I can terminate the relationship.”

“Of course you wouldn’t share our private shared information outside our relationship — friends always respect each other’s privacy.”

“Each of us shares information in proportion to the value it brings to the relationship — both of us are incented to build that value.”

That’s why people find r-cards so intuitive — they are a way of creating and managing the same balanced, mutually-controlled, give-and-take between two parties over a network that we have in the real world relationships we manage every day. And they can apply to any form of relationship — person-to-person, person-to-community, person-to-employer, person-to-vendor, etc.

—-

Okay, okay, at this point I know all the geeks are screaming “enough with the soft stuff — where’’s the technical beef??” I don’t want to duck that question, because as I’ve told Joe Andrieu, chair of the VRM Standards group, I’m knee-deep in it every day. But with the limited time I have left for this post, I can only give the high-level recipe we are currently putting to the oven test at Parity and the Higgins Project:

• Take a conventional i-card as currently defined by the Microsoft ISIP documents (which can’t get into an SDO fast enough).
• Add an OpenID — or to be precise, an identifier on which you can do XRDS discovery to locate a data sharing endpoint. In Higgins we call this form of identifier a UDI (Universal Data Identifier).
• When the r-card recipient receives the r-card, use the UDI to perform XRDS discovery of an Internet data sharing protocol supported by both parties.
• Intiatite data sharing via the selected protocol, using the UDI and other supporting claims on the r-card as necessary.

Of course readers of this blog know what data sharing protocol I have in mind: XDI — specifically the XDI RDF model. It’s particularly well-suited to r-cards because XDI link contracts provide a portable, machine-readable description of the mutually-agreed data sharing controls. But it’s important to clarify that any data sharing protocol supported by both parties will work. As an example, Asa Hardcastle showed a wonderful demo of OpenID-enabled Liberty ID-WSF at Spring IIW, and we are deep in conversations about how UDI discovery for ID-WSF endpoints can work. OpenID Attribute Exchange is another option because any OpenID identifier can already support XRDS service discovery.

—-

I know that’s only the tip of the iceburg, but this is a huge topic that I’ll be posting about for months. For example, in Bob’s talk he showed a relationship schema that he, Lori Rowland, and their colleagues at Burton group have already started to develop. I eagerly anticipate working with them to map that to XDI link contracts to make sure we have all the bases covered.

And I’d like to find time to start posting some example r-card XDI messages using super-simple X3 format to illustrate common use cases like the VRM personal address manager.

But right now I’m going to work on maintaining a particularly important relationship — with my wife — by getting to bed!

The new announced Information Card Foundation has nine community board members, and I’m pleased to report they all have a keen sense of humor. Case in point: Pam Dingle’s bio on the Board of Directors page:

Pamela Dingle

Pamela Dingle is an Enterprise Identity Consultant at Nulli Secundus Inc . She is also the founder of the Pamela Project, an open source project dedicated to creation of information card relying party modules & plugins for common web frameworks. Pamela blogs at http://eternaloptimist.wordpress.com and is an active participant at the OSIS Identity Commons Working Group supplying tests and maintaining the wiki for Interoperability events at various conferences. Pamela enjoys adding URLs to every sentence she writes (http://heresabunnywithapancakeonitshead) and hopes you click on them all.

YAF? (“Yet Another Foundation?”) Some in the identity community have had that reaction to the announcement of the Information Card Foundation (ICF) today at the start of the Burton Catalyst conference in San Diego.

As one of two members of the ICF board who also serve on the OpenID Foundation (OIDF) board (Mike Jones is the other), and also wearing my Identity Commons steward’s hat, let me share some perspective on this.

Last spring I had the pleasure of working with Eve Maler on an IEEE article called the Venn of Identity, based on Johannes Ernst’s original diagram of the three “pillars” of Internet identity development: SAML/ID-WSF, OpenID, and information cards. The paper was an opportunity to compare and contrast the strengths and weaknesses of all three approaches. I could not leave it without the feeling that the ultimate solution­—the “TCP/IP of identity” as it is often called—lies somewhere in the overlapping middle.

Exactly where, I’m not sure anyone can say yet. What we can say, to borrow an analogy from OIDF board discussions, is that if you want to climb the Internet’s never-been-summited Mount Identity, it’s best not to ignore any promising route.

(As I write this I have firmly in my mind a picture of the glorious Mt. Rainer, the Northwest icon that anchors the southwestern skyline of Seattle. Though I have never climbed it myself—I hope to someday with my two sons—many of my high-school classmates have, including one friend whose ascent with famed mountainer Willi Unsoeld ended in tragedy when Willi and a student were killed in an avalanche at Cadaver Gap.)

In this decade we have made great progress up that mountain. An early, well-equipped group of explorers have pushed steadily up the SAML couloir. Then a second party banded together to attempt the OpenID ridge. Now a third group is navigating by way of the Information Card snowfields.

The closer we come to the last and steepest slopes—the hardest and most dangerous part of the journey—the greater the chance we can all help each other take the peak (a lesson Willi would have preached in spades). In fact paths of intersection are starting to appear everywhere. OpenID information cards. OpenID login to ID-WSF. SAML SSO with OpenID. Relationship cards.

I’ll sum it up this way: ever since the “i-card” session at the Berkman Identity Mashup in June 2006, I’ve been convinced that identifiers (OpenID) and claims (information cards) are both essential tools for scaling the mountain. And I’ve always felt that assertions (SAML) and identity services (ID-WSF) could not be left behind either.

So while it may appear from a distance like introducing the Information Card Foundation adds another divergent element to an already confusing landscape, I see just the opposite. It fills in a key piece of the trail that will help us connect other routes and advance everyone’s efforts. Until pretty soon (shall I go out on a limb and say the end of the decade?) we’ll break through the last ice shelf and summit the mountain.

And just imagine the view from there.

You know you’re seriously an identity geek when your spare-time reading is Understanding Windows Cardspace. But for this rapidly rising new branch of the digital identity space, a book with this much good information about Microsoft’s CardSpace technology is definitely worth the investment.

About half the book is background on the entire problem space that information cards are a solution for; it’s long but worth the read. The rest is technical meat that there are few other places to get.

Recommended especially if you want to move into this new space quickly.

And congratulations Kim. The news just become official that Microsoft has acquired Stefan Brand’s Credentica and all its intellectual property. This pairs up Stefan with Kim Cameron and Microsoft’s Identity and Access team to bring Credentica’s groundbreaking U-Prove zero-knowledge-proof technology to market.

This is a very exciting development, particularly because it means that between Microsoft’s work on CardSpace and Higgins work on new forms of i-cards, some real breakthrough functionality is coming to the i-card paradigm. It won’t happen overnight, just as it’s taken Stefan 15 years of work to bring U-Prove this far. But once you’ve pushed a boulder that big up a hill that long, a landslide can start much more easily.

(Not that those of us working on XRI and XDI would know anything about that picture. )

Ryan Janssen pinged me via my contact page last week to ask if I had time to share the story of how I came to be working on XRI, XDI, OpenID, i-cards, Higgins, and Identity Commons. He reached me this afternoon and we talked for almost two hours. Boy, did it bring back memories. I’m so focused on building out working identity infrastructure and applications based on all these standards and projects that I rarely have a moment to reflect on how many twists and turns (and dollars) its taken to get here. So this was a full-out stroll in the park.

He’s posted an overview and will be writing more as he talks to others who have been pounding away forging this Internet identity layer. Ryan’s really done his homework too — he even included a link at the end to the original XDI white paper that co-chair Geoffrey Strongin and I contributed at the start of the OASIS XDI Technical Committee in early 2004. Wow, did that trip off the old synapses. Most fascinating is seeing the original proposed XDI schema which had just four elements. Four years later, after numerous twists and turns (and by my count 23 intermediate proposals), the XDI RDF model has…four elements (plus the XDI wrapper element). It’s not the same schema (now it’s based on the RDF graph model) — and in fact the preferred serialization is no longer even XML (it’s X3). But it’s uncannily close.

Deju vu all over again…

Paul Madsen has done a nicely illustrated post on the taxonomy of i-cards supported by the Higgins project. He makes a great point about how SAML cards (”s-cards”) could fit in, both in terms of third-party cards and self-issued cards. As I posted previously, I’m excited about seeing SAML integrated into the Higgins framework.

My only quibble with Paul’s diagram is that it shows r-cards (relationship cards) as a subset of m-cards (managed cards). If anything, it’s the other way around — an m-card would be a specialization of an r-card. But actually they are disjoint, the same way Paul shows the r-card and p-card circles in the self-issued set.

UPDATE: Paul has fixed this, and the diagrams are fine now.

The subject is actually very deep, as there are some interesting ways in which r-cards can emulate both m-cards and p-cards. But that’s a deeper subject than I have time for in this post — hopefully I’ll get some time over the holidays to go into it more.

Paul Trevithick just posted about a significant new step for the Higgins Project – the first contributions adding support for SAML 2.0. At first blush that may not seem surprising – SAML is the granddaddy of modern Internet identity protocols – but it speaks volumes precisely because Higgins established its early reputation as an alternative implementation of CardSpace and WS-Trust.

What this reinforces is that Higgins is really protocol-independent. As Paul puts it:

Higgins is about a consistent card-based experience over whatever protocols have traction in the marketplace.

I’m spending a lot of time with Paul and the Higgins team now working on integration of XRI and XDI for the same reason. Both are open protocols being developed at OASIS for digital addressing and data sharing. Both “plug in” to the Higgins framework and its abstract data model. By serving as a “interchange hub” for data and tokens from different protocols, Higgins has the potential to do for identity interactions what TCP/IP routers did for the net itself – finally get us all speaking to each other.

Mike Jones, anchor of the Microsoft Cardspace team along with Kim Cameron & crew, has moved into the blogosphere. I’ve referenced his home page in MS Research (where he used to be) in many blog posts, but now I can reference his new blog, Self-Issued (a nice play on the information card metaphor).
Since information cards and XRIs (or more informally, i-cards and i-names) are already kissing cousins (and flirting closer still), plan to see lots more cross-references to Mike’s new blog.

Kim Cameron has done another great post about how Cardspace and OpenID can work together, and specifically about the potential relationship of information cards and XRI i-names and i-numbers. This continued a thread that started with a post I did January 22 suggesting that it would be ideal for the CardSpace schema to support XRI identifiers as a specific claim type. In his response that same day, Kim said:

“…just a small clarification. Drummond talks about the “default CardSpace schema”. He’s really talking about the “default Self-Issued Card schema.”
CardSpace itself handles tokens of any type, containing claims of any type. There are no limitations on your schema if you create a managed card. I’ll make that clearer in my next post.
Further, we tried to keep the ”bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology. But one of those initial claims is a URL… I thought an i-name or i-numbers would be able to go there. Is more needed?

As usual, Kim’s architectural instinct goes straight to the heart of the matter. In fact he poses such a important question that I’m going to provide a very detailed answer, starting with a use case involving the very blogs on which we are holding these conversations.

The Power of Abstraction

In Kim’s post, where he responds to this excellent post by Andy Dale explaining why the i-name and CardSpace value propositions are so complementary, Kim was particularly kind about the work we have been doing on identifiers at the OASIS XRI and XDI Technical Committees. He gives the example of using his own i-name on his blog. To quote his post (including the links):

By the way, I’ve been using my =Kim.Cameron i-name for a couple of years now – ever since I started this blog. It has been a life-saver. It has been my email conduit to my readers and allowed me to interact personally with many people all over the world – without ONE piece of spam.

Thank you again Kim for your kind words about what I believe is currently one of the most useful features of i-names – they come with contact pages that let you be reached on the net without opening yourself up to spam. But now let me drill down into a crucial feature of how i-names and contact pages work.

First, if you hover over Kim’s “=Kim.Cameron” i-name link above, the underlying href value you will see is:

http://2idi.com/contact/=kim.cameron

Interestingly enough, this is not the original XRI. XRIs are abstract identifiers, so to go to a specific location they are resolved into URIs. The HTTP URI at 2idi.com (2idi is Kim’s i-broker for his =Kim.Cameron i-name) is actually the default HTTP URI that =Kim.Cameron resolves to if you use an XRI resolver. (Why that particular URI is the default is beyond the scope of his post; the complete details are in the current XRI resolution spec.)

The original XRI for Kim’s i-name, in pure XRI format, is:

=kim.cameron

That’s right, there isn’t even an “xri:/” scheme name. That’s optional in XRI syntax because XRIs are protocol independent, so the XRI “scheme” is actually indicated by one of give global context symbols as the first character of the XRI (=, @, !, +, $). That doesn’t mean an XRI can’t use a domain name to specify the authority; it can, just after the prefix “$dns” (or “$ip” if you want to use an IP address). While this syntax is not yet recognized yet by today’s text editors and browsers, the same was true 10 years ago of www.*. That will come in time if XRIs prove as useful as those of us developing XRI infrastructure believe they will be.

To solve the problem of how XRIs can be used immediately with today’s Web infrastructure, the OASIS XRI TC defined an HTTP(S) XRI format called HXRIs. This adds an http(s) URI scheme and domain name as a prefix to the pure XRI. The two rules for an HXRI are: a) the domain name must start with “xri.” and b) the first character of the path must be an XRI global context symbol.

An HXRI is sent to a web server called an HXRI proxy server. Anyone can operate an HXRI proxy server just by creating an “xri.” subdomain and running an instance of XRI proxy resolver code available from the OpenXRI project (see dev.inames.net for more info). So the second form of Kim’s i-name is a HXRI that uses the xri.net public HXRI proxy resolver operated by XDI.org.

http://xri.net/=kim.cameron

If you click this URI, it calls the xri.net proxy resolver which looks up the target XRDS document (I can’t display it here but you can view the XML directly).

Since the xri.net proxy resolver was not given any other instructions about what service type to select, it selects the default service (again, out of scope for this post), which in this case is a contact service, identified by the following XRI in the Type element:

xri://+i-service*(+contact)*($v*1.0)

(Note that this XRI is in URI-normal form, which is why it shows the “xri:” scheme name.)

The xri.net proxy resolver then follows the instructions for composing the final target URI, which is to append the original pure XRI (=kim.cameron) to the value of the URI element (http://2idi.com/contact/). This gives you:

http://2idi.com/contact/=kim.cameron

While this is the HTTP URI that Kim cut-and-paste to put on his blog (probably because that’s what appears in his browser address bar when he goes to his contact page), that’s not actually the HTTP URI he should use if he wants the link to persist. He should use the original HXRI of:

http://xri.net/=kim.cameron

Why? Because this is the full abstract identifier that will continue to work even if Kim later changes i-brokers to a different i-broker (such as 1id.com, Encirca, Initech, or LinkSafe – more in the pipeline). In fact if Kim wants to, he can gain even greater persistence by making the underlying link for “=Kim.Cameron” to his i-number instead of his i-name. You wouldn’t see it unless you hovered over it, but this would look like:

http://xri.net/=!BC75.AD44.D370.C0A0

This is the safest and strongest link Kim could put up because unlink global i-names, global i-numbers will never be reassigned to another XRI registrant if the original registrant expires– all global i-numbers are permanently globally unique.

The moral of this story? While XRIs (in URI-normal form) are technically URIs, they are a special kind of URI intended to be resolved into other concrete URIs that actually indicate the current network location of a particular type of resource. An XRI by itself doesn’t indicate the current network location of anything. It’s purpose is to represent an abstract identity – the real world entity that has a representation somewhere on the network (or is in fact represented entirely by the identifier, in the case of purely abstract entities like tags).

Finally Answering the Question: XRI Claims for the Self-Issued Cardspace Schema

With this background laid, we can now finally start to answer Kim’s original question:

Further, we tried to keep the ”bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology. But one of those initial claims is a URL… I thought an i-name or i-numbers would be able to go there. Is more needed?

My answer is that while it is technically possible to put an XRI (in URI-normal form) into a URI field, and such an XRI would carry the necessary identifier metadata to indicate its URI type (the xri: scheme name), this would be akin to putting a fax number in a phone number field. Yes, technically, a fax number is a phone number, but it’s a special kind of phone number capable of a special kind of phone service, and this is typically indicated to both humans and devices by providing an input field that is explicitly typed to contain a fax number, even though the format is identical to that of a regular phone number.

The same applies to XRIs—in fact even more so because:

• There are explicitly two different kinds of XRIs: i-names and i-numbers. The first is reassignable and the second persistent.
• XRIs are explicitly intended to come in synonym sets, for example one-or-more i-names paired with a persistent i-number. In fact when you register a global i-name with the XDI.org global registry service, you are automatically assigned a global i-number (unless you have one already, in which case you can choose to make the new i-name a synonym to your existing global i-number if you want).

So the bottom line is that for the Microsoft default schema for self-asserted cards to fully support XRI i-names and i-numbers as privacy-protected digital identifiers, I recommend that it include two claims for this purpose: one for a human-readable i-name, and one for a persistent i-number. Ideally both can support multiple instances, though in 99% of the cases only one i-number field will be needed, while in some cases users may wish to share more than one i-name synonym.

I look forward to working with Kim and Mike Jones and the CardSpace team to figuring out the best way forward to full interoperability — and synergy — between CardSpace, XRI i-names and i-numbers, and OpenID.

May 3, 2006, mid-afternoon. The second Internet Identity Workshop had just wrapped up. It was so thick with sessions and discussions that Paul Trevithick, Andy Dale, and I just kept passing each other in the halls saying, “We need to talk!” but never having the time to actually do it.

We finally agreed to meet in one of the conference rooms after the main event was over. We migrated to a whiteboard and started drawing pictures to help us answer the key questions that kept coming up over the past two days, “How exactly are Higgins and XDI different? What does Higgins do that XDI doesn’t and vice versa?”

There was great irony in this. Besides heading the Higgins project, Paul is a member of the XDI Technical Committee (TC) at OASIS. Besides being the leading implementer of XDI, Andy has been a member of the Higgins project. And I’ve been working with both of them for several years now. Yet still none of us had a really good answer to this question.

As we kept drawing and redrawing the diagrams on the whiteboard, wrestling with how things lined up, I noticed Kaliya, Doc Searls, Phil Windley (collectively the organizers of IIW), plus several other late-stayers had joined the room and were happily monitoring to our progress. They were as interested in the outcome as we were!

I stil remember the late afternoon sun streaming in though the second-story window of the Computer History Museum as I pondered that whiteboard. All three of us had the unsettling feeling that there was much more to this story than we were able to divine off this particular diagram at this particular time. And then poof, our fifteen minutes was up and we all had to split for our respective trains, planes, and automobiles.

But the question was NOT answered, and it kept gnawing at the three of us. It was still there at Digital ID World in September, only now it was starting to surface in another direction: the relationship of OpenID 2.0 (which supports XRI) and Higgins. Could Higgins support both OpenID authentication and CardSpace authentication of the same digital subject? If so, was a URL or an XRI the common identifier of the subject? And how would this relate to attribute sharing?

Again the three of us swore we needed to get in a room together to get to the bottom of this and finally answer these questions – for ourselves, and for everyone else that was asking. We even knew of at least one context where we might get that opportunity – a new project from Paul Hawken’s Natural Capital Institute called WISER (World Index for Social and Environmental Responsibility) that will provide an indexing and data sharing platform for the entire international NGO/civil society sector. It looked like an effort on which we could all collaborate.

Still it took until December for the WISER Commons project to gel to the point where we could finally schedule three days together last week to develop a recommended identity and data sharing architecture for WISER.

As planned, the first day we spent understanding the requirements of this groundbreaking project (about which I’ll blog more soon). This gave us just what we wanted: several flagship use cases against which we could compare the Higgins and XDI architectures in detail. The next morning we sequestered ourselves in front of a white board in a conference room at Andy’s offices. We took the first use case and started diagramming it. Step by step by step we worked through how it would be implemented using the Higgins framework and the XDI protocol. But this time, where before we had drawn big boxes and circles and arrows…we started drilling down. Blowing up each box into its subcomponents and drawing the next level of circles and arrows…and when we got stuck, drilling down to yet another level below that.

As expected, there was a boatload of terminology frustration on both sides. Higgins uses “context”, “contextref”, “digital subject”, “subjectref”, and “context-unique ID” or “CUID”. XDI uses “authority”, “type”, “instance”, “i-name”, “i-number”, and “cross-reference”. But as we slowly peeled the onions, we began recognizing intersection points from which we could start mapping the terms.

For example, we knew going into it that both Higgins and XDI were based on schema-independent, context-independent data models, and those models are fundamentally based on RDF subject/predicate/object graphs. But it wasn’t until we peeled the onion all the way down to these core data models and started drawing the RDF graphs that we found ourselves not only on solid ground…

…but common ground. Acres of it. Whole continents of it. In fact, as we used to say at the gold dredging operation where I worked in Alaska, we hit bedrock – and that bedrock extended all the way under the mountain range.

Suddenly for the first time we were no longer looking at each other as “the other way of doing it”. Instead we saw we were both on the same side, building fundamentally the same thing: an interoperable way of sharing data between any two systems and applications.

The next morning when we reconvened with the WISER Commons team we hit upon the perfect analogy: it was exactly like the transcontinental railway projects in the 1800s. Higgins was building from East to West (Paul being from Boston), i.e., from the user-interface and application layer down towards the protocol layer (Paul coming from a background in page layout and desktop publishing). Andy and I and the rest of the XDI TC had been building from West to East (Andy being based in Berkeley and me in Seattle), i.e., from the protocol layer up towards the application and UI layer (Andy coming from the enterprise database and messaging world).

And although we had been building two entirely different railroads for moving data from coast to coast, suddenly here we were, meeting in the middle of the continent. And, to our mutual astonishment, finding that we were both using the same guage tracks! In other words, with a little work, you could hook the two together and data would flow as smoothly up and down the Higgins/XDI stack and across Higgins/XDI-enabled systems as steam locomotives could move across the interconnected intercontinental railway system.

The secret was the guage itself – RDF. We had both arrived at it as the common core model for data description. And although the railroads we have respectively built from it have many different features and can go different speeds and handle different types of passengers and freight in different ways, they are fundamentally interoperable.

So we dubbed this “The Golden Spike Meeting” of Higgins and XDI (Laurie Rae informs me that in Canada it was called “The Last Spike”, but there’s something more romantic about a golden spike). And hopefully it will represent as important a milestone in our progress towards an open interoperable data sharing layer for the net. At a minimum you can know that Paul and Andy and I are committed to bolting these trains together as quickly and efficiently as possible and showing for real how the data can just start moving.

All aboard!!

Ever since the last Internet Identity Workshop I’ve been running like mad trying to finish spec assignments, catch up on email, and prep for the holidays. Not to mention catch up on blog posts (Why anyone calls December “the holidays” is beyond me

First up is a comment back from Mike Jones of Microsoft regarding my plea that CardSpace and OpenID UX designers help each other in the user experience shift embodied in user-centric identity. Mike says:

In response to your question “How can we help each other?”, the first step to me seems to be for the OpenID providers to allow people to sign into their OpenIDs with InfoCards, rather than username/password. Then OpenID users will automatically gain all the benefits of the CardSpace user experience ceremony.

Mike’s right that Microsoft has put thousands of man-hours into designing the Cardspace UX, including the extensive anti-phishing provisions. Any OpenID provider can take advantage of that just by supporting Cardspace-based login instead of much weaker username/password login. That’s a great first step.

I think there will be much more to Cardspace and OpenID integration if the demos at IIW were any indication, but I’ll reserve that for future blog posts (after I finish my Xmas shopping).

Paul Trevithick let me know that the notes from the i-card session at the Berkman Identity Open Space last month are posted at http://wiki.idmashup.org/I-cards.

I continue to find it very helpful to make the distinction between address-based identity and card-based identity. It helps me gives much shorter and more understandable answers to questions like “What’s the difference between an i-card and an i-name?”

It also makes it much easier to talk about how an identity framework like Higgins will work with both forms of identity. Paul’s understood this intuitively all along, which is why he’s been creating a pluggable framework to help developers write identity-empowered applications, no matter whether the underlying systems/protocols are address-based or card-based.

 

At the Berkman Identity Mashup two weeks ago, at an open space session proposed by Paul Trevithick (“Professor Higgins” , the Identity Gang reached consensus on a fundamental metaphor for interoperable identity systems: the i-card.

This consensus was rooted on the fact that, at least in English, the noun “card” (in the general context of communications) is widely understood to mean “a container of information”, or even more specifically, a “container used for purposes of sharing or exchanging information”. This differentiates it, for example, from the term “page”, whose connotation is more of a fixed set of information available for viewing, such as “a page in a book” or “a web page”.

Why the “i”? As Doc Searls put it in the discussion, “A metaphor describes how something is like something else, but not exactly the same as something else.” So the “i” in “i-card” serves the same purpose as the “e” in “e-mail”: it’s a way of suggesting that an i-card is a metaphor to a physical card, such as an ID card, business card, or credit card, but not an exact duplicate. Dale Olds of Novell pointed out that this is just like the graphic folder metaphor used by most file systems: it is similar to a physical file folder, but not the exact equivalent.

When it comes to cards, “i” word better than “e” for all the same reasons it does for “i-name” and “i-broker”, namely that it connotates and abbreviates:

• identity—the assertion of equivalence to something that exists elsewhere (in meatspace or headspace)
• information—what is exchanged using the card.
• internet—the medium of exchange in the broadest sense.
• intelligent—in a digital format, the card can be “smarter” than paper.
• I—the English word for “first person singular”, which in a strict identity graph context can be though of as “the implicit starting node for any relationship”.

This consensus has been badly needed because the Identity Gang (as a loose proxy for the Internet identity community as a whole) has been struggling to settle on a common metaphor for how to describe the set of information that is exchanged in the context of establishing a identity relationship.

The primary need for such a metaphor, as everyone at the session agreed, is to enable consistent user experience—something that is all but impossible without a simple, universal conceptual model users can grasp. The importance of his factor is captured in Kim Cameron’s 6th Law of Identity. Kim has often explained that Microsoft originally chose the card metaphor because it was such a clear analogy to the familiar experience of showing a physical identification card such a driver’s license or credit card. (Microsoft was not the first—Novell’s DigitalMe initiative featured “meCards” all the way back in 1999, and undoubtably there were others before that.)

A related lingering problem was also solved a few weeks ago when Microsoft choose the name “Cardspace” for its implementation of the WS-Trust-based authentication and attribute exchange infrastructure that has been code-named “InfoCard” for the past few years. Suddenly the pieces all line up: i-card as the generic term for “a container of information exchanged for the purpose of identifying or describing the parties to a relationship”, and Microsoft Cardspace as the trademarked name for Microsoft’s specific implementation of i-cards using a specific protocol (WS-Trust) on a specific platform (Windows).

As big a problem as this solves for consistent user experience, I have a different reason for believing it is a profound step in the evolution of interoperable Internet identity. For me it solved of a longstanding identity conundrum I liken to the longstanding debate in physics, “Is light a particle or a wave?” In the end the answer was mu (“unask the question”), because it turned out light could be treated as either a particle or a wave. Both were valid models and the one to use depended on the problem being solved.

Translated to identityspace, the analogous question has been: “Is identity an address or a card”? Or to use the new terminology, “Does one establish an identity using an i-name or an i-card?” At long last this question can be answered exactly the same way the physicists did: mu! Both are valid models and the one to use depends on the problem being solved.

In a session about i-brokers at the Berkman conference, I described the difference between “address-based identity” and “card-based identity” this way:

• Address-based identity can have the property of being “resolvable”, i.e., a digital address can serve not only to identity a digital subject, but when needed, as a way of enabling further discovery about or communication with the subject. Address-based identity is required, for example, when two parties need to establish a bi-directional messaging relationship (email, phone, IM).
• Card-based identity has the property of being descriptive, i.e., of being able to represent attributes, claims, or other metadata and data associated with a digital subject. Card-based identity is required, for example, when a relationship is predicated on one or both parties having certain attributes.

From these descriptions, two conclusions immediately fall out:

1. These two forms of identity are not mutually exclusive, i.e., an address-based identity can be used to discover/request a card-based identity, and a card-based identity can contain one or more address-based identities.
2. Neither form inherently implies or requires the other, i.e., an address-based identity does not mean that a card-based identity is available (or, if available, that a contact has access to it). Nor does a card-based identity mean that an address-based identity is available (or if available, that a contact has access to it).

Whatsmore, both address-based identity and card-based identity can be further classified in some very helpful ways:

• Address-based identities can be broken into resolvable and non-resolvable. While an address-based identity is always unique in the address space in which it is assigned, that doesn’t necessarily mean it can be resolved, i.e., dereferenced via a mechanism or protocol that provides further discover or communications with a digital subject. An email address is a good example of the former; a browser cookie a good example of the latter.
• Card-based identities can be broken into addressable and non-addressable. This means that some card-based identities may contain an address-based identity and some may not. A business card is the classic example of an addressible card-based identity; in fact the primary purpose of most business cards is to share address-based identities. On the other hand a coffee-shop loyalty card is a good example of a non-addressable card-based identity: while it describes identity-related attributes of its owner (how many cups of coffee they have purchased), it may not contain any address-based identity whatsoever (not even your real-world name).

With these distinctions made clear, we can now propose an “Eighth Law of Identity”:

An interoperable identity metasystem must support both address-based identities (resolvable and non-resolvable) and card-based identities (addressable and non-addressable).

In other words, i-names and i-cards will not only co-exist, but they are highly complementary. For example, i-names can be used to request i-cards and i-cards can be used to share i-names. And both can be more user-centric and privacy-protecting than anything we have in the physical world, or even anything else that we have developed in cyberspace to date.

And i-brokers, for their part, can provide both address-based identities and address-based identity services and card-based identities and card-based identity services—and all of them can live happily ever after together.

And the clouds part and the sun comes shining through just like it did through the leaves of the elm trees where we sat outside the MIT Media Lab for the i-card open space session. Sometimes it takes the light of many minds shining on a subject to make it clear to all of us.