← Mike Jones on Cardspace & OpenID Synergy

The Persistence of Persistence →

Posted on 12/19/2006 by Drummond Reed

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.

This entry was posted in Blogging, General, I-brokers, OpenID, Practical I-Names, XRI. Bookmark the permalink.

← Mike Jones on Cardspace & OpenID Synergy

The Persistence of Persistence →