>> On 10-Oct-06, at 11:00 AM, Drummond Reed wrote: >> >> Again, this is why I recommend RPs don't even store the i-name, but >> instead >> store their own display name for the user. The display name and the >> i-number >> (CanonicalID) never need to change, whereas an i-name may be >> reassigned. > >Dick wrote: > >why would an i-name be reassigned?
Just like a domain name, an i-name registration can lapse and be returned back into the name pool, where it can be registered by a different registrant. >why would an i-number not be reassigned? I-numbers are functionally URNs. They are assigned once by a registry (globally or at any level of delegation) and never reassigned. Even if the registration lapses, it can only be renewed by the original registrant (or their trustee). I-numbers are one of the most unique features of XRI registries. See the XDI.org Global Services Specifications at http://gss.xdi.org for much more than you ever wanted to know about the policies around persistent identifier management. Good lawyers took as many years as the technologists to come up with this stuff ;-) >who owns the i-number? The original registrant - forever. Even if they die, they can appoint one or more trustees to continue to own/manage the registration. >I thought that who is authorative for an i-name was managed by a >registry that was separate from the i-broker, and that mechanism >provided the separation of identifier management from IdP. It does. The same way domain name registrations are portable from one DNS registrar to another, global i-name and i-number registration are portable across IdPs (in XDI.org XRI infrastructure they are called i-brokers). The role of the IdP/i-broker, like the role of a DNS registrar, is to perform transactions with the registry on the registrant's behalf, i.e., register, update, delete, and transfer registrations. =Drummond _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs