[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