XRI canonical id question

Drummond Reed drummond.reed at cordance.net
Tue Oct 10 17:35:38 UTC 2006


>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 ;-) ]

Ironic, Johannes, but CanonicalIDs actually *plug* a potential security
hole. Here's what I mean:

In XDI.org XRI infrastructure, every i-name is associated with an i-number
"synonym", i.e., they are equivalent identifiers for the same resource (and
resolving them will get you the same XRD). 

It's a many-to-one relationship, i.e., you can have as many i-names as you
want as synonyms for the same i-number. (At a pure technical level, it's
actually a many-to-many relationship, i.e., you can have as many i-names and
i-numbers all acting as synonymous identifiers for the same resource, but
practically speaking, you only need one i-number to persistently identify
the resource, while you may need zero-to-n i-names as semantic identifiers
for the resource).

The key property of i-numbers is that unlike i-names, or domain names, they
are persistent, i.e., never reassigned (functionally this makes them URNs,
http://en.wikipedia.org/wiki/Uniform_Resource_Name). 

So if I understand your question correctly, you are asking, "Is there ever a
scenario where the i-name is disassociated from the CanonicalID (i-number),
and is this a potential security hole?"

The answer is, "Yes, it's fully expected that an i-name may be reassigned to
another resource and thus be disassociated from a CanonicalID i-number." The
"security hole", then, is not whether the RP stores the CanonicalID
i-number, but if the Relying Party DOESN'T.

In others words, if an RP stores the i-name as the identifier -- or a domain
name as an identifier -- that identity can be "taken over" if that i-name or
domain name is ever reassigned. That's the "security hole" inherent in using
any form of reassignable identifier in a digital identity infrastructure.

That's why I've been such a stickler about making sure that OpenID
Authentication 2.0 enables consistent, proper handling of identifier
synonyms. With URLs, separation of an RP-facing-identifier from an
IdP-facing-identifier synonyms enforces identifier portability across IdPs
(that was Brad's original inspiration for the openid:delegate feature). With
XRIs, separation of reassignable-i-name and persistent i-number synonyms not
just enforces identifier portability, but also protects users from ever
having their digital identity be taken over by someone else because their
i-name or domain name was reassigned.

Does that answer your question?

=Drummond 




More information about the specs mailing list