Equals Drummond

I could spend this entire week doing nothing but reading and posting about good post-holiday reading of recent blog posts. My theory is simple: over the holiday break, people (well, most people – not me this year) have time to take a breather and write down something that’s really been on their minds.

And because they are not rushed, they have time to condense and sharpen their thoughts, and the result is a rash of excellent blog posts.

A wonderful example is Will Norris’ post about identity and identifiers. He speaks from long experience (and he’s worked on several identity protocols, including OpenID and SAML, as part of the Shibboleth project).

Read it and weep (if you have a recyclable OpenID).

(Aside: Although, as Will’s article intimates, XRI architecture solves this problem at the structural level, the implementation of XRI across OpenID 2.0 sites and libraries is currently very uneven. So IMHO realistically a full solution to the recyclable identifier problem with OpenID is still another protocol generation away.)

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.

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.

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 =

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.

Ryan Janssen pinged me via my contact page last week to ask if I had time to share the story of how I came to be working on XRI, XDI, OpenID, i-cards, Higgins, and Identity Commons. He reached me this afternoon and we talked for almost two hours. Boy, did it bring back memories. I’m so focused on building out working identity infrastructure and applications based on all these standards and projects that I rarely have a moment to reflect on how many twists and turns (and dollars) its taken to get here. So this was a full-out stroll in the park.

He’s posted an overview and will be writing more as he talks to others who have been pounding away forging this Internet identity layer. Ryan’s really done his homework too — he even included a link at the end to the original XDI white paper that co-chair Geoffrey Strongin and I contributed at the start of the OASIS XDI Technical Committee in early 2004. Wow, did that trip off the old synapses. Most fascinating is seeing the original proposed XDI schema which had just four elements. Four years later, after numerous twists and turns (and by my count 23 intermediate proposals), the XDI RDF model has…four elements (plus the XDI wrapper element). It’s not the same schema (now it’s based on the RDF graph model) — and in fact the preferred serialization is no longer even XML (it’s X3). But it’s uncannily close.

Deju vu all over again…

When people talk about Internet innovations coming from the “grassroots”, they are going to use OpenID as the textbook case. From Brad Fitzpatrick’s original protocol in 2005 to today’s announcement that Yahoo, Google, Microsoft, IBM, and Verisign were joining the OpenID Foundation — that’s a remarkable evolution.

And the evolution of the OpenID community and the development of the OpenID Foundation to support this effort is going to be another chapter in the textbook. If you want to see OpenID flourish, please do join us.
There’s still a long row to hoe yet — I don’t think we’ve seen but the tip of the iceburg of what’s going to happen with Internet identity by the end of the decade. But it’s too late tonight to speculate on that — must get some sleep and get back to building it. (How I do wish some days for some more blogging time…)

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.

I just added XRDS (Extensible Resource Descriptor Sequence) as a new category on my blog because this simple XML document format, created by the OASIS XRI Technical Committee to provide XRI resolution metadata and subsequently adopted by Yadis, is starting to gain attention as the discovery format for OpenID.

Phil Windley just posted a good overview of XRDS today. For even more detail about XRDS (and OpenID in general) see this article written for the Java community — perhaps the single best technical article on OpenID I’ve read.

I haven’t blogged in a month because I’m so heads down with XRI 2.1 specs, prep for IIW (next week), and the business side of user-centric identity (yes, this really needs to turn into an industry if it is to ever really matter). But I could not help but note the explosion of discussion around Tim Bray’s post that Sun will be using OpenID and — gasp! — actually providing a semantically meaningful OpenID identifier! I can’t reference the discussion on the Identity Gang mailing list per community agreement, but see:

• Paul Madsen’s post.
• Eve Maler’s post.

If this raises a ruckus, imagine the concept of an entire LANGUAGE for machine-proveable assertions using machine-readable identifiers. Imagine if Sun could move from it’s current “tincture of trust” to a simple yet provable assertion like…

@sun+employee=example.name

