Clarify nonce entropy requirements (#722)

* Clarify nonce entropy requirements

* Apply suggestion from @paulbastian

* Apply suggestion from @paulbastian

* Apply suggestion from @brentzundel

Co-authored-by: Brent Zundel <brent.zundel@gmail.com>

---------

Co-authored-by: Brent Zundel <brent.zundel@gmail.com>

Author: paulbastian

1.0/openid-4-verifiable-presentations-1_0.md

@@ -358,7 +358,7 @@ This specification defines the following new request parameters:
 The following additional considerations are given for pre-existing Authorization Request parameters:
 
 `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 (#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).
 
 `scope`:
 : OPTIONAL. Defined in [@!RFC6749]. The Wallet MAY allow Verifiers to request Presentations by utilizing a pre-defined scope value. See (#request_scope) for more details.
@@ -3590,6 +3590,7 @@ The technology described in this specification was made available from contribut
 
 -31
 
+   * Clarify nonce entropy requirements
    * Clarify that state is recommended to match text from Section 14.3.2. Protection of the Response URI
    * Clarify that `encrypted_response_enc_values_supported` applies only if JWE content encryption algorithm is used
    * Removed invalid_scope error guidance as duplicate of RFC6749

1.1/openid-4-verifiable-presentations-1_1.md

@@ -354,7 +354,7 @@ This specification defines the following new request parameters:
 The following additional considerations are given for pre-existing Authorization Request parameters:
 
 `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 (#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).
 
 `scope`:
 : OPTIONAL. Defined in [@!RFC6749]. The Wallet MAY allow Verifiers to request Presentations by utilizing a pre-defined scope value. See (#request_scope) for more details.
@@ -3655,6 +3655,7 @@ The technology described in this specification was made available from contribut
 
    -01
 
+   * Clarify nonce entropy requirements
    * Add usage of HPKE for the `info` parameter. 
    * Add security consideration not to use VP Token as Access Token
    * Clarify that state is recommended to match text from Section 14.3.2. Protection of the Response URI