On 12-Oct-06, at 11:40 PM, Drummond Reed wrote:

>>> 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).

The IdP is issuing a signed assertion about these identifiers, I  
would assume the IdP to check the link between these identifiers.

What if a bad RP sends an auth request with a mismatched set and then  
re-posts the response to some other RP? I am sure someone will figure  
a way to exploit this.


specs mailing list

Reply via email to