[OpenID] Benefits of XRI i-names/i-numbers as OpenIDs

Drummond Reed drummond.reed at cordance.net
Mon Feb 12 23:37:37 UTC 2007

>Martin Atkins wrote:
>I don't wish to pick on you Drummond, but I do feel the need to chime in 
>here and poke holes in your advantages. :)

Martin, never worry about that. Us XRI people have thick skins, or we never would have survived this long ;-)

Seriously, I answered Simon's original question so we could have a healthy discussion about what benefits XRIs can or can't bring to OpenID. This thread really helps get down to the nitty gritty realities.

>Drummond Reed wrote:
>> * Security: you don't have to enter https:// in front of an i-name. It's
>> built in, i.e., the entire resolution network supports https. So you avoid
>> the whole problem with the default for URLs being http instead of https.
>This can be achieved with URLs by making the http: URL redirect to the 
>https: one. While it's true that a Man In The Middle could intercept the 
>initial request to the http: URL and cause it to resolve elsewhere, they 
>would at worst end up claming the http: URL, not the https: one, so your 
>existing identity attached to the https: URL is still safe.

I agree that this workaround can be deployed, but there's been a lot of discussion in the specs development process about the fact that it's still not ideal. All I was trying to point out was that XRIs, since they are abstract, sidestep the entire problem by supporting all-https resolution all the time. (They also support an even stronger SAML-based trusted resolution, but that's another story.)

>> * Privacy: if you want full control of your URL you need to register your
>> own global domain name, which requires either publishing Whois contact data
>> or paying your DNS registrar for a proxy registration service (which
>> typically costs more than the domain name). The global i-name infrastructure
>> operated by XDI.org has much stronger privacy built-in (there is no Whois
>> service) and at no extra cost.
>As another responder pointed out, this is a registry policy issue rather 
>than a protocol issue. There are many domain registries that don't make 
>registrant contact details publically available, and no technical reason 
>why the XDI equivalent to a domain registrar couldn't choose to publish 
>"whois"-type information for the i-names that they acted as brokers for.

I agree it’s a registry policy issue. I was only pointing out the strength of the XDI.org registry privacy infrastructure, knowing the amount of work that went into this specifically to avoid the issues with DNS Whois.

>> * Ease of use: a personal i-name is just a string prefixed by an = sign. It
>> works the same way everywhere in all contexts/protocols that accept XRIs.
>A domain name is just a string with some dots in it. It works everywhere 
>that domain names are accepted. A HTTP URL is just a string prefixed 
>with http:// and a domain name. It works everywhere that HTTP URLs are 

Perhaps my original point was unclear. All XRIs are abstract, i.e., they all resolve to XRDS documents in order to determine the concrete URIs (or other service endpoint metadata) for further interaction. So you always know exactly what you can expect from =drummond: an XRDS that tell you.

You don't know that from just looking at a URL because it can be both concrete (resolves directly to a Web resource) and abstract (resolves to an XRDS document for discovery of concrete service endpoints). Thus you can't tell from looking at http://some.example.com whether there is an associated XRDS or not.

Phone numbers and fax numbers have the same issue -- you can't tell from just looking at one which is which -- you have to call it to find out. By contrast, you *can* tell from an 800 number (or any 8xx number) that it's toll-free just by looking at it. URLs are in the first category and XRIs are in the second. I'm not saying that's important to everyone, but for some applications the ability to know whether an identifier is abstract or not without have to try to resolve it first is important. (I'll note the ongoing discussion right now over the same issue with using email addresses as OpenID URIs.)

>> * Internationalization: i-name syntax is fully internationalized (uses the
>> full Unicode character range) right from the start, without the need for
>> complicated punycode (http://en.wikipedia.org/wiki/Punycode).
>"Complicated" punicode is just another unicode encoding scheme, like 
>UTF-8. Just as with UTF-8, most developers don't need to care much about 
>it as the lower-layer libraries handle these implementation details.

Okay, I'll concede internationalization as a differentiator. But I would be dishonest if I didn't point out that some of the companies interested in XRI infrastructure are very happy that it's been designed for UCS from the ground up.

>Since you bring it up, could you explain to me how XRI handles the 
>problem of the human confusion between the two distinct identifiers 
>"=martin" and "=mаrtin"?

I'm suspecting that your point is that you used different UCS character sets in those two strings, so what appears identical in this text in fact two different UCS strings -- the homoglyph problem (http://en.wikipedia.org/wiki/Homoglyph). (Am I right?)

If so, see section 4.2.2 of the XDI.org Global Services Specifications at http://gss.xdi.org/moin.cgi/FrontPage?action=AttachFile&do=get&target=gss-v1.0.pdf. This explains the anti-phishing architecture built into the XDI.org global i-name registries (conceived of by Wil Tan, an internationalization expert at NeuStar, who can describe it in great detail). Once any i-name within the "tree" of i-names that canonicalize into the same visual homoglyph is registered, none of the others can be registered except by the same registrant. This same solution also works for cases where UCS characters are not homoglyphs but have the same meaning (such as in traditional and simplified Chinese).

>> * Clear differentiation of context: XRI i-name/i-numbers are not just for
>> people (=names/numbers); there are also namespaces for communities
>> (@names/numbers) and tags (+names/numbers). = for personal, @ for community,
>> and + for tags. This will become more important as you need/want to put your
>> identity into specific contexts, i.e., login to a website with your identity
>> as a member of a specific community instead of your own personal identity.
>And .com was originally for companies while .org was for organisations. 
>And people should be under .name. We all know how well that distinction 
>has worked out. Just what is stopping me registering a personal i-name 
>and using it for my business or community?

While you can do that if you want, in the registration agreement for a global personal i-name (=name) you agree not assert any trademark rights because it is for personal use (whereas the registration agreement for an @name permits you to assert trademark rights). And the +namespace (tags) has no associated trademark rights and the legal foundation has been laid to support that no one can assert them there.

(It's worth mentioning that as many lawyers worked on XDI.org registry infrastructure as technologists worked on XRI infrastructure. For many people that may be a huge turn-off, but the higher we move into the social layer of the net, the more I believe it becomes inevitable. Look at the impact Creative Commons has had, for example.)

>I already have URL-based OpenID identifiers in a number of "community" 
>namespaces, such as LiveJournal and MyOpenID. All that's missing is the 
>CanonicalID stuff to tie my identities together, but since Yadis and 
>thus OpenID use XRDS it's not difficult to imagine how to add that in by 
>simply adapting the XRI mechanism.

Agreed; see below.

>> * Smarter addressing: XRI i-name/i-number syntax was developed for more than
>> just digital identity. It is designed for next-generation messaging and data
>> sharing protocols that will let you do things like tag an address (the way
>> some email servers support tagging usernames in an email address). Examples:
>> 	=drummond+contact
>> 	=drummond+email
>> 	=drummond+openid
>> 	=drummond+openid+security
>> 	=drummond+openid+ui
>> 	@cordance+contact
>> 	@cordance+openid

It may be subtle, but in the example XRIs I gave, each of the subcomponents of the overall XRI is itself an XRI, which means that machines can parse them as easily as people. For example, a machine can know by defintion that @cordance is an identifier in a business context and +contact is a tag that it can look up in an tag dictionary (where it would find that, among other things, in the context of an XRDS document, "+contact" is a synonym for the service type identifier "xri://+i-service*(+contact)*($v*1.0)"). 

A machine would need natural language processing capabilities to understand that, in your URL examples, "mycompany.com" puts "martin." in a business context, and "/contact" means it points to some kind of resource that may be related to contacting the responsible authority.

This kind of capability may not seem that important now, but as semantic web applications appear, its importance will grow. For example, we are taking huge advantage of this unambigous machine interpretation of identifiers in the XDI data interchange protocol (also underway at OASIS).

>I think the main thing that XRI has going for it that can't be said of 
>DNS/HTTP URLs is the canonical, un-reassignable i-numbers. However, it's 
>not difficult to imagine a mapping of that onto the DNS where anyone can 
>— for little or no cost — get an address like 
>1000.a1c2.96d2.8c73.inum.arpa that is guaranteed to never be reassigned 
>and is delegated to me just as any normal DNS domain is delegated.

Agreed, at least on a technical level. But setting up the operational infrastructure for persistent identifiers -- that's interoperable across the net and maintained by the community for the community -- is a much bigger challenge. That's why fully half the work that's gone into XRI infrastructure has gone into XDI.org.

Again, I hope these points help. I'm not trying to sell anyone on XRI that wants to use URLs; I'm just trying to answer questions about the motivations for XRI.


More information about the general mailing list