…which is itself would be a valid OpenID under the proposed OpenID 2.0 spec and the proposed XRI 2.1 syntax.
With XRI 2.1 and the XDI RDF model, about which I’ll start blogging much more extensively after IIW, that’s what we’ll have laid the foundation for. A semantic web where the semantics are actually in the identfiers.

Exactly the way it works with human language.

What a concept.

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.

Victor Grey, co-founder of i-broker 2idi with Fen Labalme, has always been one of my favorite cats in the identity universe, but you need to know him well enough to coax out his deep wisdom. Now that he’s blogging, you can sample it directly. I particularly love this entry on why he called his blog TATWD (Turtles All The Way Down) — one of our favorite expressions on the OASIS XDI Technical Committee.

Victor also has some wise observations about the extensive phishing debate around OpenID.

Enjoy!

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.

If you want to follow the real down-and-dirty of what the identity layer will become, catch Jeff Hodges blog at identitymeme.org. Before he joined NeuStar two years ago (lured by Peter Davis among others), Jeff was with Oblix and Sun and is the editor of several Liberty Alliance specifications. He also co-chaired the OASIS Security Services TC (producers of SAML). He’s currently working with Eve Maler’s “SAMListas” looking hard at the intersection of SAML, OpenID, and XRI.

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.

Eve Maler called it a “swirling nexus”. That’s appropriate for both the weather and the dance of discussions at an informal meeting last week between SAMListas (Eve’s term) and OpenIDear’s (my term) hosted by JanRain last week in Portland. Eve blogs it here and David Recordon here.

Eve’s writeup is so comprehensive that I don’t have much to add, other than to say that that more than ever the forces pushing us towards a fully converged Internet identity layer are gaining momentum. See my next post for more.

This play on Salvador Dali’s famous painting “The Persistence of Time” is to point out a principle that seems to recur with every evolutionary step of Internet identity architecture: the fundamental importance of persistent identifiers.

For example, last week on the OpenID General mailing list, I answered a question about the difference between using URLs and XRIs as OpenID identifiers by explaining that URLs, being based on DNS names or IP addresses, have the inherent problem that they are reassignable. As I explained in an earlier post, in an Internet identity architecture like OpenID in which your identifier is the entire key to your identity (because it is resolved to determine the identity provider from which an authentication assertion can be requested), using a reassignable identifier means your entire identity can be “taken over” if the domain name or IP address of your URL is ever reassigned. This would be tantamount to a U.S. citizen having their Social Security Number reassigned to another citizen, but even worse because there would be nothing in the infrastructure at all to prevent this, or even signal that there was something wrong.

I went on to explain:

XRI infrastructure solves this problem by explicitly supporting reassignable identifiers (i-names) and persistent identifiers (i-numbers) and permitting the resolution of any reassignable i-name to be mapped immediately to a synonymous, never-reassigned i-number which can be safely stored by an OpenID Relying Party without exposing the identity owner to the risk of having their i-name “taken over”.

Bob Wyman responded with a very important point:

The XRI Syntax specification says that a Persistent Identifier is “An identifier that is permanently assigned to a resource and intended never to be reassigned to another resource.” While it may well be the “intention” that such persistent identifiers are never to be reassigned, one must accept that an “identity owner” is, in fact, exposed to some risk of having their i-name ‘taken over’” in the case of unintended events. There is nothing technical which prevents the taking over of XRI persistent identifiers. The only thing that reduces risk here is people’s and organization’s willingness and ability to follow the rules. Such trust may well be reasonably held, but there remains an ineradicable risk of entities’ failure to perform as intended… (Note: The previous comments should not be taken as a criticism of XRI. This ‘risk’ is an inevitable characteristic of this class of system and of this type of “solution”.)

So important is Bob’s point that today I replied with the following:

Bob is absolutely right that there is nothing inherent in the technical aspects of XRI architecture — nor was there in the URN (Uniform Resource Name) architecture that came before it – to prevent the reassignment of an identifier intended to be persistent (which both XRI i-numbers and URNs are). Such protection is afforded *entirely* by the operational policies of the authority assigning the identifier, i.e., the registry.Part of the reason URNs did not catch on (besides the fact they are typically very un-human-friendly identifiers) is that the operational requirements of a URN registry are so dramatically different than a DNS registry. A URN is assigned once and never reassigned, where as a domain name is registered for a specified period and then either renewed or the registration expires and it is returned to the pool of names available for registration.

