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.

Marius

_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to