Consolidated Delegate Proposal

[Drummond Reed]

>> Drummond wrote:
>> Since the RP has to do discovery on the i-name, the RP already has the
>> i-number (CanonicalID). Further, as explained in previous threads, the
>> CanonicalID is the primary key the RP wants to store for the user,  
>> not the
>> i-name, because the i-number is forever while the i-name could change.
>>
>> The RP is also motivated to send the i-number to the IdP for the  
>> same reason
>> that the RP is motivated to send the delegate URL (if available): to
>> increase performance by saving the IdP from having to re-resolve  
>> the i-name
>> (in the XRI case) or original URL (in the URL case).
>
>Dick wrote:
>
>Won't the IdP will still have to resolve the i-name? The IdP can't  
>trust the RP, or know that the i-name and i-number are really linked  
>unless it checks itself.

There are no trust issues involved with the IdP using the identifiers sent
by the RP. The RP is "relying" on the IdP, not vice versa. If the RP sends
the wrong identifiers, it's fooling no one but itself. Thus the IdP has no
reason to re-resolve (and good performance reasons not to).

>> Lastly, in the case where the identifier-the-RP-stores and the
>> identifier-the-IdP-stores are different, if the RP has already  
>> discovered
>> the latter, then the RP can be stateless by sending both to the  
>> IdP, knowing
>> it will receive both back in the response.
>
>Then the RP is trusting the IdP will send back a correct mapping.

The is true no matter whether one or two or n identifiers are involved. In
other words, even if the RP only sent the IdP one identifier (as OpenID 1.x
does), if the IdP sends back the wrong identifier, the RP is screwed.

>This discussion has me wondering about XRI resolution though. Given  
>that multiple i-names can resolve to the same i-number, just as  
>multiple domain names can resolve to the same IP address, and that  
>the i-name is the identifier the user sees, it would seem tht the i- 
>name is what should be stored by the RP, otherwise there is no  
>difference between using any of the i-names that resolve to the same  
>i-number, or is that the idea?

That is the idea. Although it's tempting to think of multiple i-names
mapping to the same i-number as being just like multiple domain names
mapping down to the same IP address, in reality i-names and i-numbers are
peers, and the mapping is "sideways" from the reassignable i-name synonyms
to the persistent i-number synonym. So the real analogy would be multiple
"temporary" domain names mapping as CNAMEs to one "permanent" domain name,
and it's that "permanent" domain name (the i-number) that the RP wants to
store.

=Drummond