request_uri extension

diagrams/request_uri_mode_post.md

@@ -0,0 +1,45 @@
+```plantuml
+@startuml
+
+autonumber
+
+box "Wallet"
+participant "Metadata" as wm
+participant "Authorization Endpoint" as w
+end box
+
+participant "User Agent" as u
+
+box "Verifier"
+participant "Frontend" as r
+participant "Request Endpoint" as rp
+participant "Response Endpoint" as rb
+end box
+
+u --> r : use
+activate r
+
+r --> u: authorization request\n(client_id, request_uri, request_uri_mode=POST, [client_id_scheme])
+deactivate r
+u --> w: authorization request\n(client_id, request_uri, request_uri_mode=POST, [client_id_scheme])
+activate w
+w --> rp: POST **request_uri** (\n[OPTIONAL]wallet_metadata, \n[OPTIONAL]wallet_nonce)
+rp -> rp: create and sign (and optionally encrypt) request object 
+rp --> w: **signed (optionally encrypted) request object** (client_id, client_id_scheme, issuer_nonce, nonce, \nresponse_uri, presentation_definition, state)
+w -> w: authenticate and\n authorize Verifier
+
+note over u, w: User authentication and Credential selection/confirmation
+
+w -> w: create verifiable\npresentation (credential)
+w --> rb: POST response \n(vp_token(credential presentation(s) associated with nonce), presentation_submission, state)
+rb -> rb: check state, store vp_token\n & create redirect_url
+rb --> w: redirect_url
+w --> u: redirect (response_code)
+u --> r: redirect (response_code)
+activate r
+r --> rb: get presentation response\n (transaction_id, response_code)
+rb --> r: presentation response
+r -> r: validate presentation \n(incl. nonce binding)
+r -> r: use presented credential 
+@enduml
+```

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

@@ -232,9 +232,9 @@ Presentation of Verifiable Credentials using OpenID for Verifiable Presentations
 
 The Authorization Request follows the definition given in [@!RFC6749] taking into account the recommendations given in [@!I-D.ietf-oauth-security-topics].
 
-The Verifier may send an Authorization Request as Request Object by value or by reference as defined in JWT-Secured Authorization Request (JAR) [@RFC9101].
+The Verifier MAY send an Authorization Request as a Request Object either by value or by reference, as defined in the JWT-Secured Authorization Request (JAR) [@RFC9101]. The Request Object MAY contain a subset of parameters, which the Wallet uses to request the creation of a new Request Object from the Verifier. This request is made using an HTTP POST to the Verifier's `request_uri` endpoint. The Wallet MAY support this feature, which involves providing some details about its technical capabilities with the Verifier. This allows the Verifier to generate a Request Object that is specifically designed to match the capabilities of the Wallet making the request. Verifiers that support this feature MUST provide the `request_uri_method`, as defined below, to indicate to the Wallet that they support this feature.
 
-The Verifier articulates requirements of the Credential(s) that are requested using `presentation_definition` and `presentation_definition_uri` parameters that contain a Presentation Definition JSON object as defined in Section 5 of [@!DIF.PresentationExchange]. Wallet implementations MUST process Presentation Definition JSON object and select candidate Verifiable Credential(s) using the evaluation process described in Section 8 of [@!DIF.PresentationExchange].
+The Verifier specifies the requirements for the Credential(s) being requested using the `presentation_definition` and `presentation_definition_uri` parameters. These parameters contain a Presentation Definition JSON object as outlined in Section 5 of [@!DIF.PresentationExchange]. Wallet implementations are required to process this Presentation Definition JSON object and select suitable Verifiable Credential(s) following the evaluation process detailed in Section 8 of [@!DIF.PresentationExchange].
 
 The Verifier communicates a Client Identifier Scheme that indicate how the Wallet is supposed to interpret the Client Identifier and associated data in the process of Client identification, authentication, and authorization using `client_id_scheme` parameter. This parameter enables deployments of this specification to use different mechanisms to obtain and validate Client metadata beyond the scope of [@!RFC6749]. A certain Client Identifier Scheme MAY require the Verifier to sign the Authorization Request as means of authentication and/or pass additional parameters and require the Wallet to process them.
 
