Equals Drummond

Someday I’m going to write a book about primary challenge with disruptive technologies: they are always starved for resources. In fact, you could argue this chicken-or-egg problem is what defines a disruptive technology: it can’t attract enough development resources until it has proven its value, and it can’t prove its value until it has attracted enough development resources.

The effective result: a small group of people (who most of the rest of the planet consider to have at least partially lost their marbles) keeps pushing the disruptive technology forward in niches until – poof! – suddenly it’s mainstream.

As you might guess, this brief diatribe was inspired by a message I received from an OpenID developer this morning:

I’ve now read a lot about XRI, and I still just don’t get it. Do you know of any good resources that explain the flow of XRI’s?

ARRRRGGGHHHH! The question hits right between the eyes because I think of all the detail in the XRI Syntax 2.0 and XRI Resolution 2.0 specs, and all the implementation work that has been done and XRI services being delivered, and yet, I still can’t just point to a good XRI in a Nutshell guide (to borrow the standard O’Reilly name for such guides) needed by the vast majority of developers being exposed to XRI for the first time (such as through OpenID).

And I know why: the relatively small community that developed the XRI specs, early implementions, and infrastructure services just hasn’t had had the resources. We keep talking about the need for it but it keeps taking a back seat to either: a) our day jobs so we can keep from starving, or b) the need to keep pushing forward XRI specs/implementations/services so that it can succeed.

Enough of this rant. In the spirit of continuous improvement, I’ll leverage the power of personal publishing simply by blogging the answer I sent back in email this morning. Hopefully this will become the seed of a real XRI in a Nutshell document within the next few months. Keep in mind this is for developers familiar with OpenID, which assumes a basic knowledge of DNS. A little XRDS knowledge helps too.

—-

XRI IN A (REALLY SMALL) NUTSHELL

XRI is an identifer and resolution infrastructure just like DNS, except that it operates at a higher abstraction layer, just like DNS operates at a higher abstraction layer than IP addressing. XRI is to URI addressing (of any kind) what DNS is to IP addressing.

At the DNS layer, the resolution protocol is UDP. At the XRI layer, the resolution protocol is HTTP (or HTTPS for security - more on that below).

In DNS, you resolve a domain name to an RR (Resource Record). In XRI, you resolve an XRI to an XRDS document.

In DNS, the server hosting RRs for DNS zones is called a nameserver. In XRI, the server hosting XRDS documents for XRI authorities is called an authority server.

Just as DNS names can delegate to other DNS names (e.g., in www.yahoo.com, com delegates to yahoo delegates to www), XRI authorities can delegate to other XRI authorities. In XRI the delegation characters are not dots but * (for reassignable XRIs, called i-names), and ! (for persistent XRIs, called i-numbers). So the XRI i-name =drummond*foo is a delegation from my XRI authority to another one called foo. And the XRI i-number =!F83.62B1.44F.2813!24 is a delegation from my i-number to another one called 24. (Authority delegation is handled in XRDS documents using the service type xri://$res*auth*($v*2.0).)

In the resolution spec, we define two kinds of XRI resolvers: local and proxy. A local XRI resolver is just like a local DNS resolver: you call it with an XRI and a set of resolution parameters (like the service type you’re looking for and whether you want it to use trusted resolution or not) and it gives you back (depending on what function you call) the entire XRDS, the final XRD, the final XRD filtered for only the service you want, or just a list of URIs from that service. A reference API for a local resolver is provided in Appendix F of XRI Resolution 2.0.

A proxy resolver is simply an HTTP(S) interface on a local resolver, so you can call it over the net like a service. This interface is defined in section 11 of XRI Resolution 2.0. To call a proxy resolver, you embed the XRI you want to resolve in an HTTP or HTTPS URI and then add query parameters to control the resolution result you want back. The resulting HTTP(S) URI is called an HXRI.

The ABNF for an HXRI is in section 11.2 of XRI Resolution 2.0. But it’s really simple: a) you create a prefix of http://xri.*/ or https://xri.*/, b) you append the XRI you want resolved as the path (without the xri://, and c) you add any XRI query parameters.

http://xri.net is just a XRI proxy resolver run by XDI.org as a public service (NeuStar actually operates it). But there are other proxy resolvers, for example, http://xri.freexri.com (see @freexri for more). Anyone can run an XRI proxy resolver just like anyone can run a DNS server. There is no one authoritative proxy resolver.

So when you see http://xri.net/=drummond in my email sig, that’s an HXRI. It’s jus the way to ask the the http://xri.net/ proxy resolver to resolve the XRI =drummond. If you don’t give it any resolution parameters, what the proxy resolver will return is a 302 redirect to the HTTP(S) URI for whatever resource I have designed to be selected as my default service (in my case, my contact page at http://2idi.com/contact/=drummond). But if you add resolution parameters, you can get back anything the proxy resolver supports. For example, the following HXRI will give you back my XRDS:

