Be more precise on OpenID4VP nonce entropy

[paulbastian]

OpenID4VP currently states for nonce:

nonce:
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, store it with its current session, and pass it in the nonce Authorization Request Parameter to the Wallet. See Section 14.1 for details. Values MUST only contain ASCII URL safe characters (uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde).

which is not very strong language and especially missing specific minimum requirements, e.g. the best practice of 128bits.

In contrast, OpenID4VP currently states for state:

ensure that the value is a cryptographically strong pseudo-random number with at least 128 bits of entropy,

So I propose to add similar language for nonce:

The Verifier MUST create a fresh and unpredictable nonce using a secure cryptographically random number generator of at least 128bits of entropy for every Authorization Request, store it with its current session, and pass it in the nonce Authorization Request Parameter to the Wallet.

[jogu]

Discussed on today's WG call:

Can't really enforce this. Some large scale verifiers HMAC signed JWTs instead.

Is it worth providing non-normative guidance on implementing that correctly / what the trade off is?
We need to at least make sure such an implementation is compliant.

[paulbastian]

Some large scale verifiers HMAC signed JWTs instead

What does that mean and how do they enforce replay protection if it does not include sufficient entropy?