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 firstname.lastname@example.org http://openid.net/mailman/listinfo/specs