From d01ee02ac541c89196c4eafc6f8a5530663aa871 Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Tue, 12 Nov 2024 15:04:53 +0100 Subject: [PATCH 1/5] add wallet attestation as new request/response parameters --- openid-4-verifiable-presentations-1_0.md | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 75f3f90b..949478a5 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -118,6 +118,9 @@ VP Token: Wallet: : An entity used by the Holder to receive, store, present, and manage Verifiable Credentials and key material. There is no single deployment model of a Wallet: Verifiable Credentials and keys can both be stored/managed locally, or by using a remote self-hosted service, or a remote third-party service. In the context of this specification, the Wallet acts as an OAuth 2.0 Authorization Server (see [@!RFC6749]) towards the Credential Verifier which acts as the OAuth 2.0 Client. +Wallet Attestation: +: An attestation designed to prove authenticity of the wallet towards parties it is interacting with, in the context of this specification, the Verifier. The overall concept, format and data structure of a Wallet Attestation is defined in [@!OpenID.VCI]. + # Overview This specification defines a mechanism on top of OAuth 2.0 to request and present Verifiable Credentials as Verifiable Presentations. @@ -310,6 +313,9 @@ The following is a non-normative example of a transaction data content, after ba } ``` +`wallet_attestation`: +: OPTIONAL. A boolean value that indicates whether or not a wallet attestation is requested by the Verifier. If the parameter is not present, the default value is `false`. If the value is `true`, a wallet attestation is expected to be part of the response (see `wallet_attestation` in (#response-parameters)). + ## Existing Parameters The following additional considerations are given for pre-existing Authorization Request parameters: @@ -610,6 +616,7 @@ The following is a non-normative example of a request object: "presentation_definition": {...}, "nonce": "n-0S6_WzA2Mj", "wallet_nonce": "qPmxiNFCR3QTm19POc8u", + "wallet_attestation": true, "state" : "eyJhb...6-sVA" } ``` @@ -978,6 +985,9 @@ If Presentation Exchange was used for the request, the `presentation_submission` Including the `presentation_submission` parameter as a separate response parameter allows the Wallet to provide the Verifier with additional information about the format and structure in advance of the processing of the VP Token, and can be used even with the Credential formats that do not allow for the direct inclusion of `presentation_submission` parameters inside a Credential itself. +`wallet_attestation`: +: REQUIRED if the `wallet_attestation` parameter was present and its value `true` in the Authorization Request (see (#vp_token_request) for more details). The Wallet Attestation presentation MUST be bound to the nonce that was provided in the Authorization Request. The expected format of a Wallet Attestation and validation rules are defined in section TODO of [@!OpenID.VCI]. If the validation of the Wallet Attestation fails, the response is rejected. Additional claims for individual implementations and ecosystems can be added to a Wallet Attestation. + Additional response parameters MAY be defined and used, as described in [@!RFC6749]. The Client MUST ignore any unrecognized parameters. @@ -989,6 +999,7 @@ HTTP/1.1 302 Found Location: https://client.example.org/cb# presentation_submission=... &vp_token=... + &wallet_attestation=... ``` ### Examples (DCQL) {#response_dcql_query} @@ -1495,7 +1506,7 @@ Note: If the Verifier's Response URI did not return a `redirect_uri` in step (6) ## Preventing Replay of the VP Token {#preventing-replay} -An attacker could try to inject a VP Token (or an individual Verifiable Presentation), that was obtained from a previous Authorization Response, into another Authorization Response thus impersonating the End-User that originally presented that VP Token or the respective Verifiable Presentation. +An attacker could try to inject a VP Token (or an individual Verifiable Presentation, or Wallet Attestation), that was obtained from a previous Authorization Response, into another Authorization Response thus impersonating the End-User that originally presented that VP Token or the respective Verifiable Presentation. Implementers of this specification MUST implement the controls as defined in this section to detect such an attack. @@ -1631,12 +1642,16 @@ If no End-User interaction is required before sending the request, it is easy to Mandatory End-User interaction before sending the request, like clicking a button, unlocking the wallet or even just showing a screen of the app, can make this less attractive/likely to being exploited. -Requests from the Wallet to the Verifier SHOULD be sent with the minimal amount of information possible, and in particular, without any HTTP headers identifying the software used for the request (e.g., HTTP libraries or their versions). The Wallet MUST NOT send PII or any other data that could be used for fingerprinting to the Request URI in order to prevent End-User tracking. +Requests from the Wallet to the Verifier SHOULD be sent with the minimal amount of information possible, and in particular, without any HTTP headers identifying the software used for the request (e.g., HTTP libraries or their versions). The Wallet MUST NOT send PII or any other data that could be used for fingerprinting to the Request URI in order to prevent End-User tracking. ## Authorization Error Response with the `wallet_unavailable` error code In the event that another component is invoked instead of the Wallet, the End-User MUST be informed and give consent before the invoked component returns the `wallet_unavailable` Authorization Error Response to the Verifier. +## Wallet Attestation + +Wallet Attestations could be an additional correlation factor that could allow End-User tracking. Wallet Attestations SHOULD use privacy-preserving mechanisms similar to the ones that are applied to credentials in an ecosystem, e.g., use of one-time usage Wallet Attestations if the same applies for credentials. + {backmatter} @@ -2672,6 +2687,9 @@ The technology described in this specification was made available from contribut [[ To be removed from the final specification ]] + -23 + * Added `wallet_attestation` parameter to Authorization Request and Response + -22 * Introduced the Digital Credentials Query Language From abbe8912cb2d4a3d700cc85ddde5eb334125ac97 Mon Sep 17 00:00:00 2001 From: Christian Bormann <8774236+c2bo@users.noreply.github.com> Date: Mon, 18 Nov 2024 10:30:44 +0100 Subject: [PATCH 2/5] Apply suggestions from Giuseppe Co-authored-by: Giuseppe De Marco --- openid-4-verifiable-presentations-1_0.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 0872c878..57503187 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -119,7 +119,7 @@ Wallet: : An entity used by the Holder to receive, store, present, and manage Verifiable Credentials and key material. There is no single deployment model of a Wallet: Verifiable Credentials and keys can both be stored/managed locally, or by using a remote self-hosted service, or a remote third-party service. In the context of this specification, the Wallet acts as an OAuth 2.0 Authorization Server (see [@!RFC6749]) towards the Credential Verifier which acts as the OAuth 2.0 Client. Wallet Attestation: -: An attestation designed to prove authenticity of the wallet towards parties it is interacting with, in the context of this specification, the Verifier. The overall concept, format and data structure of a Wallet Attestation is defined in [@!OpenID.VCI]. +: A signed proof crafted to demonstrate the authenticity of the Wallet to the parties it interacts with, specifically the Verifier in this specification. The comprehensive concept, format, and data structure of a Wallet Attestation are outlined in [@!OpenID.VCI]. # Overview @@ -314,7 +314,7 @@ The following is a non-normative example of a transaction data content, after ba ``` `wallet_attestation`: -: OPTIONAL. A boolean value that indicates whether or not a wallet attestation is requested by the Verifier. If the parameter is not present, the default value is `false`. If the value is `true`, a wallet attestation is expected to be part of the response (see `wallet_attestation` in (#response-parameters)). +: OPTIONAL. A boolean value that indicates whether or not a Wallet Attestation is requested by the Verifier. If the parameter is not present, the default value is `false`. If the value is `true`, a Wallet Attestation is expected to be part of the response (see `wallet_attestation` in (#response-parameters)). ## Existing Parameters @@ -1650,7 +1650,7 @@ In the event that another component is invoked instead of the Wallet, the End-Us ## Wallet Attestation -Wallet Attestations could be an additional correlation factor that could allow End-User tracking. Wallet Attestations SHOULD use privacy-preserving mechanisms similar to the ones that are applied to credentials in an ecosystem, e.g., use of one-time usage Wallet Attestations if the same applies for credentials. +Wallet Attestations could be an additional correlation factor that could allow End-User tracking. Wallet Attestations SHOULD use privacy-preserving mechanisms similar to the ones that are applied to Credentials in an ecosystem, e.g., use of one-time usage Wallet Attestations if the same applies for Credentials. {backmatter} From 7371d6ec3920e3b51ebaab24f87f60a80262531a Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Mon, 25 Nov 2024 09:08:24 +0100 Subject: [PATCH 3/5] add vci reference for wallet attestation --- openid-4-verifiable-presentations-1_0.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index ce691616..96824080 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1865,6 +1865,22 @@ Wallet Attestations could be an additional correlation factor that could allow E + + + OpenID for Verifiable Credential Issuance + + SPRIND + + + SPRIND + + + Mattr + + + + + OpenID Federation 1.0 From 6b91eb2c6b346e388d3fcc699f55e9e0c6275af8 Mon Sep 17 00:00:00 2001 From: Christian Bormann <8774236+c2bo@users.noreply.github.com> Date: Wed, 18 Dec 2024 14:58:57 +0100 Subject: [PATCH 4/5] Apply suggestions from Daniel Co-authored-by: Daniel Fett --- openid-4-verifiable-presentations-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index d1a6920d..50a5b045 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -324,7 +324,7 @@ The following is a non-normative example of a transaction data content, after ba ``` `wallet_attestation`: -: OPTIONAL. A boolean value that indicates whether or not a Wallet Attestation is requested by the Verifier. If the parameter is not present, the default value is `false`. If the value is `true`, a Wallet Attestation is expected to be part of the response (see `wallet_attestation` in (#response-parameters)). +: OPTIONAL. A value that indicates whether or not a Wallet Attestation is requested by the Verifier. If the parameter is not present, or is `false`, no Wallet Attestation is requested. Otherwise, a Wallet Attestation is expected to be part of the response (see `wallet_attestation` in (#response-parameters)). ## Existing Parameters @@ -967,7 +967,7 @@ If Presentation Exchange was used for the request, the `presentation_submission` Including the `presentation_submission` parameter as a separate response parameter allows the Wallet to provide the Verifier with additional information about the format and structure in advance of the processing of the VP Token, and can be used even with the Credential formats that do not allow for the direct inclusion of `presentation_submission` parameters inside a Credential itself. `wallet_attestation`: -: REQUIRED if the `wallet_attestation` parameter was present and its value `true` in the Authorization Request (see (#vp_token_request) for more details). The Wallet Attestation presentation MUST be bound to the nonce that was provided in the Authorization Request. The expected format of a Wallet Attestation and validation rules are defined in section TODO of [@!OpenID.VCI]. If the validation of the Wallet Attestation fails, the response is rejected. Additional claims for individual implementations and ecosystems can be added to a Wallet Attestation. +: REQUIRED if the `wallet_attestation` parameter was requested in the Authorization Request (see (#vp_token_request) for more details). The Wallet Attestation presentation MUST be bound to the nonce that was provided in the Authorization Request. The expected format of a Wallet Attestation and validation rules are defined in section TODO of [@!OpenID.VCI]. If the validation of the Wallet Attestation fails, the response MUST be rejected. Additional claims for individual implementations and ecosystems can be added to a Wallet Attestation. Additional response parameters MAY be defined and used, as described in [@!RFC6749]. From 5b99be9bc2802ca866a56b89984b943562e02e00 Mon Sep 17 00:00:00 2001 From: Christian Bormann <8774236+c2bo@users.noreply.github.com> Date: Wed, 18 Dec 2024 15:04:09 +0100 Subject: [PATCH 5/5] point to the correct appendix --- openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 50a5b045..777dd48e 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -967,7 +967,7 @@ If Presentation Exchange was used for the request, the `presentation_submission` Including the `presentation_submission` parameter as a separate response parameter allows the Wallet to provide the Verifier with additional information about the format and structure in advance of the processing of the VP Token, and can be used even with the Credential formats that do not allow for the direct inclusion of `presentation_submission` parameters inside a Credential itself. `wallet_attestation`: -: REQUIRED if the `wallet_attestation` parameter was requested in the Authorization Request (see (#vp_token_request) for more details). The Wallet Attestation presentation MUST be bound to the nonce that was provided in the Authorization Request. The expected format of a Wallet Attestation and validation rules are defined in section TODO of [@!OpenID.VCI]. If the validation of the Wallet Attestation fails, the response MUST be rejected. Additional claims for individual implementations and ecosystems can be added to a Wallet Attestation. +: REQUIRED if the `wallet_attestation` parameter was requested in the Authorization Request (see (#vp_token_request) for more details). The Wallet Attestation presentation MUST be bound to the nonce that was provided in the Authorization Request. The expected format of a Wallet Attestation and validation rules are defined in Appendix E of [@!OpenID.VCI]. If the validation of the Wallet Attestation fails, the response MUST be rejected. Additional claims for individual implementations and ecosystems can be added to a Wallet Attestation. Additional response parameters MAY be defined and used, as described in [@!RFC6749].