http://xri.net/=drummond?_xrd_r=application/xrds+xml

Lastly, since you bring up security, there are two key trust features of XRI infrastructure that are good reasons to use XRI with OpenID Authentication 2.0. The first is trusted resolution. XRI infrastructure supports three modes of trusted resolution: 1) all-HTTPS resolution calls (meaning every step of the resolution chain across delegations uses HTTPS automatically), 2) SAML signatures (meaning every step of the resolution chain returns an XRDS with a SAML signature), and 3) both HTTPS and SAML. See section 10 of XRI Resolution 2.0 for details of all three. (Note: HTTPS is supported by 100% of the XRI authority servers I know of, but SAML support has so far has been limited to special cases.)

The big advantage is that since XRIs are abstract identifiers, any OpenID RP can choose to use 100% HTTPS resolution every time it is given an XRI. That means XRI users never have to type https:// or do anything special at all to always have the benefit of a secure identifier. I should be able to type =drummond into any OpenID RP and have it always use HTTPS to resolve it.

The second key trust feature is that XRI infrastructure has a fundamental solution to the OpenID recycling problem. (See this short ACM paper for a full explanation of this problem.)

Since XRI infrastructure supports synonyms (different identifiers that identify the same target resource), all XRI infrastructure rooted in the XRI registry services offered by XDI.org have the operational requirement to assign persistent i-numbers for every i-name registered (at any level) and to never reassign those i-numbers to another registrant. No recycling. For example, both my i-names =drummond and =drummond.reed have the i-number synonym =!F83.62B1.44F.2813. That’s will always be my OpenID claimed identifier to any RP where I sign in as either =drummond or =drummond.reed. It will never be reassigned even if I let both those i-names lapse.

Unlike the URL hash solution to persistent identifiers in OpenID, the XRI solution has the advantage of being fully portable. Even if I let my i-names lapse, I still have full control of my i-number =!F83.62B1.44F.2813 forever.

For example, I can transfer it to any i-broker just like you can transfer a domain name to any domain name registrar. The “elephant in the living room” of the URL hash solution to OpenID recycling is that a hash like https://i-own-this-domain.com#1234 is absolutely worthless if i-own-this-domain.com is reassigned to a new registrant (which, as we know, can happen with a DNS name for all kinds of reasons, not all of which a registrant can control). Now the new registrant totally controls the whole URL hash space! Your “secure” OpenID identifier has been completely compromised.

So the truth is that the hash URL solution only works for very large providers where you can be reasonably sure that for example http://yahoo.com or http://aol.com is not going to sell out to someone that’s going to start reassigning yahoo.com or aol.com hash URLs. But for all the smaller providers – and mostly for all the individuals that would like to have their OpenID URL based on their own domain name – it doesn’t work at all.

—-

Lastly, besides the links above, another site I recommend for more info on XRI is Markus Sabadello’s @freexri site. Markus is one of the lead developers of the OpenXRI project (a Java implementation of XRI resolver/authority server/proxy server).

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 =

Boeing has long been one of the most progressive companies when it comes to identity management and how it can enable new value chains in a large ecosystem. Marty Schleiff is one of the reasons. I’ve worked with him extensively on the XRI Technical Committee at OASIS, but Marty’s involved with pretty much every aspect of identity and directory services at Boeing.

Marty’s new blog is called Identity Happens. It was motivated by his idea of creating something like an OSI reference model for identity. Give it a read — this is going to be a great discussion.

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.

Some 34 years after it was published and 20 years after my last (fifth) reading, Robert Pirsig’s Zen and the Art of Motorcycle Maintenance remains the book that has has the biggest influence on my life. I took my old copy with me on our family vacation to Montana because we would be travelling part of the route Pirsig travels by motorcycle in the book.

On our drive back last week this inspired me to read my wife and sons one of my favorite passages from the book that happens to include a perfect summary of why vacations are so good for the soul (and for your work/health/life):

The gumption-filling process occurs when one is quiet long enough to see and hear and feel the real universe, not just one’s own stale opinions about it. But it’s nothing exotic. That’s why I like the word.
You see it often in people who return from long, quiet fishing trips. Often they’re a little defensive about having put so much time to “no account” because there’s no intellectual justification for what they’ve been doing. But the returned fisherman usually has a peculiar abundance of gumption, usually for the very same things he was sick to death of a few weeks before. He hasn’t been wasting time. It’s only our limited cultural viewpoint that makes it seem so.

