XRI canonical id question

[Drummond Reed]

>Johannes Ernst wrote:
>> Drummond:
>> 
>> The current auth draft says in section 11.4:
>>     If the Verified Identifier is an XRI, the discovered CanonicalID 
>> field from the XRD SHOULD be used as a key for local storage of 
>> information about the End User.
>> 
>> Is there ever a scenario where the identifier is disassociated from the 
>> CanonicalID? I was wondering whether there is a potential security hole?
>> 
>> [I simply don't know, so I'm asking you ;-) ]
>> 
>> 
>Martin Atkins wrote:
>
>I'm pretty sure that "i-numbers" are never re-assigned. That's a pretty 
>fundamental design principle for XRI, as I understand it.

Exactly. It's important to note that while XRI syntax and resolution enable
this on a technical level, it's still ultimately a policy that has to be
enforced at a registry level. This has always been true of URNs -- as the
IETF noted at the conclusion of its URN effort, persistence is an
operational characteristic of an identifier, not purely a technical
characteristic. (For more on persistent identifiers, I recommend
http://www.nla.gov.au/padi/topics/36.html). 

>RPs should ideally be displaying the entered i-name but using the 
>i-number as the primary key. Of course, this does have the possibility 
>that in future the display name may be wrong, but since the RP should be 
>storing both it will be able to detect during auth that the two have 
>become detached and create a new conceptual user, probably 
>disassociating the i-name from the old one in the process.

Right on the money. I would go further and recommend that an RP not even
store the i-name, just the i-number and a user's preferred display name.
That way the i-name becomes really just a convenient way for the user to
give the RP their i-number (CanonicalID).

>This does pose a problem to humans in that the RP will be displaying an 
>incorrect i-name until the new owner tries to authenticate with the same 
>RP, which may never happen.

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.

=Drummond