XRD Begins

Posted on 11/30/2008 by Drummond Reed

For most people, watching the evolution of technical specifications is like watching a glacier move. To those of us living the process, though, there can be a great deal of drama to it — in fact it’s much more like climbing an icefall inside the glacier (anyone doubting how much adrenaline that takes should read John Krakauer’s description in Into Thin Air of climbing Mt. Everest’s Khumbu Icefall). For example, the failure of the OASIS Standard vote on the XRI 2.0 specifications last May — the first ever in 40+ OASIS Standard votes — was a watershed in the interaction of two standards bodies (W3C and OASIS).

The repercussions from that event have been equally unpredictable. Who would have thought that just four months later the XRI TC and W3C TAG would have rough consensus on how to resolve their differences? Or that the discussions would spill over to the much larger topic of uniform metadata discovery on the Web? Or that discovery could turn out to be the key to building identity into the browser? Or that interest in the XRDS discovery format would boil up enough to beget a new spec intended for uniform metadata discovery for any type of URI or XRI?

But that’s just what has happened. Two weeks ago at the Internet Identity Workshop, Eran Hammer-Lahav, author of the OAuth Discovery spec and founder of the XRDS-Simple list, led a marathon session on a new uniform metadata discovery specification to be called XRD 1.0. With 20 to 40 people in attendance all afternoon, Eran first ran through his exhaustively-researched blog post on HTTP and discovery, then through the proposed simplifications to the current XRDS/XRD schema. By the end there was rough consensus on XRD as a mechanism for uniform metadata discovery across all the different Internet identity and data sharing specs that need it (XRI, OpenID, OAuth, OpenSocial, XDI, Data Portability, etc.)

The name “XRD” is itself quite revealing of the evolutionary path to this point. When the OASIS XRI TC first developed the XML-based metadata discovery format we needed for XRI resolution back in 2003, we called it XRID (XRI Descriptor). We made it as simple and generalized as we could simply because any resource could have an XRI, so there was no telling what type of metadata might be needed over time. We focused primarily on one clear requirement: given input identifier x and service type y, define how to discover service endpoint URI z.

By 2005, when OpenID grew to the point of needing a discovery format, the authors of the Yadis (Yet Another Discovery spec) authors looked at XRID and saw something very close to what they needed. But XRID assumed you needed a sequence of descriptors corresponding to an XRI resolution chain. With OpenID a sequence wasn’t needed because an http(s) URI would have just one descriptor. So the XRI TC renamed the metadata format to XRD (Extensible Resource Descriptor) and created a separate XML wrapper element called XRDS (XRD Sequence) for cases like XRI resolution where you needed to wrap a sequence of XRDs.

However for cross-compatibility between XRI and OpenID, OpenID discovery just assumed the outer XRDS wrapper element even if it contained only one XRD. So the discovery format became widely known by the wrapper element, XRDS.

It wasn’t until Eran’s deep-dive on uniform metadata discovery that he recognized that the base case should be the other way around, i.e., for most URIs the the base discovery document should be an XRD, and only in cases like XRI resolution do you need the XRDS wrapper element.

Since the XRI TC had already made the decision in our next round of specs to split off XRDS from XRI Resolution, it was easy to just call this new specification XRD 1.0 (“1.0” reflecting that it is the first standalone specification for XRD). However what we didn’t realize until the XRI TC F2F meeting the day after IIW was that XRD as both a metadata discovery format and protocol would be comprehensive enough that XRI 3.0 Resolution could become simply a “profile” of XRD 1.0 — and thus dramatically shorter.

We also didn’t realize how badly many different stakeholders want a Web-wide metadata discovery mechanism. Within a week after IIW we had six new people join the XRI TC to be part of the XRD work, and as of this writing nine more are in the queue.

So the roadmap of the next generation of XRI TC outputs is clear now. We will produce two OASIS Standard-track specifications:

  • XRI 3.0 (including Syntax, Resolution, and Bindings) as a uniform syntax and resolution protocol for shared semantics across hierarchical URI schemes.
  • XRD 1.0 for uniform metadata discovery for any URI or XRI.

Stay tuned for updates – hopefully this set of specs will set a glacier speed record.

Posted in General, OpenID, XRD, XRDS, XRI, Yadis | 3 Comments

Wikipedia: The Auto-Matching Contribution

Posted on 11/15/2008 by Drummond Reed

I could go on for hours about the value of Wikipedia to every person on this planet. But let me go right to the bottom line: take a few seconds to show your own appreciation for by making a donation. (With PayPal it literally takes 30 seconds.)

Wikipedia Affiliate Button

Personally, I include Wikipedia among my charitable contributions because no matter what other cause you support, it’s very hard to argue that a better way to share and disburse knowledge in this world isn’t a contribution to that cause as well.

So I consider my Wikipedia donation an “automatic matching contribution” for every other donation I make.

Posted in Community Dictionary Service | Tagged | Leave a comment

Semantic Web for the Working Ontologist

Posted on 11/15/2008 by Drummond Reed

Whenever I find myself recommending a book more than two or three times, it’s easier to just put a link here and point people at it. It’s definitely time to do that for Semantic Web for the Working Ontologist. It’s the second “you must read this” book recommended to me by Parity CEO Paul Trevithick (the last one was Made to Stick, which I also blogged about).

At last week’s Internet Identity Workshop I must have told a dozen people to read this book. It’s not that it’s filled with blazing insights about a notoriously inaccessible topic. It’s rather that the book patiently and carefully explains the real basics of RDF, RDFS, OWL, and the SemWeb using everyday examples that working developers and architects can wrap their heads around. It’s the most example-intensive technical book I’ve ever read, and when it comes to the SemWeb, I’m convinced that’s the right approach.

