Equals Drummond

This entire fall has been intense with work, thus the paucity of posts here. The holidays brings a welcome respite and a chance to catch up with a few key mental threads.

One of them is the growing awareness of the need for what the VRM community calls personal data stores (PDS). The concept is relatively simple: an online store for your own personal data — anything from classic PII (personally identifiable information), such as your identity and contact data, to any other data that you generate or control (files, blog posts, pictures, papers, music, videos, etc.)

Three things have surprised me about PDS:

1. How generally accepted the notion is by almost anyone who spends much time online, even folks well outside the identity community. It’s a relatively intuitive idea as soon as you understand the basic premise that individual people should have their own data source online.
2. How many names have been applied to the same general concept. As I indicated, PDS is only the term applied by the VRM community. The same general concept has been called probably a dozen other names. Here’s an excellent blog post by Mark Dixon that calls it a Personal Identity-Persona Service and a Security Identity Bank Vault.
3. How hard it is to implement. Though there have been several attempts, such as the Mine! Project, nothing has come remotely close to catching on yet.

I have several theses as to why this is so (and yes, the need for a Internet data sharing standard like XDI is high on the list), but I’ll save those for another blog post.

Here, I’ll just conclude with a simple prediction: it’s a threshold problem. Once the first practical solution for PDS starts to take hold, it will catch on and grow just like the first social networks did. The only question is what application will provide that initial traction.

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.

I made a long post about it when Bob first presented it at IIW and then the Burton Catalyst conference last June. Now anyone can get it here. See also Bob’s commentary on its evolution here.

Highly recommended for understanding the underlying dynamics of identity and relationship on the net.

More about the long quiet spell soon. First I must post about a trip I made last week to spend the day with Phil Windley, his partner Stephen Fulling, and the inimitable Craig Burton down in Salt Lake City.

What Phil and company are doing at Kynetx is earthshaking. There’s not much info on the website yet, but last week Phil posted a white paper The Advent of Next Generation Browsing that introduces the whole concept of structured browsing. I won’t even bother to try to explain it here; just get the paper and read it. Then read another one of Joe Andrieu’s exceedingly cogent essays with his impressions, criticisms, and suggestions about the Kynetx vision of structured browsing and how it fits with Joe’s work on search maps. Also read Phil’s reply to Joe.

The rules language Phil wrote (KRL – Kynetx Rules Language) is at the heart of their solution for structured browsing. I am a huge fan of what rules languages can do with structured identifiers and structured information. That’s what I was down in Salt Lake talking with Phil, Stephen, and Craig about. Phil followed it up with a great post, First Class Namespaces in Programming Languages, that sums up how XRI and XDI might fit with KRL.

Did I say earthshaking? Watch out when this quake breaks loose.

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 =

Phil Windley has an uncanny ability to size up new technologies in a single bound. Read his take on relationship providers and how far they can go beyond the role of “identity providers” (a term I have never liked since the moment I first heard it six years ago).

As he concludes:

I’m still trying to understand all the details, but convinced of the necessity of this kind of thing. My work on reputation (PDF) was a start at understanding how trust relationships can be created online. I’ll be writing more about this as I understand it more over the coming weeks.

I can hardly wait to read his further thoughts. Relationship is the pot of real gold at the end of the identity rainbow.

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!

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.

I’m writing this from the audience of Bob Blakley’s Data Sharing Summit session (which he also gave yesterday at the Internet Identity Workshop) on The Relationship Layer. It’s based on a paper he and his colleagues Gerry Gebel and Lori Rowland written for the Burton Group (but not published yet – Bob says look for his upcoming “world’s longest blog post”). This will be followed by a session the Higgins Project that will demonstrate a new form of information card called a relationship card (r-card).

The driving point of Bob’s session is that the ultimate purpose of identity technologies is to enable relationships. Bob’s thesis is that when you look at it this way, the current paradigms of Internet identity infrastructure — both the “federated” paradigm and the “user-centric” paradigm — need to evolve into a relationship paradigm.

In this paradigm:

• Relationships should be “nodes not edges” in the social graph, i.e., they should be first class objects in the graph rather than just arcs connecting the nodes representing people and organizations.
• Identity should always be in a relationship context.

There are two reasons for constraining this use of identity to a relationship context:

1. To set the rules for the relationship.
2. To provide accountability.

Bob makes several other key points:

• This approach shifts the privacy discussion from rights – which Bob says is “poorly supported by current law” (at least in the USA) — to contracts, which are voluntary obligations into which the parties to the relationship enter.
• Relationship objects provide a new form of protection and accountability because they “wrap” identity data inside a container that makes it much clearer who is authorized to do what with that data.
• This relationship container is a much easier way and more effective way to deal with data rights issues than DRM.

Bob goes as far as proposing the conceptual structure of a generic relationship object. The basic parts are:

• Creator
• Rules
• Roles
• Participants, who make Consents and Promises and share Claims

Each participant to the relationship chooses the role(s) they will play, the consents they give, the promises they make, and the claims they share. (Those of use drinking the XDI koolaid will immediately recognize this as the essential ingredients of XDI link contracts, but more clearly articulated at the social level.)

Another consequence is how this shifts the role of identity providers in both the federated and user-centric models. For example, Bob asked a new identity provider in the latter space, “What are you selling?” The answer should NOT be “identity”. The answer should be, “relationships” – specifically high-quality relationships for low cost.

Eve Maler commented: “I’m really happy to see arrows pointing in both directions (i.e., to both parties in the relationship) so both parties participate in a relationship and both can ‘give and get’.” Bob gave a big high-five to this and it set him off on his “rant on user-centric identity”, which in a nutshell is that the “asset” that is a relationship is a joint property that benefits both parties. “Enterprise-centric” identity systems emphasize giving control to the enterprise. “User-centric” identity emphasizes giving control to the user. But both are, as Bob puts it, “forms of abuse”, i.e., neither one emphasize the relationship and therefore the mutual trust, which should really be the Sun at the center of an Internet identity system.

So instead of “Identity 2.0″, we should we call it “Relationship 2.0″.

Bob said is that there is a great instantion here of permission marketing. Comparing this to traditional email list marketing, he said: “What you want is not to have the world’s greatest collection of email addresses, but the world’s greatest collection of relationship contracts in which the users actually want to hear about whatever the vendor wants to communicate about.”

Another quote from Bob: “Sociability works much more from accountability than it does from authorization.” The example here was access control lists for social data on social networks. Bob argues that lengthy access control lists are not only a bother to users but don’t recognize the much more powerful “social contract” that is based on expectations and accountability, i.e., “a real friend of mine will not share my information in a way that might harm me, and if they did, they know how I will react”.

Net net: I think Bob’s thesis is the Copernican Revolution of the Internet identity industry. I’m sure it will a major theme of my posts in the months ahead.

But my very next post will be about the next session (once it’s over) that follows directly from Bob’s thesis: relationship cards.