As I explained in the previous thread, one of the primary motivations for the development of XRI architecture was to bring both reassignable and persistent identifiers together under one unified registration and resolution architecture that could not only solve the usability issues of persistent identifiers (by permitting them to be discovered via human-friendly synonyms), but to enable a new type of registry that supports policies for *both* reassignable and persistent identifiers.

XDI.org is (to my knowledge) the first global identifier registry infrastructure developed using this model. Although the details are probably far too esoteric for most members of this list, if you find yourself interested in the policies of a global registry infrastructure that supports the registration of both reassignable and persistent identifiers, by all means visit the XDI.org Global Services Specifications site and review the main GSS document, in particular the section on I-Numbers.

Net net: as OpenID spreads, so will recognition of the value of having a persistent identifier at the root of an OpenID identity – and so will appreciation of an identifier infrastructure designed from top to bottom to support the policies necessary to make reliance on these persistent identifiers a reasonable risk.

Mark my words as we head into 2007 (which I’ve already heard predicted as “the year of OpenID”): the need to use persistent identifiers to provide long-term Internet identity protection will finally start getting the attention it deserves.

I hadn’t blogged yet about the excellent session Salim Ismail led on Creative Uses of I-Names at Internet Identity Workshop two weeks ago, but Phil Windley did, and then yesterday he posted a longer piece about XRI and i-names on his ZDNet blog. So now I’ve really got some responding to do. Herewith a frank assessment of the current state of the XRI/i-names universe.

The Good

Phil’s writeup is a great overview of what this new type of Internet identifier is about and why it’s relevant to user-centric identity. He sums up the value proposition of a personal i-name this way:

What’s the point? Easy: I own =windley, my i-name, for the next 50 years and I control the resolution. If my blog URL or my Skype handle changes, I can change how those XRIs resolve and you can still find me and all the services related to me. Plus, the XRIs above are (mostly) based on a standard semantics, so if I know your i-name, I can easily find your blog.

Phil nails the fundamental reason that the XRI standard was created: to add an additional layer of indirection on top of DNS- and IP-based URLs that gives an XRI registrant (a person, an organization, or a standards body) control over their persistent identity and relationships.

Phil also nails the second key benefit of this additional layer of indirection: semantic mapping. XRI is (to my knowledge) the first Internet identifier syntax designed expressly for the sharing of identifiers across domains. In fact two XRI syntax characters are reserved for this purpose: +, for general dictionary tags like +blog, +salmon, +love, +jupiter; and $, for special dictionary tags like $v (version), $d (date), and $l (language).

These $words, as they tend to be called, are defined in XRI dictionaries by standards bodies like OASIS specifically to enable resource identifiers to share semantics. For example, the $v space provides a domain-independent, machine-readable syntax for describing the version of a resource. Take the following three XRIs: they all identify version #2.1 of a resource (a blog post, webpage, and newspaper edition, respectively).

• =drummond/(+blog)/(+post)*88*($v*2.1)
• @cordance/(+website)/(+page)*143*($v*2.1)
• @example.newspaper/(+edition)/($date*2006-12-19)*($v*2.1)

The Bad

Phil also hits on one of the main complaints about XRIs: they look strange and their features are as-yet little understood. As Phil says:

XRIs are more complicated than URLs, but I remember everyone screwing up their face when URLs were new too and somehow we got used to them. XRIs make up for their additional complexity in semantic mappings and flexibility.

I think Phil’s right about people getting used to the syntax (especially for easy XRIs like =windley). We’re also doing more on the OASIS XRI TC to continue to make the syntax more human-friendly. But that’s not the most confusing part. By far the hardest-to-understand feature of XRI architecture is how it enables persistent Internet identity. Phil’s article puts it this way:

Further, i-names are not reassignable (unlike domain names), so when you contact the person at =windley, you know it’s me, not just the next guy to pick up the name when I let it expire.

