From 2914b004245ce41e4e9b4a19ea7e734567351d1c Mon Sep 17 00:00:00 2001 From: Valentine Mazurov Date: Wed, 25 Feb 2026 13:32:09 +0400 Subject: [PATCH 1/4] Add a security consideration not to use VP Token as Access Token. --- 1.1/openid-4-verifiable-presentations-1_1.md | 4 +++- 1 file changed, 3 insertions(+), 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 353c42f3..cf120d3d 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1882,6 +1882,8 @@ Implementations of this specification MUST have security mechanisms in place to Clients intending to authenticate the End-User utilizing a claim in a Credential MUST ensure this claim is stable for the End-User as well as locally unique and never reassigned within the Credential Issuer to another End-User. Such a claim MUST also only be used in combination with the Credential Issuer identifier to ensure global uniqueness and to prevent attacks where an attacker obtains the same claim from a different Credential Issuer and tries to impersonate the legitimate End-User. +Clients intending to access a Resource Server on-behalf of the End-User authenticated via Credential presentation, SHOULD NOT use VP Token as an Access Token. The way to produce Access Token based on Credential presentation is out of scope of this specification. + ## Encrypting an Unsigned Response {#encrypting_unsigned_response} Because an encrypted Authorization Response has no additional integrity protection, an attacker might be able to alter Authorization Response parameters and generate a new encrypted Authorization Response for the Verifier, as encryption is performed using the public key of the Verifier (which is likely to be widely known when not ephemeral to the request/response). Note this includes injecting a new VP Token. Since the contents of the VP Token are integrity protected, tampering with the VP Token is detectable by the Verifier. For details, see (#preventing-replay). @@ -3562,4 +3564,4 @@ The technology described in this specification was made available from contribut -01 - * TBD \ No newline at end of file + * Add security consideration not to use VP Token as Access Token From 458dcac63006e9037edb3932e7a7c7b5d5ce3a8f Mon Sep 17 00:00:00 2001 From: Valentine Mazurov Date: Thu, 26 Feb 2026 18:48:12 +0400 Subject: [PATCH 2/4] Add RFC6749 Resource Server term reference --- 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 cf120d3d..c9d37fc0 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -79,7 +79,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S # Terminology -This specification uses the terms "Access Token", "Authorization Request", "Authorization Response", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Response Type", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User" and "Entity" as defined by OpenID Connect Core [@!OpenID.Core], the terms "Request Object" and "Request URI" as defined by [@!RFC9101], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" defined by JSON Web Signature (JWS) [@!RFC7515], the term "JSON Web Encryption (JWE)" defined by [@!RFC7516], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [@!OAuth.Responses]. +This specification uses the terms "Access Token", "Authorization Request", "Authorization Response", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Resource Server", "Response Type", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User" and "Entity" as defined by OpenID Connect Core [@!OpenID.Core], the terms "Request Object" and "Request URI" as defined by [@!RFC9101], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" defined by JSON Web Signature (JWS) [@!RFC7515], the term "JSON Web Encryption (JWE)" defined by [@!RFC7516], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [@!OAuth.Responses]. Base64url-encoded denotes the URL-safe base64 encoding without padding defined in Section 2 of [@!RFC7515]. From 22f430ba5d0b573389f4cdae966d9ef768920c30 Mon Sep 17 00:00:00 2001 From: Valentine Mazurov Date: Mon, 9 Mar 2026 11:09:09 +0300 Subject: [PATCH 3/4] Update 1.1/openid-4-verifiable-presentations-1_1.md Co-authored-by: Christian Bormann --- 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 07287c72..c66608b7 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1882,7 +1882,7 @@ Implementations of this specification MUST have security mechanisms in place to Clients intending to authenticate the End-User utilizing a claim in a Credential MUST ensure this claim is stable for the End-User as well as locally unique and never reassigned within the Credential Issuer to another End-User. Such a claim MUST also only be used in combination with the Credential Issuer identifier to ensure global uniqueness and to prevent attacks where an attacker obtains the same claim from a different Credential Issuer and tries to impersonate the legitimate End-User. -Clients intending to access a Resource Server on-behalf of the End-User authenticated via Credential presentation, SHOULD NOT use VP Token as an Access Token. The way to produce Access Token based on Credential presentation is out of scope of this specification. +Clients intending to access a Resource Server on-behalf of the End-User authenticated via Credential presentation, MUST NOT use the VP Token as an Access Token. The way to produce Access Tokens based on Credential presentations is out of scope of this specification. ## Encrypting an Unsigned Response {#encrypting_unsigned_response} From a6970cb68ffd50170f5c067d115c5b55c75465e2 Mon Sep 17 00:00:00 2001 From: Valentine Mazurov Date: Mon, 9 Mar 2026 11:50:52 +0300 Subject: [PATCH 4/4] * Remove Resource Server reference; * extract VP Token != Access Token into a separate security consideration. --- 1.1/openid-4-verifiable-presentations-1_1.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index c66608b7..e234e782 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -79,7 +79,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S # Terminology -This specification uses the terms "Access Token", "Authorization Request", "Authorization Response", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Resource Server", "Response Type", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User" and "Entity" as defined by OpenID Connect Core [@!OpenID.Core], the terms "Request Object" and "Request URI" as defined by [@!RFC9101], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" defined by JSON Web Signature (JWS) [@!RFC7515], the term "JSON Web Encryption (JWE)" defined by [@!RFC7516], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [@!OAuth.Responses]. +This specification uses the terms "Access Token", "Authorization Request", "Authorization Response", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Response Type", "Token Request" and "Token Response" defined by OAuth 2.0 [@!RFC6749], the terms "End-User" and "Entity" as defined by OpenID Connect Core [@!OpenID.Core], the terms "Request Object" and "Request URI" as defined by [@!RFC9101], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [@!RFC7519], the term "JOSE Header" defined by JSON Web Signature (JWS) [@!RFC7515], the term "JSON Web Encryption (JWE)" defined by [@!RFC7516], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [@!OAuth.Responses]. Base64url-encoded denotes the URL-safe base64 encoding without padding defined in Section 2 of [@!RFC7515]. @@ -1882,7 +1882,9 @@ Implementations of this specification MUST have security mechanisms in place to Clients intending to authenticate the End-User utilizing a claim in a Credential MUST ensure this claim is stable for the End-User as well as locally unique and never reassigned within the Credential Issuer to another End-User. Such a claim MUST also only be used in combination with the Credential Issuer identifier to ensure global uniqueness and to prevent attacks where an attacker obtains the same claim from a different Credential Issuer and tries to impersonate the legitimate End-User. -Clients intending to access a Resource Server on-behalf of the End-User authenticated via Credential presentation, MUST NOT use the VP Token as an Access Token. The way to produce Access Tokens based on Credential presentations is out of scope of this specification. +## VP Token abuse {#vp-token-abuse} + +Ecosystems MUST NOT use the VP Token as an Access Token. The way to produce Access Tokens based on Credential presentations is out of scope of this specification. ## Encrypting an Unsigned Response {#encrypting_unsigned_response} @@ -2546,6 +2548,7 @@ The following security considerations from OpenID4VP apply: * Preventing Replay of Verifiable Presentations as described in (#preventing-replay), with the difference that the origin is used instead of the Client Identifier to bind the response to the Client. * End-User Authentication using Credentials as described in (#end-user-authentication-using-credentials). +* VP Token abuse (#vp-token-abuse). * Encrypting an Unsigned Response as described in (#encrypting_unsigned_response). * TLS Requirements as described in (#tls-requirements). * Always Use the Full Client Identifier as described in (#full-client-identifier) for signed requests.