To me it seems reasonable that a client may send multiple signed messages
in one second.
So I´m +1 for a nonce. A more fine grained timestamp is nice but I think we
might end upp at the same place, someone saying that they think it is
reasonable to send multiple signed messages the same millisecon
I understand how they work, I’ve built exactly that cache before. But I
askWouldn’t a unique timestamp have the same effect? Currently it’s integer
seconds but slicing that down further (floating point seconds?) if people
desired would allow for multiple signed messages in the same second from t
The nonce would allow to build a replay cache, the timestamp to trim that cache
and reject messages that are too old.
Similar protocols have a nonce for the above reasons (ws-sec msg security,
hawk)...
—
cheers
Dominick Baier
On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu) wr
I’d be glad to add in a nonce if there’s a compelling reason for it, such as
closing a security attack vector.
What’s the proposed purpose of the nonce? Is it just to add randomness to the
signing base? Or is it to prevent replay at the RS? If the former, the
timestamp should add enough of that
Question about the HTTP signing spec - why is there no nonce (and just a
timestamp)?
TIA
-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
