cachability of delegated identity URLs / Consumer-Server comms
paul at ciphergoth.org
Thu Jun 9 04:11:21 PDT 2005
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
More information about the yadis