I think a client should definitely and in every case reject a response with a mismatching nonce. This is covered in RfC2560 in its current form: mismatching nonce => reject.
So allow me to rephrase again based on your proposal:
A) always includes a nonce into his request; B) checks the nonce in the response:
- if it matches with the nonce from the request, then accept the response (pending other checks),
- if it does not match with the nonce from the request, then reject the response
- if nonce is not present, then are a local trusted time available and a policy for cache responses both available ?
- if both a local trusted time is available and there exists
a policy for cache responses, then compare the time
difference between that local trusted clock and the
producedAt field from ResponseData. If that time difference
is below the limit stated by that policy, then accept the
response (pending other checks).
- if not, then reject the response.
[Additionally we add some checks:
i) if nextUpdate is present and is lower than the current date from our trusted clock before sending the request, we detected a clock problem in our "trusted" clocks.
ii) if thisUpdate is too old for our limit stated in the policy we reject the answer, too.
iii) additionally some sanity checks: thisUpdate<=producedAt<=nextUpdate
I have to double check, but I think thats all we do.]