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

Martin Atkins mart at degeneration.co.uk
Mon Feb 12 19:50:02 UTC 2007


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

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.

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

> * 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 
accepted.

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

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"?

> * 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?

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.

> * 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
> 

martin.name/contact
martin.name/email
martin.name/
martin.name/openid/security
martin.name/openid/ui
martin.mycompany.com/contact
martin.mycompany.com/openid


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.





More information about the general mailing list