Wallet Attestation: Option with new request/response parameters

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

@@ -121,6 +121,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:
+: 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 
 
 This specification defines a mechanism on top of OAuth 2.0 to request and present Verifiable Credentials as Verifiable Presentations.
@@ -320,6 +323,9 @@ The following is a non-normative example of a transaction data content, after ba
 }
 ```
 
+`wallet_attestation`:
+: 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
 
 The following additional considerations are given for pre-existing Authorization Request parameters:
@@ -620,6 +626,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"
 }
 ```
@@ -959,6 +966,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 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].
 The Client MUST ignore any unrecognized parameters.
@@ -970,6 +980,7 @@ HTTP/1.1 302 Found
 Location: https://client.example.org/cb#
   presentation_submission=...
   &vp_token=...
+  &wallet_attestation=...
 ```
 
 ### Examples (DCQL) {#response_dcql_query}
@@ -1480,7 +1491,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. 
 
@@ -1616,12 +1627,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}
 
 <reference anchor="VC_DATA" target="https://www.w3.org/TR/2022/REC-vc-data-model-20220303/">
@@ -1833,6 +1848,22 @@ In the event that another component is invoked instead of the Wallet, the End-Us
         </front>
 </reference>
 
+<reference anchor="OpenID.VCI" target="https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html">
+        <front>
+          <title>OpenID for Verifiable Credential Issuance</title>
+          <author initials="T." surname="Lodderstedt" fullname="Torsten Lodderstedt">
+            <organization>SPRIND</organization>
+          </author>
+          <author initials="K." surname="Yasuda" fullname="Kristina Yasuda">
+            <organization>SPRIND</organization>
+          </author>
+          <author initials="T." surname="Looker" fullname="Tobias Looker">
+            <organization>Mattr</organization>
+          </author>
+          <date day="21" month="August" year="2024"/>
+        </front>
+</reference>
+
 <reference anchor="OpenID.Federation" target="https://openid.net/specs/openid-federation-1_0.html">
         <front>
           <title>OpenID Federation 1.0</title>
@@ -2694,6 +2725,7 @@ The technology described in this specification was made available from contribut
 
    -23
 
+   * Added `wallet_attestation` parameter to Authorization Request and Response
    * fixed percent-encoding of URI examples
    * fixed an example that used 'client' where 'wallet' is more appropriate
    * make SIOP example request/response consistent with each other