Consolidated Delegate Proposal
Marius Scurtescu
marius at sxip.com
Fri Oct 13 22:01:54 UTC 2006
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
More information about the specs
mailing list