This “vacation mind” is so valuable to sustained creative work (and building digital identity systems is nothing if not creative) that I’ll do everything I can to sustain it throughout the rest of the year. So if you see me looking like I’ve “gone fishing”…that’s exactly right.

Whoever thought we’d be using blogs for vacation notices? But until we have real Internet-wide presence service, it seems much more sane than problem-prone email bounce-backs.

So count on me to be completely offline (and I mean completely) until August 4th. I’ll blog more on why when I return (in complete bliss).

Joe Andrieu nails another super post (where DOES he find the time to write/draw all of these???), this time about what it means for a platform to really be open.

My favorite part is that he doesn’t just do it in words — he does it in pictures, deliciously simple and understandable graphics that make it really clear what he means by “open platform”. In short, it’s the protocol, stupid!

Or as Joe puts it:

Level 4 platforms allow developers to build applications anywhere–on a website, on your desktop, even on your cell phone–and those applications can talk to any number of platform providers without restriction, using standard open protocols. Many of us have heard of the most successful protocols: SMTP, POP, HTTP, HTML, TCP/IP, RSS, but most users know these by the applications they enable: email, the World Wide Web, the Internet, blogs.

It’s the perfect message before the VRM Workshop starting tomorrow, and of course it’s exactly what we’re driving towards with XDI. One day I hope Joe can say the same thing about XDI - most users will never have heard of it or the dataweb model of data sharing, but they’ll know the application - VRM!

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 naïve thought that I’d 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—what’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 Johanne’s 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 moutain. 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.

If you haven’t heard of VRM (Vendor Relationship Management) yet, you will soon. Not that it will be an overnight phenomena - that’s one of the points Joe Andrieu makes in his mini-FAQ about VRM. But read Joe’s post to see why in many ways the emergence of VRM is as inevitable — due to the steady evolution of Internet identity and data sharing technology — as the emergence of CRM systems was in the 90’s — due to the steady evolution of database technology.

At the last Internet Identity Workshop, I gave Paul Madsen a community award for keenest identity wit. Everybody agreed he wins hands down. For a taste see his appraisal of the W3C recommendation on XRI.

It was stunning. 10 days ago, a few days after the voting period began on XRI Syntax 2.0 and XRI Resolution 2.0 becoming an OASIS Standard, the W3C TAG (Technical Architecture Group) came out with a statement recommending that members of OASIS – a completely separate and independent standards body – vote against it.

Despite 20 votes already being cast in favor of the specifications at that point, almost immediately a handful of negative votes were cast with comments referencing the W3C recommendation, starting with Sun Microsystems (especially ironic since Eduardo Gutentag of Sun is chair of the OASIS Board of Directors).

Although it’s not unusual for a proposed OASIS standard to have some opposition, what is strange is to have that opposition led by another standards body. What took the XRI TC even more by surprise, however, was the W3C’s sudden vocal opposition to XRI 2.0. When the W3C TAG submitted a comment on the last day of the first public review period of the XRI Resolution 2.0 specification in March, the XRI TC responded with a detailed 5-page answer to the three questions posed by the TAG. We never received any response.

In a subsequent final public review of XRI Resolution 2.0 held the following month, we didn’t hear anything more from the W3C TAG. Nor did the TAG minutes show any further discussion.

In any case, the XRI TC posted a response to the TAG’s position, and OASIS members responded by casting more positive votes, enough so that only a few days later the vote passed the minimum threshold of positive votes (15% of OASIS voting members) required for an OASIS Standard to pass.

That’s when it became apparent just how badly the W3C didn’t want that to happen. The second rule with an OASIS Standard vote is that no more than 25% of the votes cast can be negative. That’s never happened in OASIS history – in fact the highest percentage of negative votes ever cast against an OASIS standard was 9% (for the Management Using Web Services v1.0 specification in February 2005, for which a whopping 6 negative votes were cast).

But within hours of the XRI 2.0 ballots reaching the 15% positive threshold, suddenly more negative votes began appearing. Almost all of them referenced the W3C TAG recommendation. By Thursday of last week, with three days left, enough negative votes had been cast to reach the 25%-of-all-votes-cast negative threshold.

Naturally XRI supporters responded by contacting other OASIS members, informing them of this unprecedented situation, and asking for their support. In one case, a company’s OASIS voting rep had cast a negative vote apparently without knowing his company was planning to adopt XRI and XDI technology. After a hastily arranged meeting to explain the details, the company reversed its position and voted in favor.

Many more OASIS members responded likewise, and by Friday morning there were again enough positive votes to safely pass both specifications.

But it wasn’t over. More emails, phone calls, and even blog posts from W3C TAG members went out. More negative votes appeared. By Friday evening, the negative votes were again just above the 25% threshold.

