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

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

Last week I had a long talk about XRI with Phil Windley and Scott Lemon that they just posted as an IT Conversations podcast. If you ever wanted to know the full XRI story from start to finish (verbally, at least), this is the podcast for you. Phil tends to draw out the details from me, so there’s quite a bit of “verbal whiteboarding” (I live for whiteboards), but altogether it amounts the most comprehensive oral summary of XRI I’ve ever done.

After all, the point of this blog is that identifiers matter. Few people understand just how much.

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.

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.

I-name forwarding service is finally here! At last we’re tapping some of the power of XRI resolution infrastructure — and demonstrating why I named this blog “=drummond”. Following is the new i-name of my blog:

http://xri.net/=drummond/(+blog)

And following is the i-name for my current work context, whatever that may be at any point in time (currently Cordance Corporation):

http://xri.net/=drummond/(+work)

Both examples use the very simple first-generation XRI tag dictionary (+names) that’s in the XDI.org Forwarding Service specification. The advantage of +names is that as the +tag dictionary grows (and the XDI.org community has grands plans for how to do this), it makes it easy to find what you’re looking for without having to guess what someone else called it. (It also explains the funny parentheses — “+blog” is its own separately-resolvable XRI, and the parentheses tell an XRI parser this. To make it easier for people to type in an address bar, it will actually work without the parents, i.e., http://xri.net/=drummond/+blog.

But a forwarding XRI doesn’t have to use an i-name dictionary — it can also use standard HTTP URI path and query syntax. For example, I created the following XRI…

http://xri.net/=drummond/sws

…just so I never have to remember the website name for my son’s school (Seattle Waldorf School).

Finally, a simple way I can manage the names I want for anything on the Web I want.

I haven’t posted for a month. Beside’s the fact that it was August (a sacred month in Seattle), it was also prep for Digital ID World this week in Santa Clara, where XDI.org-accredited i-brokers are introducing support for OpenID 1.1, as well as interoperable contact and forwarding services.

And during the three days of the show (Monday-Wednesday), you can register a 1-year global personal i-name (=name) from any XDI.org-accredited i-broker for just US$5.00. A true personal digital address you can keep for life for less than a domain name.

Now that’s practical.

P.S. During this special, 1id.com is also running a special contest this week for a U2 iPod. Just submit your idea for the coolest i-name application.

INITECH is the first XDI.org-accredited i-broker to provide three i-services for their i-name customer — they just went live with SAML-based i-name Single Sign-On (i-SSO), Contact and Forwarding services.

You can see these services at work with their own i-name, @greenbutton. You can visit their contact page at http://xri.net/@greenbutton and see how contact requests are authenticated with either an i-name or email address, effectively eliminating spam (more on that subject in a future post).

Note that only SAML authentication is available currently, but OpenID authentication will be available by September. I-names will be the first digital address to support both SAML and OpenID authentication.

For more about Greenbutton, INITECH’s i-broker service, visit them at http://www.gbtn.biz/.

I should have suspected this — we finally get to the biggest inflection point in the evolution of i-names and I’m too busy to blog about it.

Oh well, that’s life. In less than two hours we finally flip the switch on the first user-centric digital address registry. See the news at http://biz.yahoo.com/prnews/060620/nytu091.html?.v=54

The ceremony itself is going to be the simultaneous popping of a dozen champagne bottles (some non-alcoholic) representing the first 7 i-brokers (see the list), 4 XRI registry infrastructure developers (XDI.org, Cordance, NeuStar, and AmSoft), and 1 for the users of the world to whom this is all dedicated (and whom we’re asking Doc Searls to represent. After all, as Paul Trevithick put it in a session this morning, all of us in user-centric identity ultimately “work for Doc”.)

My hope is that this is one more tangible step in the road to Doc’s vision of Internet identity infrastructure that truly empowers all of us as users.

When I can’t do a post for a month you know something’s up (or down). But this one’s up: XDI.org has finally finished and approved the Global Services Specification (GSS) that governs the operation of XDI.org’s global XRI i-name and i-number registry services (GRS). The press release of the announcement went out today.

This paves the way for a formal opening of the GRS at 7PM ET next Tuesday evening in a live ceremony at the Berkman Identity Mashup. The participating i-brokers (from 3 continents) will be announced next week at the conference.

Better still, the GSS specifies that XDI.org-accredited i-brokers will support both OpenID and SAML. That means i-name owners will be able to authenticate and share data with any site that speaks either one of these protocols.

Convergence towards real operating identity infrastructure is going to be a major theme next week. I can hardly wait. It’s only been, what, 12 years…

See the Internet Identity Workshop wiki for info about a morning meeting for developers to be held at Cafe Won Ton in the Fulsom neighborhood of S.F. next Monday, 2005/12/12, before the Syndicate conference. It’ll be a great chance to see how new identity technologies — XRI/i-names, OpenID, LID, SXIP, YADIS, Yoke – fit together to start offering real, interoperable user-centric identity solutions to requirements Web developers face every time they have to build a new site.

Andy Dale has started to blog about where all this XDI stuff is going at ooTao: DataTao. DataTao is (to my knowledge) the first pure data sharing service. In other words, any individual or organization with an i-name will be able to open a free account at DataTao and establish it as the “home base” for their personal or business data. DataTao will then enable the account owner to publish the data to any subscribing party (individual or organization) in any supported format (XDI, LID, SXIP, etc.)

The DataTao data brokering model does not require that DataTao be the authoritative source for the data, any more than a bank requires that it be the only place you can store your money. If you already have another authoritative source for some data — for example, if your Books We Like account is already authoritative for your book-buying preferences — then you just tell DataTao to subscribe to that data source. Now you’re empowered to share that data with anyone you like, under the terms you set as the data authority (which will be even easier the subscriber is a member of Identity Commons, because a key goal of IC is to help standardize common data sharing agreements.)

How excited am I about the DataTao model? After more than a decade of working on the underlying technologies that make it possible, I can’t wait to be the first one beating down their door to finally have one place to manage and control all my personal data sharing. I’m hoping that DataTao will become the model for data brokering that 2idi has been for i-brokering.

Go Andy! (And Steve, and Barry, and Justine, and all the other members of the DataTao team!)

My sparcity of posts in August equates directly to the intensity of work going on right now on the XRI 2.0 specifications at OASIS. After the XRI 2.0 Committee Draft 01 specifications were approved by the XRI Technical Committee (TC) in March, they underwent a public review period which drew a variety of excellent comments. This plus implementation feedback from a growing community of both commercial and open source implementers is now being folded into the Committee Draft 02 specifications which are scheduled for a TC vote by mid-October and an OASIS-wide vote in December.

When you’re this close to the open standards “sausage making” process, it’s nice to see growing recognition of how these standards can solve the problems they were designed for. A wonderful example is the article Mary Hodder (Napsterization) about the recent Yahoo/Flicker ID snafu. She does a great job of explaining how i-names (XRIs that functional as universal, privacy-protected addresses for people or organizations) could avoid this problem altogether.

And Phil Windley, who is co-hosting the Internet Identity Workshop in Berkeley in October, adds his perspective to Mary’s in his post at Between the Lines.

(And that’s before we even get to how XRIs can help with the Open Tagging problem, a subject about which I am very excited and only wish I had more time to work on. But first let’s get XRI 2.0 out the door!!!)

Owen Davis, co-founder and president of Identity Commons, has switched his blog from http://blog.whatbox.biz to the new Identity Commons community blog at http://news.idcommons.net.

But the bigger news is that: this is one of the first i-name enabled blogs, i.e., it accepts an i-name for both site registration and comment authentication. Try it out – just click the comment link on any article.

Attendees at DIDW 2005 last week received a free 50-year global personal i-name (an “=name”) courtesy of Identity Commons. This is part of the early i-name registration program also sponsored by XDI.ORG, 2idi (i-broker for the program), Cordance (my employer), and NeuStar (operator of global i-name registry services).

Those who were new to i-names had many practical questions, summed up by =dizzyd who blogged:

The immediate problem, of course, is that if I give my i-name to someone outside of the digitial identity space, they’re not going to know what to do with it. Socially, there is no context for this identifier, and even worse, there aren’t any obvious tools available to the average user which would allow them “use” my i-name to contact me. Now, I’m willing to concede that this may just be due to the fact that i-names are not yet popular, and like any new identifier, will just require some time to get fixed in the social awareness. However, that’s not going to happen if the i-name people (XRI/XDI, as I understand it) don’t come up with some useful, or at least well publicized tools. If they exist, I would gladly accept pointers.

Great point, and one being worked assiduously by the XRI/XDI community. So here’s a summary of the first three services being developed for i-names (note that only the first is full available today – the next two are planned for general introduction once full global i-name registry services are operational this fall.)

1. Privacy-protected address service. This allows you to use the http form of your i-name as a link to a contact page hosted by your i-broker (such as 2idi). Contact pages are searchable Web pages that accept incoming contact requests which are verified by the i-broker to prevent spam. Bloggers like Kim Cameron use this service today as a way to accept comments without comment spam (see his i-name contact link on the right frame of his blog.) Or visit my own =Drummond contact page.
2. I-name single sign-on (ISSO) service. This allows you to use your i-name and i-broker password to log on at any ISSO enabled website. Although a non-SAML form of ISSO is already in use by 2idi and some of its partner sites, fully SAML 2.0 compliant ISSO is under development and should be in testing shortly. See the ISSO spec page at XDI.ORG for more details.
3. I-share data sharing service. I-share is essentially “IM for data sharing” — a simple, universal way to share and permanently synchronize common types of data (business cards, files, links, agendas, itineraries) using using i-names and i-numbers. I-share will be the first general use of the XDI data sharing protocol under development by the OASIS XDI Technical Committee.

=dizzyd goes on to ask a second question that comes up often:

On a less practical note, it bugs me that i-names are essentially attempting to create a global address space for the whole Internet. What I mean by this, is that by default i-names are global, so there can only be one “=dizzyd” for the whole Internet. From an identifier standpoint, i-names are regressing us back to the days of “bob394″ and “alice2zz”. Imagine how life would be if we only had first names — how would we distinguish between this Bob and that Bob? The reality is that the Internet is a big place and it needs an addressing scheme that reflects at least some understanding of the scale involved. Email addresses may not be the perfect answer, but at least they add an intermediate partioning of the address space that more closely reflects how big the ‘Net is.

Unfortunately this is a misconception that shows the XRI/XDI community has a lot of market education to do about XRIs. In reality, XRI syntax and resolution infrastructure is designed to be at least as partionable as URIs, DNS names, and IP addresses (principally because XRIs layer over these as abstract identifiers.)

In particular, what might not be clear to a new =name registrant is that they have registered the XRI equivalent of a first-level domain. In other words, if their i-broker supports it, they can now delegate second-level i-names the same way domain name registrants can delegate DNS names under their domain name (i.e., “example.com” can delegate “www.example.com”, “mail.example.com”, “ftp.example.com”, etc.) The only difference is that with i-names: a) delegation always works from left-to-right, and b) the delegation character is * instead of dot (dots are legal characters in i-names.) Examples:

