Specifically, if I use my i-name as my central digital identity including authentication, via its OpenID service, then any disruptions in the XRI name resolution poses a big and personal problem.

The point is well taken that XRIs are modeled after DNS. Part of my concern is if a DNS service is down, then it is probably down for a whole bunch of people and it is not personal. The fact that I cannot login to my service websites cause the XRI server is down while others can is quite personal and hits home hard – thereby one asks a lot tougher questions and needs better assurances.

=rajeev

I do understand your explanation lot better.

You bring up OpenID 2.0 and the use of native XRI resolution.

a) Are the openid authenticators required to adopt OpenID 2.0 within a given time frame ?

b) Till a full transition to OpenID 2.0 is made, how do we know if a given website/authenticator is running OpenID 2.0 or 1.0 ?

For example, I picked this website from the opendirectory list. It asks for my openid URI, but does not tell me whether it is running 1.0 or 2.0..

Quite appreciative of your willingness to help and provide information!

=rajeev

a) XRI resolution is modeled very closely on DNS resolution. In fact the =, @ and ! root registries are run by NeuStar. They run the TLDs for .biz, .us, .cn and a bunch of others, they also do all of the North American phone number resolution, it’s says on their web site “We enable the routing of over 2 billion voice calls a day”. I’m sure that is somewhat marketing spin but it gives me reason to trust them. Beyond the root, just like DNS, XRI is designed to have a bunch of caching servers that serve up delegated registries and optimize the network.

b) Drummond and you are right… You CAN use forwarding from your i-name to your URL based openID and as Drummond says this would result in the URL being captured as the canonical id instead of your i-number…. What I said was… “You don’t NEED to” and “I think it’s a bad idea” I agree that you CAN do it that way. I tend to be less politic than Drummond and just because you CAN do something if I don’t think it’s a good pattern, I will say so. Now with all that said.. there is clearly one use case that is best satisfied with the forwarding approach; if you have already invested a lot in building the value of a url based openID but you want the convenience of an i-name; forwarding may be for you (but you loose trusted resolution and i-number canonicalization).

You said “who is addressing that SPOF issue with the URI itself ?”… I don’t understand :-( what is SPOF?

Good information – Thx for the note.

What I am unsure of are the following things:

a) If we rely on i-names as our universal identifiers and also for OpenID, then the i-name resolution becomes extremely critical. What reliability parameters can we expect out of xri resolution.

b) And then there is this posting by Drummond with regards to i-name resolutions being different if you are specifying the full XRI url or just the i-name.

All in all, if both iname and openid protocols are URI based — then who is addressing that SPOF issue with the URI itself ?

When you authenticate using your i-name what is persisted by the relying party is actually the i-number that the name resolves to. This gives 2 benefits:

1) If you have multiple i-names associated with the same i-number you can use any of them when you return to the relying party, you don’t have to remember ‘which i-name I used here last time’.

2) If you stop using an i-name and start using another one, assuming you put that new one on the same i-number, your experience at your service providers will be one of seamless continuation of service while the person who buys your ‘old’ i-name will instantly be recognized as a different person.

Hope this helps :-)

You can always contact me at =andy if you want to chat more.