The OpenID specification gives a lot of flexibility to an individual when it comes to choosing an identity for authentication. In OpenID protocol, your username is simply your URL and you, as the user, control who is looking at your information and how.
One can use a URL they control for OpenID authentication. Also, if I have a a blog, I can use the blog address as my OpenID authentication URL with the use of LINK and META tags. There is a very good HOWTO here.
But which URL ? I think a lot of people will be struggling with that, sooner or later.
- People’s blog addresses can change. Most particularly so if you are using a free blogging service. What’ the guarantee that in about a year, my blog address is still rajeev.name ? Then what happens to all of my accounts where I signed in as rajeev.name ?
- If one is using a third party, free openid URLs (myopenid.com, videntity.org etc), then even that can change. What happens to those accounts ?
- In all of the above cases, my authentication is tied to my URL server’s uptime ? Not sure if I like that.
- If I have an i-name, I can setup a URL forwarder to my actual OpenID URL. However, even i-names can be transferred just like domains — if you let an i-name expire, then the next guy who gets my i-name gets my accounts ?
We know that i-names are actually a user-friendly names to i-numbers. I-Numbers are supposed to be permanant where as i-names are not. So if I am rest assured that my i-number can NEVER be re-assigned to another person, then should I be using my i-number as my openid URL ?
You do not need to set up a forward to authenticate an i-name with OpenID (in fact that would be a bad way to do it). OpenID 2.0 natively supports XRI resolution. When you enter your i-name XRI resolution is performed to find the YADIS document (instead of de-referencing the OpenID URL), once the YADIS document is retrieved authentication proceeds the same for an i-name as it would for a URL(more or less).
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.
Hi Andy
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 ?
Hi 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?
=Andy
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
What I meant by SPOF is Single Point of Failure.
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