The HTTP Signatures 1.0 spec should probably explain exactly how to implement nonces for implementers that would like a fully vetted solution that protects against replay. This would be useful for implementers implementing HTTP signatures in a clear channel environment.
Another consideration for nonces is the probability that multiple clients may share the same public key. In this instance, due to clock skew issues, it is possible that some clients may accidentally trigger replay protection by sending a date in the past. The balance that this spec attempts to achieve is a simple per-client, time-based counter. Thus, the nonce would need to include something like a UUID-based client identifier, plus an incredibly accurate UTC datetime-based nonce as described in RFC 3339 [RFC3339]. For example: "598ef3e8-98b0-435d-8ca3-fecefdd87568 2013-
05-04 20:00:35.808785840+00:00"
The HTTP Signatures 1.0 spec should probably explain exactly how to implement nonces for implementers that would like a fully vetted solution that protects against replay. This would be useful for implementers implementing HTTP signatures in a clear channel environment.
Another consideration for nonces is the probability that multiple clients may share the same public key. In this instance, due to clock skew issues, it is possible that some clients may accidentally trigger replay protection by sending a date in the past. The balance that this spec attempts to achieve is a simple per-client, time-based counter. Thus, the nonce would need to include something like a UUID-based client identifier, plus an incredibly accurate UTC datetime-based nonce as described in RFC 3339 [RFC3339]. For example: "598ef3e8-98b0-435d-8ca3-fecefdd87568 2013- 05-04 20:00:35.808785840+00:00"