Clarify nonce entropy requirements

[paulbastian]

Closes #707

[fkj]

I don't have a strong opinion on the actual entropy required, but I think this looks fine if nobody objects to 128 bits.

[c2bo]

I believe we should add a note here explaining that a self-contained nonce (e.g., HMACed) is fine as well provided the underlying algorithm (e.g., HMAC) provides enough entropy. I believe that is also roughly what was discussed 1-2 weeks ago when this was discussed in the WG?

[paulbastian]

there is nothing that prevents you from putting a 128 bit random value into the self-contained nonce?

[c2bo]

Yes, we should just make that explicit/explain that

[paulbastian]

Should we add this to 14.1. Preventing Replay of Verifiable Presentations rather than in this chapter?

[fkj]

I think the consensus was that it would be great to add a description of how to do the HMAC approach correctly, but it could be moved into a separate issue/PR.

[jogu]

This might cause some verifiers that are compliant with the current spec to become out of compliance I think, i.e. it's a breaking change.

I'm not sure how we address that. But it is a potential issue given 1.0 is intended to be named in EU law. One possibility is to make it a 'SHOULD' instead, perhaps with a note that it would have been made mandatory if not for backwards compliance.

[paulbastian]

I suggest this to be a MUST, as this is just making "sufficient" more precise to current best practices

[Sakurann]

if this breaks existing implementations, we can't make it a must. and need to find an alternative way

[paulbastian]

I believe this is what errata is made for

[fkj]

I agree that it's probably best to make it a RECOMMENDED 128 bits and keep the normative language the same.

[jogu]

The use of 'at least' means we're not specifying an upper bound. The length of nonces that are supported has been an ongoing issue outside of the VP world - sometimes people want to use self contained JWTs as nonces/state, sometimes authorization servers limit the lengths they support. For interoperability we'd need to say something about an upper bound on the length.

[paulbastian]

Don't confuse length and entropy. Also the upper limit for length may be a breaking change.

[jogu]

Indeed, it could be a breaking change, but in practice the certification suites have to take a position. Which is currently ~23 characters, and the suite also tries a 43 character nonce I believe and requires that to work.

There generally is a link between entropy and length at least for the lower bound - 128bit means there's a minimum length.

[brentzundel]

During WG meeting today, the group preferred changing the 128-bit length to recommended in order to limit breaking changes.

[brentzundel]

Suggested change

: REQUIRED. A case-sensitive String representing a value to securely bind Verifiable Presentation(s) provided by the Wallet to the particular transaction. The Verifier MUST create a fresh and unpredictable nonce using a secure cryptographically random number generator of at least 128 bits of entropy for every Authorization Request and store it with its current session. See (#preventing-replay) for details. Values MUST only contain ASCII URL safe characters (uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde).

: REQUIRED. A case-sensitive String representing a value to securely bind Verifiable Presentation(s) provided by the Wallet to the particular transaction. The Verifier MUST create a fresh, cryptographically random number with sufficient entropy for every Authorization Request and store it with its current session. The nonce SHOULD contain at least 128 bits of entropy. See (#preventing-replay) for details. Values MUST only contain ASCII URL safe characters (uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde).