Association Handles and Service URIs

Kevin Turner kevin at janrain.com
Fri Aug 25 17:52:47 UTC 2006


On Thu, 2006-08-24 at 17:49 -0700, Marius Scurtescu wrote:

> The only party interested in verifying the assertion is the RP. Why  
> would the RP send something else than its real URI? It cannot steal  
> associations made with other RPs since a new one will be generated.

Then, at the very least, I could DoS communications between a relying
party and an IdP by repeatedly asking that IdP for new associations with
that RP's address, thus expiring any association that RP was actually
using.

> > The RP needs that handle to distinguish between other associations
> > issued by that IdP, as associations may expire or be otherwise
> > invalidated.
> 
> True, but only one active association exists at any give time for  
> each IdP. Is there a need to track expired or invalid associations?

You're right, there is typically only one active association.  I suppose
there is a borderline case where the RP sends a request with one
association handle, but in the time between when you make the request
and get a response, a new association has been established...  but since
new associations are typically only established when the old one becomes
invalid, it's questionable if you should accept the response in that
case anyway.


> > The RP also needs that handle because that's the only way it can  
> > talk to
> > the IdP about which handle to use.  (because, as discussed above, the
> > IdP cannot look up a handle from a return_to or trust root.)
> 
> As far as I can tell the IdP could use the return_to or the trust root.

I think it is useful to know whether the IdP and the RP have the same
idea of the "current" association.  If you do not issue new handles to
new associations, but always use the RP's address instead, when a
signature doesn't check out you can't tell if it's because you're using
the wrong association, or if it's because the message was corrupted.
That seems like a worthwhile distinction to be able to make.




More information about the yadis mailing list