cachability of delegated identity URLs / Consumer-Server comms

[Paul Crowley]

Ken Horn wrote:
> 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.. :)

The flow is correct.  We use cryptographic cleverness at the server end 
to obviate the need for the server to store anything.  The protocol 
doesn't detail this cleverness because it doesn't need to, but basically 
the server will use a cryptographic transformation to map from the 
handle to the secret, so it doesn't have to store each entry in the 
handle -> secret map.

> Why can't they change? It's maybe terminology but losing a secret, is 
> one route of change.

If handle A maps to B, it will never map to C.  However, what A maps to 
can be lost.

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

Best to call it version 0, I suspect.  That version makes it explicit 
that the DSA keys can be cached, and it doesn't say for how long.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/