And one thing is for sure: you can’t read this book without coming away with a much deeper understanding of the power of the concept of inference, especially as it relates to the SemWeb.

I especially recommend this book to anyone interested in XRI and XDI — the former because one of of the strongest emerging use cases for XRI is sharing semantics across contexts, and the latter because XDI is a semantic protocol that uses XRIs to encode RDF statements (some of which can as filled with inferences as natural language statements).

Net net: if you’ve always wanted to understand the SemWeb but been afraid to try, treat yourself to this geek Christmas present.

Posted in General | Leave a comment

Now We Will

Posted on 11/4/2008 by Drummond Reed

I don’t think I’ve ever made a political post in this blog, but tonight is an exception.

We’ve never had an election like this. In my lifetime, I’ve never seen one man and his family and his campaign have such an impact on the direction of this country and this planet.

My wife and I were in tears watching Obama’s acceptance speech with our two sons. Just what it means to see Barack and Michelle and his daughters going to the White House – it’s a symbol to every last one of us of what is possible not just in this country but in every country.

It’s also a huge first step towards restoring our good name in the world.

It is a turning point for the 21st century? No one can say for sure. But I’m going to wake up tomorrow with more hope in my heart for my boy’s future than I have in a long time.

It’s now longer just Yes We Can.

It’s Now We Will.

Posted in Blogging, General | Tagged | 2 Comments

Firefox, Are You Listening?

Posted on 9/26/2008 by Drummond Reed

Pam Dingle has a wonderful suggestion about how Firefox should proceed with automatic updates. Those of us building identity selector technology that integrates closely with browsers need stable browsers to work with. That’s always tough after a major release, but Pam’s suggestion makes sense.

Posted in General | Leave a comment

Nat Sakimura on OpenID and XRI

Posted on 9/23/2008 by Drummond Reed

Nat Sakimura, who is quietly implementing real user-centric identity solutions in the Japanese market while many others are still talking about them, has posted his concise reasoning why XRI abstract identifiers are the the only really safe identifiers to use with OpenID.

The whole question of the differences between abstract and concrete identifiers, currently being explored in depth in conversations between the W3C TAG and the OASIS XRI TC, may turn out to be a crucial one for the soon-to-begin work on OpenID 2.1. When it comes to security, privacy, and usability, the differences really start to add up.

Posted in OpenID, Practical I-Names, XRI | Tagged , , | Leave a comment

Fall IIW: Don't Miss It

Posted on 9/20/2008 by Drummond Reed

I was just telling a colleague in the identity industry that so many meetings are being planned for the Fall IIW, Nov. 10-12 in Mountain View, CA, that I’m not sure that there will be any time for anything else.

And it always what’s NOT planned that makes it so unforgettable.

What can I say? Don’t miss it.

IIW2008 Registration banner

Posted in Identity Commons | Tagged , | 1 Comment

XRI in a Nutshell

Posted on 9/6/2008 by Drummond Reed

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 http://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).

Posted in OpenID, Practical I-Names, XRDS, XRI | Tagged , , | 2 Comments

Eve Finds Another Intersection

Posted on 9/4/2008 by Drummond Reed

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 = 🙂

Posted in Data Portability, General, I-Cards, Information cards, OpenID, Privacy, R-Cards, Relationship cards, Social Web, VRM, XDI | Tagged , , | Leave a comment

Identity Happens with Marty Schleiff

Posted on 8/11/2008 by Drummond Reed

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.

Posted in Blogging, XRI | Tagged , | Leave a comment

Phil Windley on Relationship Providers

Posted on 8/6/2008 by Drummond Reed

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.

Posted in Blogging, R-Cards, Relationship cards, VRM | Leave a comment

Robert Pirsig Explains Vacation Zen

Posted on 8/5/2008 by Drummond Reed

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.

Posted in Blogging, vacations | Leave a comment

Vacation Beckons

Posted on 7/20/2008 by Drummond Reed

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).

Posted in Blogging, General | Leave a comment

Joe Nails it Open

Posted on 7/13/2008 by Drummond Reed

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!

Posted in Dataweb, General, VRM, XDI | Tagged , | Leave a comment

Principles of VRM

Posted on 7/9/2008 by Drummond Reed

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.

Posted in Higgins, Identity Rights Agreements, R-Cards, Relationship cards, VRM, XDI | Tagged , , | 1 Comment

Relationship Cards (R-Cards)

Posted on 7/1/2008 by Drummond Reed

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!

Posted in Data Portability, General, Higgins, I-Cards, Identity Rights Agreements, Information cards, R-Cards, Relationship cards, Social Web, VRM, XDI, XRDS | Tagged , , , , , | 2 Comments

Pamela Dingle: My Favorite Bio

Posted on 6/25/2008 by Drummond Reed

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.

Posted in Blogging, General, I-Cards | Tagged , , , , | 2 Comments

The Information Card Foundation: Helping Scale Mount Identity

Posted on 6/24/2008 by Drummond Reed

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.

Posted in CardSpace, General, I-Cards, Identity Commons, OpenID, Relationship cards, SAML, Social Web | Tagged , , , , , | 1 Comment

Joe Andrieu Answers Questions about VRM

Posted on 6/14/2008 by Drummond Reed

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.

Posted in Blogging, VRM | Leave a comment

Paul Madsen Sums It Up

Posted on 6/3/2008 by Drummond Reed

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.

Posted in General | Leave a comment