Unfortunately that’s not quite right – which reflects how hard this part of XRI architecture can be to grasp initially. Here’s a brief attempt to unfog it:

To solve the problem of persistent identification of a resource — anything from a person to a white paper — XRI syntax defines two forms of XRIs, known informally as i-names and i-numbers. I-names are simple and human-friendly identifiers like =windley. I-numbers are typically ugly machine-friendly identifiers like =!92E6.7E3C.B5D0.9D7E. Note that both start with an equals sign to tell you they are in the same XRI global namespace, in this case = for individual persons (as opposed to @ for organizations, + for generic tags, $ for standardized tags, and ! for networks). What distinguishes the i-number from the i-name is the ! (bang) character after the initial symbol. Bang is the XRI prefix character for a persistent identifier.

The reason for this special syntax character is that unlike i-names, which are intented to be reassignable identifiers just like domain names, i-numbers are intended to be persistent, i.e., never reassigned. (Technically this latter type of persistent identifier is called a URN – Uniform Resource Name).

I say “intended” because the persistence of an identifier cannot be enforced by technology alone, but only by the operational policies of the assigning authority, in this case an XRI registry. That’s why when you register a global i-name with an XDI.org-accredited i-broker (similar to an ICANN-accredited DNS registrar), the XDI.org Global Services Specification policies require that:

1. The XRI Global Registry Service (GRS) must assign you a synonymous i-number, and
2. The GRS must NEVER reassigned this i-number to another registrant again (for eternity). For example, the i-number synonym for Phil’s =windley i-name is =!92E6.7E3C.B5D0.9D7E, and this i-number will NEVER be reassigned to another registrant.

However Phil’s =windley i-name can be reassigned, just like a domain name, either when it expires, or by Phil selling or transfering it to someone else, just like a domain name. Phil has the ability to do that as long as he’s the registrant, which in his case is at least 50 years (because he registered it during the special XDI.org beta program – now that the GRS is live the longest registration currently available is 10 years, the same as most DNS registries.)

However Phil was right on about his identity being protected from “takeover” by another registrant of =windley because XRI-based applications always key on the persistent i-number and not the reassignable i-name. For example, the OpenID Authentication 2.0 specification (which is tantalizingly close to being final, and which supports both URLs and XRIs as user identifiers) explicitly states that when a user logs in with an XRI (typically an i-name), the relying party MUST resolve it and store its synonymous i-number as the persistent identifier for the user. The reason is simple: the user’s i-number will never be reassigned, so even if the i-name =windley expires and is re-registered by someone else (or Phil sells or transfers it), the i-number for the new registrant will be different. So the new owner of =windley can’t go to websites where Phil has used =windley and login as Phil because the website’s database “knows” Phil as =!92E6.7E3C.B5D0.9D7E, and the new owner of =windley will have a different i-number.

There’s another benefit to this XRI synonym architecture, by the way: Phil can register other i-names in addition to =windley as synonyms for his =!92E6.7E3C.B5D0.9D7E i-number and then use any of them to login as this “persona” because they will all by synonymous with the same i-number. For example, I use both =drummond and =drummond.reed as synonyms for my i-number =!F83.62B1.44F.2813 (the one I use depends on the context of where I’m using my i-name, i.e., do I want to reveal my last name or not?)

The Unfinished

So we’re making progress, and it’s very encouraging that digital identity experts like Phil are recognizing the power of the XRI layer of indirection to provide control, persistence, and semantic mapping for the emerging layer of user-centric identity. But as Phil discussed with me after the IIW session on i-names, the remaining hurdle is finishing all the pieces of XRI infrastructure necessary to fully support identity-enabled applications the same way DNS infrastructure had to be in place to support the emergence of the Web.

He’s hardly the only one. That same week on the OpenID mailing lists, David Recordon forwarded a message from Brad Fitzpatrick, originator of OpenID, that summarized one of the main things he doesn’t like about XRI:

- implementations lacking. probably because spec not stable?
particularly hate the answer of using proxy resolvers because it’s
too difficult(!?) to do otherwise.

