From 9873fe5b2f939abc762cf3ef20e8a9a7f6eba59d Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Mon, 13 Jul 2026 21:56:55 +0200 Subject: [PATCH 1/3] add text on untrusted input to 1.0 --- 1.0/openid-4-verifiable-presentations-1_0.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index ed91213f..085bf2b5 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -1919,6 +1919,15 @@ these constraints. The Wallet is not controlled by the Verifier and the Verifier MUST perform its own security checks on the returned Credentials and Presentations. +## Parsing of untrusted inputs + +Wallets MUST treat all incoming requests as untrusted input. To mitigate injection and resource exhaustion attacks, Wallets MUST implement input validation on the Authorization Request and its enclosed DCQL query. + +Wallets SHOULD implement the following steps: + +* Enforce input validation: Verify that the Authorization Request and DCQL query contain no malformed properties. Unknown parameters MUST be ignored. +* Apply resource limits: Enforce maximum length restrictions on strings, maximum depths for nested objects, and maximum item counts for arrays within the query. + # Privacy Considerations {#privacy-considerations} Many privacy considerations are specific to the Credential format and associated proof type used in a particular Presentation. @@ -3601,6 +3610,7 @@ The technology described in this specification was made available from contribut -31 + * add security considerations on untrusted input * 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 From 99366a0ac18c82cada541271688a68d54b63f826 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 30 Jul 2026 17:34:42 +0200 Subject: [PATCH 2/3] Clarify input validation requirements for wallets --- 1.1/openid-4-verifiable-presentations-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index df34af9b..c9c98554 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -2001,7 +2001,7 @@ Presentations. Wallets MUST treat all incoming requests as untrusted input. To mitigate injection and resource exhaustion attacks, Wallets MUST implement input validation on the Authorization Request and its enclosed DCQL query. -Wallets SHOULD implement the following steps: +Wallets SHOULD at least implement the following steps: * Enforce input validation: Verify that the Authorization Request and DCQL query contain no malformed properties. Unknown parameters MUST be ignored. * Apply resource limits: Enforce maximum length restrictions on strings, maximum depths for nested objects, and maximum item counts for arrays within the query. From 10c4c0aad6e67f76b2fc5c45104a94e9b730361e Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Thu, 30 Jul 2026 17:36:02 +0200 Subject: [PATCH 3/3] Apply suggestion from @lj-raidiam Co-authored-by: Lukasz Jaromin --- 1.0/openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index 8217eec1..bf6358a0 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -1938,7 +1938,7 @@ Presentations. Wallets MUST treat all incoming requests as untrusted input. To mitigate injection and resource exhaustion attacks, Wallets MUST implement input validation on the Authorization Request and its enclosed DCQL query. -Wallets SHOULD implement the following steps: +Wallets SHOULD implement at least the following steps: * Enforce input validation: Verify that the Authorization Request and DCQL query contain no malformed properties. Unknown parameters MUST be ignored. * Apply resource limits: Enforce maximum length restrictions on strings, maximum depths for nested objects, and maximum item counts for arrays within the query.