request_uri extension

diagrams/create_request_uri.md

@@ -0,0 +1,49 @@
+```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: **signed authorization request**\n(client_id, create_request_uri, state)
+deactivate r
+u --> w: **signed authorization request**\n(client_id, create_request_uri, state)
+activate w
+w --> w: check authorization request signature
+w --> rp: POST **create request request** (\nstate,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]w_nonce, \n[OPTIONAL]w_ephm_key, \n[OPTIONAL]wallet attestation, wallet attestation pop(v_nonce))
+note over u, w: HTTP status code 401 signals need to authenticate
+rp --> wm: [OPTIONAL] get wallet metadata
+wm --> rp: [OPTIONAL] wallet metadata
+rp -> rp: create and sign presentation request object (client_id, w_nonce, nonce, response_uri, \npresentation_definition, state)
+rp --> w: **signed request object** (client_id, w_nonce, nonce, response_uri, \npresentation_definition, state)
+note over u, w: do we want to allow unsigned presentation request objects, too?
+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, presentation_submission, state)
+rb --> w: redirect_url
+w --> u: response (response_code)
+u --> r: response (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,7 +232,7 @@ 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 Request Object by value or by reference as defined in JWT-Secured Authorization Request (JAR) [@RFC9101]. Additionally, the request can be sent as an object containing only a subset of parameters needed to in a subseqent step request the creation of a request object from the verifier through a HTTPS POST request via a newly introduced `create request endpoint`. 
 
 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].
 
@@ -261,6 +261,9 @@ 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.
 
+`create_request_uri`: 
+: OPTIONAL. A string containing an HTTPS URL pointing to a resource where the Wallet MUST request the creation of a request object as defined in [@RFC9101]. The details of this endpoint are defined in (#create_request_uri). This parameter MUST only be combined with `client_id`, `state`, `client_id_scheme`, and any client id scheme specific parameter. It SHOULD be sent in a signed authorization request. 
+
 The following additional considerations are given for pre-existing Authorization Request parameters:
 
 `nonce`:
@@ -283,6 +286,18 @@ 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 of a request object with a `create_request_uri``: 
+
+```
+{
+  "iss": "https://client.example.org",
+  "aud": "https://server.example.com",
+  "state": "af0ifjsldkj",
+  "nonce": "n-0S6_WzA2Mj",
+  "create_request_uri": "https://client.example.org/create_request"
+}
+```
+
 ## `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 +475,43 @@ 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.
 
+# Create Request Endpoint {#create_response_uri}
+
+This endpoint is offered by the Verifier. The Wallet sends a request to this endpoint if the Verifier requests so by passing the `create_request_uri` authorization request parameter. In case of success, the response is a request object that the Wallet MUST process in the same way as a request object as defined in [@RFC9101]. 
+
+Create Request requests MUST be HTTPS POST requests with the "application/json" media type.
+
+The following parameters are defined: 
+
+`state`:
+: A JSON String containing the value of the corresponding authorization Request's `state` parameter, if present.
+
+`issuer`:
+: A JSON containing an HTTPS URL designating the Issuer URL of the Wallet (acting as a OAuth Authorization Server). The Verifier MAY obtain the Wallet's metadata by adding the well-know location `oauth-authorization-server` as specified in [@!RFC8414]. Metadata MAY also be provided by other means, for example in the wallet attestation. 
+
+`w_nonce`:
+: A JSON String containing as fresh, cryptographically random number with sufficient entropy the Verifier MUST use when creating the signed presentation request object. 
+
+`client_assertion`
+: A JSON String containing a Wallet attestation along with a proof of possession of the public key as defined in [@!I-D.ietf-oauth-attestation-based-client-auth]. This assertion is used to authenticate the Wallet towards the Verifier. 
+
+### Create Request Response
+
+The Create Request Response MUST be HTTPS POST response with the "application/oauth-authz-req+jwt" media type and contain a signed request object as defined in [@RFC9101]. It MUST fulfill the requirements as defined in (#vp_token_request).
+
+### Create Request Error Response
+
+The error code `401` signals to the Wallet that it needs to authenticate to the Verifier. In this case, the error response SHOULD contain a `WWW-Authenticate` header for every attestation method the Verifier supports.
+
+Below a non-normative example for the Wallet attestation method as specified above. The `WWW-Authenticate` contains the nonce value the Wallet MUST use in the calculation of the proof of possession of the wallet attestation. 
+
+```
+HTTP/1.1 401 Unauthorized
+    WWW-Authenticate: wallet-attestation error="use_nonce", \
+      error_description="Verifier requires wallet attestation"
+    Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v
+```
+
 # 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).