cachability of delegated identity URLs / Consumer-Server comms
ken.horn at clara.co.uk
Thu Jun 9 04:06:18 PDT 2005
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 --
More information about the yadis