@@ -261,6 +261,12 @@ This specification defines the following new parameters:
 
 A public key to be used by the Wallet as an input to the key agreement to encrypt Authorization Response (see (#jarm)). It MAY be passed by the Verifier using the `jwks` or the `jwks_uri` claim within the `client_metadata` or `client_metadata_uri` request parameter.
 
+`request_uri_method`: 
+: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two values are defined for `request_uri_method` in this specification: `get` and `post`. Please note that these values are case-insensitive. The GET method, as defined in [@RFC9101], involves the Wallet sending a GET request to retrieve a Request Object. The POST method, newly defined in this specification, involves the Wallet requesting the creation of a new Request Object as outlined in [@RFC9101] by sending an HTTP POST request to the request URI. This request using the HTTP POST is detailed in (#request_uri_method_post). 
+`request_uri_method` MUST only be present if the request contains a `request_uri` parameter. If the `request_uri_method` parameter is not present, the Wallet MUST process the `request_uri` as defined in [@RFC9101]. Wallets not supporting the new method `post` will send a GET request to the request URI (default behavior as defined in [@RFC9101]).  
+
+If the Verifier uses the `request_uri_method` set to `post`, it SHOULD add the `client_metadata` parameter to the authorization request to pass its capabilities. This enables the Wallet to assess the Verifier's capabilities, allowing it to transmit only the relevant capabilities through the `wallet_metadata` request parameter in the Request URI POST request. If the Verifier uses the parameter `client_id_scheme` in the Request Object, it MUST also add the same `client_id_scheme` value in the Authorization Request.   
+
 The following additional considerations are given for pre-existing Authorization Request parameters:
 
 `nonce`:
@@ -283,6 +289,17 @@ The following is a non-normative example of an Authorization Request:
     &nonce=n-0S6_WzA2Mj HTTP/1.1
 ```
 
+The following is a non-normative example with a `request_uri_mode` parameter (including the additional parameters `client_id_scheme` and `client_metadata`): 
+
+```
+  GET /authorize?
+    client_id=client.example.org
+    &client_id_scheme=x509_san_dns
+    &client_metadata=...
+    &request_uri=https%3A%2F%2Fclient.example.org%2Frequest
+    &request_uri_mode=post HTTP/1.1
+```
+
 ## `presentation_definition` Parameter {#request_presentation_definition}
 
 This parameter contains a Presentation Definition JSON object conforming to the syntax defined in Section 5 of [@!DIF.PresentationExchange].
@@ -460,6 +477,53 @@ To use `client_id_scheme` values `entity_id`, `did`, `verifier_attestation`, `x5
 
 Other specifications can define further values for the `client_id_scheme` parameter. It is RECOMMENDED to use collision-resistant names for such values.
 
+## Request URI Method POST {#request_uri_method_post}
+
+This request is offered at the Request URI endpoint by the Verifier.  
+
+The request MUST use the HTTP POST method with the https scheme and the media type set to "application/oauth-authz-req+jwt".
+
+The following parameters are defined: 
+
+`wallet_metadata`:
+: OPTIONAL. A JSON Object containing metadata parameters as defined in (#as_metadata_parameters). 
+
+`wallet_nonce`:
+: OPTIONAL. A JSON String containing as fresh, cryptographically random number with sufficient entropy the Verifier MUST use when creating the signed presentation request object. 
+
+If the Wallet wants the Verifier to encrypt the request object, it SHOULD use the `jwks` or `jwks_uri` claim within `wallet_metadata` to pass the public key for the input to the key agreement. Other mechanisms to pass the encryption key can be used as well. 
+
+### Request URI Response
+
+The Request URI Response MUST be a HTTPS POST response with the "application/oauth-authz-req+jwt" media type and contain a signed, optionally encrypted, request object as defined in [@RFC9101]. 
+
+The following is a non-normative example of a request object:
+
+```json
+{
+   "client_id": "client.example.org",
+   "client_id_scheme": "x509_san_dns",
+   "response_uri": "https://client.example.org/post",
+   "response_type": "vp_token",
+   "response_mode": "direct_post",
+   "presentation_definition": {...},
+   "nonce": "n-0S6_WzA2Mj",
+   "state" : "eyJhb...6-sVA
+}
+```
+
+The Wallet MUST process the request process as defined in [@RFC9101]. Additionally, if the Wallet passed a `wallet_nonce` in the post request, the Wallet MUST validate whether the request object contains the respective nonce value in a `wallet_nonce`. If it does not, the Wallet MUST terminate request processing. 
+
+The request object MUST fulfill the requirements as defined in (#vp_token_request).
+
+The Wallet MUST extract the set of authorization request parameters from the Request Object. The Wallet MUST only use the parameters in this Request Object, even if the same parameter was provided in an authorization request query parameter. The Client ID value in the `client_id` authorization request parameter in the Request Object 'client_id' claim MUST be identical. If the Authorization Request contains a `client_id_scheme` parameter, the `client_id_scheme` authorization request parameter in the Request Object 'client_id_scheme' claim MUST be identical.
+
+The Wallet then validates the request, as specified in OAuth 2.0 [RFC6749].
+
+### Request URI Error Response
+
+If the Verifier responds with any HTTP error response, the Wallet MUST terminate the process.
+
 # Response {#response}
 
 A VP Token is only returned if the corresponding Authorization Request contained a `presentation_definition` parameter, a `presentation_definition_uri` parameter, or a `scope` parameter representing a Presentation Definition (#vp_token_request).
@@ -1088,6 +1152,12 @@ Implementations MUST follow [@!BCP195].
 
 Whenever TLS is used, a TLS server certificate check MUST be performed, per [@!RFC6125].
 
+# Privacy Considerations
+
+## Authorization Requests with Request URI
+
+The Wallet MUST NOT sent personally identifiable information (PII) or any other data that could be used for fingerprinting to the Request URI in order to prevent user tracking. 
+
 {backmatter}
 
 <reference anchor="VC_DATA" target="https://www.w3.org/TR/2022/REC-vc-data-model-20220303/">
@@ -1675,6 +1745,10 @@ The technology described in this specification was made available from contribut
 
    [[ To be removed from the final specification ]]
 
+   -21
+
+   * added POST request mode for Request URI
+
    -20
 
    * added "verifier_attestation" client id scheme value