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