Equals Drummond

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.

Doc Searls has done a very succinct post on the Principles of VRM in preparation for the VRM Workshop next week in Boston. You can’t read it and not see how closely VRM is related to r-cards (relationship cards) and XDI. I’m so excited to actually start bringing this to market this year that sometimes I want to drop everything else (standards calls, conferences, email, expense reports, EVERYTHING) and just work on that ’till its out the door.

Like the Web itself, the Web of Relationships — the whole Web becoming a social network — will change the world in ways we can hardly begin to imagine.

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!

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.

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.

Joe Andrieu, one of the leaders of the VRM (Vendor Relationship Management) community, has posted a good initial assessment of Microsoft’s first foray (post-Passport) of storing personal data for consumers via their Health Care Record initiative. It’s well worth reading his assessment of how this really legitimizes the market for “personal data stores”.

Since that’s one of the primary use cases for which XDI is being developed as a protocol and Higgins is being developed as an open source projects, there will be much more to say about this in the coming months.

Certain events scream out for live blogging. The Data Sharing Summit is one of them. So these are my notes from first half of Day 1. (Then why are they being posted at midnight, you ask? Because there was too damn much to talk about during the second half of the day. More on that tomorrow.)

First, this is the list of problems that attendees want to see addressed:

• The distributed schema mapping problem – how do you map across zillions of different local schemas?
• The “Social Web Bill of Rights” or “identity rights agreement” problem – how can you have “Creative Commons licenses for data sharing”?
• The protocol problem – how do you move social graph data around?
• The “too many IDs” problem – how can we not require more IDs (even with OpenID there is starting to be a proliferation of IDs)?
• The directory or “friend discovery” problem – how do you find other people in the social graph (a “People’s Guidestar”)?
• The addressing problem – how can data be addressed in a consistent manner across distributed locations?
• The user privacy and control problem (also called the “fear” or “surprise” problem) – how can users not be spooked by the idea of their social graph data “getting loose”; how can they maintain control over portable social graph data?
• The granular access control problem – how can control be easily brought down to the individual attribute level, e.g., date of birth?
• The regulation problem – how can social graph portability be accomplished within the bounds of data sharing regulations that currently do not permit certain types of personal data to be shared across certain jurisdictions?
• The safety problem – how can portable social graphs not be subject to the same spam, phishing, and phraud problems as email and the Web?
• The political problem – how can we make it “politically necessary” for sites and applications to offer social network graph export?
• The “friend description problem” – how can we have a interoperable means of providing richer description of “friend” relationships?
• The calendar sharing problem – of all the different types of social graph data, how specifically can we reach alignment over sharing of calendar data?
• The adoption problem – what are the compelling uses of social graph portability that will drive large-scale adoption?
• The internationalization problem – how can attribute sharing work across all world languages?
• The user experience problem – how can social graph sharing operations be made simple and understandable to everyday Web users?
• The operational problem – how will large-scale data sharing affect network loads, caching, firewalls, security perimeters, etc.?
• The “invitation fatigue” problem – how can we stop being overwhelmed by yet another source of messages and “click-to-accept” links?

Second, this is the list of solutions being offered at the DSS:

• An OpenID interoperability testing service (Marc Canter)
• A new open source project & community for social data portability using Higgins and Higgins context providers.
• A community dictionary service for schema mapping (Markus Sabadello, Drummond Reed, Paul Trevithick)
• Different companies offering the potential to have open APIs for sharing their social graph data (AOL/AIM, Yahoo, Google, Cyworld).
• OpenID-based attribute exchange (Dick Hardt & Sxip)
• An open API format for social network portability and sync’ing (Brad Fitzpatrick and David Recordon)
• A social network export service (Upscoop from Rapleaf)

Third, here are the demos that were shown before lunch:

• Cloudtripper: Paul Trevithick and Markus Sabadello showed how Higgins in conjunction with Higgins context providers (code chunks that know how to talk to specific data sources) can be used to pull a user’s social graph data together directly to their own desktop client.
• Community Dictionary Service (CDS): Markus Sabadello and I demo’d a new service contributed to the Identity Schemas Working Group at Identity Commons. Intended to help solve the schema mapping problem for highly distributed data sharing, the CDS is a “Wikipedia for machines” – a way for applications to discover and map elements from different data schemas. (I’ll blog a bunch more about this after the Summit is over, but please do see it for yourself.)
• FOAF crawler: David Recordon (now back at Six Apart) showed a service that crawls public FOAF, XFN, or other relationship metadata to produce aggregated social graphs.
• Pownce: Leah Culver demo’d a social network aggregation service that lets users aggregate their own social graph.
• XRI-based data sharing: Mike Mell showed an implementation of a data sharing solution based on XRI structured identifiers for La Leche League International.

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!!