=dizzyd*john
=dizzyd*jerry.johnson
=dizzyd*jerry.johnson*mary.johnson


In other words, every registrant of a global =name can serve as their own registry of delegated *names (and each of their delegates can delegate third-level *names, and so on.) Unlike typical DNS delegation, i-brokers can make this very easy and consumer-friendly, so it will be easy, for example, for a family member to delegate *names to other family members. Organizational i-names (@names) can do the same thing, delegating *names to other organizations or individuals, again to any depth. For example:

@Example.Corp
@Example.Corp*East.Coast
@Example.Corp*West.Coast
@Example.Corp*West.Coast*Portland
@Example.Corp*West.Coast*Seattle
@Example.Corp*Jerry.Johnson

Note this last example (Example Corp delegating to Jerry Johnson) is essentially the XRI equivalent of an email address (i.e., an organizational authority delegating to an individual.) This demonstrates that XRI syntax provides partitioning at least as flexible and scalable as URI syntax (i.e., DNS names and IP address), while at the same time providing a richer human-friendly naming syntax (dots and colons in addition to dashes, plus support for the full Unicode character set).

(Note: To keep this short, I’m leaving out some other key XRI features – persistent i-numbers and cross-references – that we’ll cover in other Practical I-Names columns.)

Got more “Practical I-Names” questions? If you don’t already have my email address, feel free to send them to me via my i-name contact page at =Drummond.