diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index 48a77907..0b1982e9 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/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 diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 69339568..198af1b2 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/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