cachability of delegated identity URLs / Consumer-Server comms

[Paul Crowley]

Ken Horn wrote:
> If this is correct, I'm again uncomfortable with the server having to 
> create and store (in general) an association with the consumer (which it 
> has no reason to trust at this point) prior to being requested by an 
> authenticated (to the server) user.

Most servers, and certainly any server worried about DoS attacks, will 
not store anything when an association is established.

> If the flow above is correct, do we have a fallback if the secrets 
> change prior to expiry 

Secrets can never change, but they can be lost.  It would be useful to 
have a somewhat wider range of errors that the server can give the 
consumer during identification; that's something that's been flagged up 
but not discussed.

 > Again, the DSA flow was more robust I think in this regard.

The new protocol is more robust. The DSA secret keys were exactly as 
vulnerable to being lost as the secrets behind the HMAC secrets, but 
because they didn't expire there was no replacement path.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/