Equals Drummond

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

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

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

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

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

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

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

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

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

And just imagine the view from there.

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

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

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

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

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

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

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

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

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

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

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

Speaking of great posts and great pictures, I think Eve Maler’s recent Venn of Identity diagram is the best thumbnail picture of “Internet identity space” I’ve ever seen. She credits both Johannes Ernst and Paul Madsen for the progenitors. Eve’s Venn diagram approach to the “three corners” capture the subtlety of the overlap very nicely.

Makes me look forward to the next Internet Identity Workshop May 14-16 to see the next evolutionary leap. Don’t forget to register early.

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

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

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

The Power of Abstraction

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

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

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

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

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

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

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

=kim.cameron

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Earlier this month Kim Cameron starting blogging about some of the phishing concerns he’s had about OpenID that he and Mike Jones have shared with myself and other members of the OpenID community privately since Digital ID World last September. Given that anti-phishing protection is one of the greatest strengths of CardSpace, one of Kim’s and Mike’s suggestions has been for OpenID providers to start accepting CardSpace cards for customer authentication.

Today Kim blogged his proposed solution for integrating OpenID and InfoCard in detail. He does a wonderful job of it, making it very clear how using CardSpace and OpenID together can be a win/win for both. With Windows Vista shipping to consumers at the end of the month, and the CardSpace upgrade now available to XP users, this is a very practical solution to increasing OpenID security that I expect all XDI.org-accredited i-brokers (who all provide OpenID authentication service for i-name holders) to implement as soon as they can.

Kim closes his post by saying, “That said, I have another proposal [for integrating OpenID and CardSpace] as well.” That’s good, and I await it eagerly, because I too believe the integration can go much deeper, just as it can for OpenID and SAML. The heart of it is individuals and organizations being able to assert their own resolvable, privacy-protected digital identifiers. That’s the foundation of the OpenID framework, and the job for which we’ve been designing XRI i-names and i-numbers for the past five years. Microsoft’s current default CardSpace schema does not yet natively support XRIs as digital identifiers, but adding them could increase their power and utility and be another big step towards convergence on a unified Internet identity layer.