cachability of delegated identity URLs / Consumer-Server comms

[Ken Horn]

Paul Crowley wrote:

> 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.
>
OK, maybe I'm misreading the protocol / spec. Was the flow I mentioned 
correct? My gut feel is to only accept requests from consumers that 
already know something I've given to a user. Maybe I'm just insecure 
though... (or should that be paranoid.. :)

>> 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.
>
Why can't they change? It's maybe terminology but losing a secret, is 
one route of change. Another might be to force re-association. Can't a 
server choose to change it's secrets / keys etc whenever it chooses?

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

Isn't re-request the replacement path? On the DSA flow (dare I call it 
version 1? :), every time I started my process it used fresh keys -- 
worked fine.