Association Handles and Service URIs

[Marius Scurtescu]

On 24-Aug-06, at 5:17 PM, Kevin Turner wrote:

> On Thu, 2006-08-24 at 15:24 -0700, Marius Scurtescu wrote:
>> The RP URI (or the Trust Root) could be sent by the RP with the
>> "associate" request.
>
> It could, but if there's no way of validating that information, it  
> isn't
> reliable, and is then misleading at best.  The RP can pass its URI in
> checkid requests because we know that if *that* URI is invalid, the RP
> will not receive the redirect response.  The same is not true in
> associate requests, as the answer just goes back through the tcp
> connection, not tied to any URI.

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.

>
>
>>> In contrast, an RP will be aware of which IdP it requested an
>>> association from.
>>
>> So the RP does not really need this handle then, right?
>
> 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?

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

>
>
>> Yes, but 'now' is relative. Between the time an association is
>> created by the IdP (IdP's now) and the time it is sent back and
>> parsed by the RP (RP's now) there is a gap. In most cases this gap is
>> negligible, but it can create borderline issues.
>
> one might argue that the gap created by transmitting and processing a
> TCP packet is in fact more negligible than the clock skew between any
> given couple of servers on the network.

The gap could be bigger than the packet transmission and processing.  
Since the 'now' moment is not define it is up to the IdP to mark it.  
The IdP could mark now right at the beginning of the request, in  
which case the gap will include the time needed to generate the  
response.

My main point is than an absolute expiry time is less ambiguous and I  
cannot see what is the advantage of a relative expiry time. Both the  
IdP and the RP ultimately will track and absolute time, why convert  
back and forth to a relative time?


>
> (Yes, I know we have the infrastructure available to synchronize all
> computers on the Internet to within an imperceptible differences from
> meticulously maintained atomic clocks.  I also know that not everyone
> takes advantage of that, and even on systems that do, it can fail and
> nobody notices for weeks.)
>
> There are fall-back cases in the protocol that take care of any
> borderline issues that may arise from this particular problem.  An
> especially apprehensive RP may also shave a bit off the association
> lifetime to avoid playing things too close to the line, with no ill
> effects.

Yes, shaving of a bit of the association lifetime is a good idea in  
both cases.