The CanonicalID Approach

[Martin Atkins]

Josh Hoyt wrote:
> On 6/9/07, Martin Atkins <mart at degeneration.co.uk> wrote:
>> I'm assuming that the RP authenticates
>> http://inconvenient.example.com/0000001, not
>> http://impersonation.example.com/mart. Just as with delegation, if I can
>> successfully authenticate as the persistent identifier and the
>> non-persistent identifier points at the persistent one, we can assume
>> that http://impersonation.example.com/mart is "me" as well.
> 
> If you agree that:
> 
> 1. In order to "authenticate as the persistent identifier," discovery
> must be done on the persistent identifier
> 
> 2. In order to determine that "the non-persistent identifier points at
> the persistent one," discovery must be done on the non-persistent
> identifier.
> 

Right you are. The detail I was missing was that if, as in delegation, 
the non-persistent identifier is trusted to nominate a server endpoint 
for authentication, it becomes possible to lie about the server endpoint 
and claim any identifier.

But can we guarantee that it is always exactly two discovery steps? If 
my CanonicalID points at an identifier which itself also has a 
CanonocalID, do we follow it recursively?

I can't really think of any security flaws as a result of only following 
one level of CanonicalID, but it may be counter-intuitive for implementors.