At IIW, my XRI TC co-chair Gabe Wachob and I found ourselves apologizing to person after person who buttonholed us about the status of specific elements of XRI infrastructure. We sounded like a broken record: “We know it’s not all done yet; we’re working on it as fast as we can; please be patient.”

Gabe took out his frustration by writing a blog entry called The Thrill of the Hack (TOTH) in which he says:

I’m concerned that the i-names community has failed to enable TOTH. We have efforts in most of the directions (hangout, open source, a good IPR policy, a busy developer guide, community support), but they all need more work. Much of the effort on i-names has focused on communicating how i-names are usable to end users. But we haven’t enabled developers to make i-names (and even XRI, which doesn’t necessarily rely on the global root directories) ubiquitous and we haven’t enabled developers to go beyond what we’ve envisioned and come up with the really killer apps.

I’ve heard a lot of the frustration from folks who are interested in playing with i-names, and I want to you know that we hear you, and we understand. In fact, I share that very frustration with you.

So here’s my early New Year’s Resolution, to Phil and Gabe and everyone else wanting to see XRI infrastructure turn into the tool we all want to be. I will do my utmost to see the following completed as early in 2007 as possible:

The OASIS XRI 2.0 specification suite. While XRI Syntax 2.0 has been done for a year now, and XRI Resolution 2.0 has been stable at Working Draft 10 since the spring, both still need one more set of revisions before they are ready for a full OASIS Standard level vote. The third specification, XRI $ Dictionary 2.0 (formerly XRI Metadata), is especially needed for interoperable identifiers in the enterprise space, so we want to get that out ASAP too. Cordance is committed to hiring another full time spec editor to help make this happen.

The OpenXRI 2.0 open source code base. The OpenXRI project was started to become the “BIND of XRI” (Gabe winces when I say that because BIND was notorious for its security flaws; we’re not planning to repeat that here.) This is the code that anyone from from an individual developer to an huge ISP or portal shoud be able to use to operate their XRI infrastructure the same way they run BIND (or another DNS nameserver/resolver package) to operate their DNS infrastructure. It’s currently in Java; we need to complete the resolver, authority server, and proxy server to the 2.0 specs, then start porting it to other platforms.

Documentation, tutorials, and examples. The XRI/i-names community needs to make it exponentially easier for developers, Web architects, ISPs, governments, and others who are interested in deploying XRI infrastructure to get the information they need quickly, easily, and reliably. Several projects such as dev.inames.net have started to fill this need, but they need much more work before they come close to filling the need.

Those of you who know me know how hard I am working personally – and how hard I am flogging Cordance, NeuStar, AmSoft, XDI.org, XDI.org-Accredited I-Brokers, and other companies supplying XRI infrastructure and services – to complete these crucial pieces of the XRI puzzle. I promise that Gabe and I will blog regular reports on our progress throughout 2007.

Also, if you know of individuals or organizations who may be interested in helping, please send them to Gabe or myself (via his or my i-name contact page of course) and we’ll make sure they are plugged in to the right place.

Ever since the last Internet Identity Workshop I’ve been running like mad trying to finish spec assignments, catch up on email, and prep for the holidays. Not to mention catch up on blog posts (Why anyone calls December “the holidays” is beyond me

First up is a comment back from Mike Jones of Microsoft regarding my plea that CardSpace and OpenID UX designers help each other in the user experience shift embodied in user-centric identity. Mike says:

In response to your question “How can we help each other?”, the first step to me seems to be for the OpenID providers to allow people to sign into their OpenIDs with InfoCards, rather than username/password. Then OpenID users will automatically gain all the benefits of the CardSpace user experience ceremony.

Mike’s right that Microsoft has put thousands of man-hours into designing the Cardspace UX, including the extensive anti-phishing provisions. Any OpenID provider can take advantage of that just by supporting Cardspace-based login instead of much weaker username/password login. That’s a great first step.

I think there will be much more to Cardspace and OpenID integration if the demos at IIW were any indication, but I’ll reserve that for future blog posts (after I finish my Xmas shopping).