Given that the final day of the vote was a Saturday (OASIS Standard votes always run the final two weeks of a calendar month), it took an extraordinary effort by XRI supporters to reach out once more to OASIS members for help. But once more they responded, and by noon on Saturday, 8 hours from the close of the vote, 72 positive votes had been cast, enough to pass both specifications.

But I had a sinking feeling as I left to work on a birthday project for my youngest son. Sure enough, when I came back for dinner that night, with only four hours left in the vote, two more negative votes appeared – just enough to cross the 25% negative threshold and defeat both ballots.

(You can see the final results here and here, however due to technical problems at OASIS, you can’t currently click through to read comments posted with a vote.)

—-

As I watched the voting period end on Saturday night, one thought kept echoing through the back of my mind: “What is the W3C so afraid of? Why do they care so deeply that OASIS members not approve XRI 2.0 as an OASIS Standard? Why on earth would they turn out such an extensive and unprecedented lobbying campaign for something they have so long ignored?”

In other words, if they thought XRI was such a bad idea – or in their precise words, “We are not satisfied that XRIs provide functionality not readily available from http: URIs.” – why don’t they just let it die a natural death in the marketplace?

—-

In any case, we’re about to find out. A number of OASIS members who voted No at the TAG’s urging noted their reluctance in doing so in their comments. They explicitly asked the OASIS XRI TC and the W3C TAG to sit down together and iron out our differences. The most eloquent was Ray Denenberg of the Library of Congress, who said:

First we reference comments of Wells Fargo, who said:

“Although we support XRI’s objectives, we urge the XRI TC to consider W3C’s comments seriously and add a non-normative clause explaining key differences between XRIs and URIs, and detail how the former address specific deficiencies of the latter.”

And comments from Nokia, who said:

“Although the XRI TC and W3C TAG have exchanged some e-mail regarding the XRI spec, it appears the engagement has been mostly superficial. Consequently, we recommend these two groups engage in detailed technical discussions (including use cases and deployment scenarios) before OASIS formally adopt this spec.”

We further observe that the body of existing documents on XRI, though abundant, all seem either too high level or too detailed. It is very difficult to get the whole picture.

The Library of Congress urges OASIS to:

1. Consider W3C’s comments seriously, explain differences between XRIs and URIs and how XRIs address deficiencies of URIs, and respond with substantive explanations (rather than existing promotional text) to W3Cs concerns.

2. Prepare a paper (or non-normative clause), perhaps 5-10 pages, that includes the above, as well as a comprehensive description of XRI, including use cases, deployment scenarios, and real-life examples.

The Library of Congress supports the XRI objectives and we are prepared to change our vote if these steps are taken.

This is highly constructive feedback by Ray, and in my personal opinion, it lays out precisely the path the XRI TC and the W3C TAG should take together. Although I obviously would have preferred other ways to get here, those who know me know that I prefer to focus energy on how to solve problems, not how to create divisions.

The past is past. With this blog post I’m personally holding out an olive branch to the W3C TAG – and encouraging other XRI TC members to do the same – and asking to begin the dialog that will hopefully result in a mutual understanding about the role a layer of abstract structured identifiers will play in the Web.

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.

Chris Messina has a post worth reading about the whole subject of Data Portability. Though it is a complex new topic that demands a longer and more thoughtful post, the one point he and Chris Saad agree on is that the meme is here to stay. As the wonderful book Made to Stick would characterize it, “data portability” is a highly sticky idea. It’s not going away anytime soon.

(On a side note, I’m desparately seeking time to do a longer post about Made to Stick, which every technology communicator should not just read but memorize. It was the inspiration for the presentation I gave at Internet Identity Workshop today which used no slides at all. Bill Coleman insisted Paul Trevithick read it. Paul insisted I read it. I insist you read it. ’nuff said.)

The Magic Include Shell took my blog offline and finally compelled me to move it to new hosting quarters, upgrade to WP 2.5.1, install a new theme, and add OpenID and information card support - all thanks to the magic of Stas Zubalevich at Parity.

If your WordPress suddenly goes wonky, I highly recommend this article about the Magic Include Shell. Nasty stuff.

Glad to be back online for the Internet Identity Workshop starting tomorrow - it’s gonna be a dousy.

Ryan Janssen has posted another interview in his series on digital identity, and I daresay that if you’ve ever met Doc Searls, you can just feel his energy and passion about VRM coming through in this writeup. Highly recommended reading. Doc has been right about many things, and ultimately I think VRM is going to be one of the most important.

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.

Nowadays I find myself orienting my entire year around IIW (the Internet Identity Workshop). DO NOT miss it if you want to seriously intersect with the user-centric identity community. This year it will include a follow-on Data Sharing Summit on May 15, illustrating how the focus is slowly moving to the most important capability enabled by UCI.

See ya there.