From 0ef69f7f88624c284bed8b3d341601454ed22aaf Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 2 Nov 2023 18:17:21 +0100 Subject: [PATCH 01/91] create sequence diagram --- diagrams/create_request_uri.md | 49 ++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 diagrams/create_request_uri.md diff --git a/diagrams/create_request_uri.md b/diagrams/create_request_uri.md new file mode 100644 index 00000000..7632c380 --- /dev/null +++ b/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: **create request request** (\nstate,\n[OPTIONAL]iss, \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 +``` \ No newline at end of file From b402aa771bbc7fd2e9b01554d3a0ce9a5e107145 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 2 Nov 2023 18:18:55 +0100 Subject: [PATCH 02/91] added POST to indicate HTTP method --- diagrams/create_request_uri.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diagrams/create_request_uri.md b/diagrams/create_request_uri.md index 7632c380..0a2f0fa8 100644 --- a/diagrams/create_request_uri.md +++ b/diagrams/create_request_uri.md @@ -24,7 +24,7 @@ deactivate r u --> w: **signed authorization request**\n(client_id, create_request_uri, state) activate w w --> w: check authorization request signature -w --> rp: **create request request** (\nstate,\n[OPTIONAL]iss, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]w_nonce, \n[OPTIONAL]w_ephm_key, \n[OPTIONAL]wallet attestation, wallet attestation pop(v_nonce)) +w --> rp: POST **create request request** (\nstate,\n[OPTIONAL]iss, \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 @@ -36,7 +36,7 @@ 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) +w --> rb: POST response \n(vp_token, presentation_submission, state) rb --> w: redirect_url w --> u: response (response_code) u --> r: response (response_code) From 673fcf79c9b2002f87ae9adcbc52919de442788e Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 2 Nov 2023 18:44:23 +0100 Subject: [PATCH 03/91] added create_presentation_uri parameter --- openid-4-verifiable-presentations-1_0.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 97a1814a..97bd1b96 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/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]. From 9dff2821b12be8fae623cc0e8c04d9e4cd7494d5 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 2 Nov 2023 18:51:22 +0100 Subject: [PATCH 04/91] added create request endpoint --- openid-4-verifiable-presentations-1_0.md | 37 ++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 97bd1b96..026eff08 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -475,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). From f945d547e4942590437569a091276139f96ef163 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 2 Nov 2023 18:51:49 +0100 Subject: [PATCH 05/91] fixed iss --- diagrams/create_request_uri.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diagrams/create_request_uri.md b/diagrams/create_request_uri.md index 0a2f0fa8..011e322e 100644 --- a/diagrams/create_request_uri.md +++ b/diagrams/create_request_uri.md @@ -24,7 +24,7 @@ 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]iss, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]w_nonce, \n[OPTIONAL]w_ephm_key, \n[OPTIONAL]wallet attestation, wallet attestation pop(v_nonce)) +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 From 0a42d0fd76a49ab26f471c6926160abeb7386b2e Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 8 Nov 2023 16:47:12 +0100 Subject: [PATCH 06/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Giuseppe De Marco --- 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 026eff08..d7bc829d 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/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]. 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 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 an object containing only a subset of parameters needed to, in a subsequent step, request the creation of a request object from the Verifier through an 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]. From 37fbccfb39d14ff8ac8dc46a0258bb056d007312 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 8 Nov 2023 16:53:55 +0100 Subject: [PATCH 07/91] added iat and exp --- openid-4-verifiable-presentations-1_0.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index d7bc829d..0a991195 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -292,6 +292,8 @@ The following is a non-normative example of a request object with a `create_requ { "iss": "https://client.example.org", "aud": "https://server.example.com", + "iat": 1541493724, + "exp": 1516247022, "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "create_request_uri": "https://client.example.org/create_request" @@ -479,7 +481,7 @@ Other specifications can define further values for the `client_id_scheme` parame 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. +Create Request requests MUST be HTTPS POST requests with the "application/oauth-authz-req+jwt" media type. The following parameters are defined: From b7c2570c2ac004ee8040c3392d9aa6188f857176 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 8 Nov 2023 16:54:19 +0100 Subject: [PATCH 08/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Giuseppe De Marco --- 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 0a991195..cf241d3d 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -489,7 +489,7 @@ The following parameters are defined: : 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. +: A JSON containing an HTTPS URL designating the Issuer URL of the Wallet (acting as a OAuth 2.0 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. From 350391d23b0cb6ada7a4e2a916f347c9e42e7da7 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 8 Nov 2023 17:07:26 +0100 Subject: [PATCH 09/91] added trustworthiness check to sequence diagram --- diagrams/create_request_uri.md | 1 + 1 file changed, 1 insertion(+) diff --git a/diagrams/create_request_uri.md b/diagrams/create_request_uri.md index 011e322e..8415539d 100644 --- a/diagrams/create_request_uri.md +++ b/diagrams/create_request_uri.md @@ -24,6 +24,7 @@ deactivate r u --> w: **signed authorization request**\n(client_id, create_request_uri, state) activate w w --> w: check authorization request signature +w --> w: check on trustworthiness of Verifier (approach on trust mechanism) 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 From 8056fc15835b5bd5b22153509c992ce570897e18 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Fri, 17 Nov 2023 19:01:00 +0100 Subject: [PATCH 10/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Giuseppe De Marco --- 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 cf241d3d..1f45d26c 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -481,7 +481,7 @@ Other specifications can define further values for the `client_id_scheme` parame 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/oauth-authz-req+jwt" media type. +The request MUST use the POST method, the https scheme and the media type set to "application/oauth-authz-req+jwt". The following parameters are defined: From 9061d5059c68c1758793c7125813c457debc1156 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Fri, 17 Nov 2023 19:01:08 +0100 Subject: [PATCH 11/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Giuseppe De Marco --- 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 1f45d26c..8d7f03fc 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -505,7 +505,7 @@ The Create Request Response MUST be HTTPS POST response with the "application/oa 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. +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 From ba585be80842606b96e05f479e2b1581a59d633f Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Fri, 17 Nov 2023 19:01:15 +0100 Subject: [PATCH 12/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Giuseppe De Marco --- 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 8d7f03fc..3e0f3595 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -489,7 +489,7 @@ The following parameters are defined: : 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 2.0 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. +: A JSON containing an HTTPS URL designating the Issuer URL of the Wallet (acting as a OAuth 2.0 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. From b1ee70e0c903ef8ff09ec8d51d99ea81b096e543 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 20 Dec 2023 20:00:11 +0100 Subject: [PATCH 13/91] reworked based on feedback from Paul and Giuseppe --- ...uest_uri.md => request_uri_mode_create.md} | 11 +++--- openid-4-verifiable-presentations-1_0.md | 37 ++++++++----------- 2 files changed, 21 insertions(+), 27 deletions(-) rename diagrams/{create_request_uri.md => request_uri_mode_create.md} (63%) diff --git a/diagrams/create_request_uri.md b/diagrams/request_uri_mode_create.md similarity index 63% rename from diagrams/create_request_uri.md rename to diagrams/request_uri_mode_create.md index 8415539d..f61292ac 100644 --- a/diagrams/create_request_uri.md +++ b/diagrams/request_uri_mode_create.md @@ -19,18 +19,17 @@ end box u --> r : use activate r -r --> u: **signed authorization request**\n(client_id, create_request_uri, state) +r --> u: **signed authorization request**\n(client_id, request_uri, request_uri_mode=create, state) deactivate r -u --> w: **signed authorization request**\n(client_id, create_request_uri, state) +u --> w: **signed authorization request**\n(client_id, equest_uri, request_uri_mode=create, state) activate w w --> w: check authorization request signature w --> w: check on trustworthiness of Verifier (approach on trust mechanism) -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 +w --> rp: POST **request_uri_** (\nstate,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]w_nonce, \n[OPTIONAL]w_ephm_key) 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) +rp -> rp: create and sign (and optionally encrypt) presentation request object (client_id, w_nonce, nonce, response_uri, \npresentation_definition, state) +rp --> w: **signed (optionally encrypted) 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 diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 3e0f3595..f839df31 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -261,8 +261,8 @@ 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. +`request_uri_mode`: +: OPTIONAL. A string determining the mode to use the `request_uri` passed in the same request. This specification defines two values for this parameter: `fetch` and `create`. `fetch` is the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `create` is a new mode defined in this specification where the Wallet requests the creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_mode_create). `request_uri_mode` MUST only be present if the request also contains a `request_uri` parameter. It SHOULD be sent in a signed authorization request. If the parameter is not present, the Wallet MUST process the `request_uri` as defined in [@RFC9101]. The following additional considerations are given for pre-existing Authorization Request parameters: @@ -286,7 +286,7 @@ 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``: +The following is a non-normative example of a request object with a `request_uri_mode`: ``` { @@ -296,7 +296,8 @@ The following is a non-normative example of a request object with a `create_requ "exp": 1516247022, "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", - "create_request_uri": "https://client.example.org/create_request" + "request_uri": "https://client.example.org/request", + "request_uri_mode": "create" } ``` @@ -477,25 +478,28 @@ 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} +# Request URI Mode Create {#response_uri_mode_create} -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]. +This request is offered at the Request URI endpoint by the Verifier. 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]. The request MUST use the POST method, the https scheme and the media type set to "application/oauth-authz-req+jwt". The following parameters are defined: `state`: -: A JSON String containing the value of the corresponding authorization Request's `state` parameter, if present. +: OPTIONAL. 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 2.0 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. +: OPTIONAL. A JSON containing an HTTPS URL designating the Issuer URL of the Wallet (acting as a OAuth 2.0 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_metadata`parameter`. + +`wallet_metadata`; +: OPTIONAL. A JSON Object containing metadata parameters as defined in (#as_metadata_parameters). `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. +: OPTIONAL. 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. +`w_ephm_key`: +: OPTIONAL. A JWK object containing a key the Verifier MUST use to encrypt the request object. ### Create Request Response @@ -503,16 +507,7 @@ The Create Request Response MUST be HTTPS POST response with the "application/oa ### 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 -``` +TBD # Response {#response} From d29107b00b1fdebca44d664fcb3f734cf312ac23 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 20 Dec 2023 21:13:40 +0100 Subject: [PATCH 14/91] some fixes --- diagrams/request_uri_mode_create.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index f61292ac..2289bd70 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -21,11 +21,11 @@ activate r r --> u: **signed authorization request**\n(client_id, request_uri, request_uri_mode=create, state) deactivate r -u --> w: **signed authorization request**\n(client_id, equest_uri, request_uri_mode=create, state) +u --> w: **signed authorization request**\n(client_id, request_uri, request_uri_mode=create, state) activate w w --> w: check authorization request signature w --> w: check on trustworthiness of Verifier (approach on trust mechanism) -w --> rp: POST **request_uri_** (\nstate,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]w_nonce, \n[OPTIONAL]w_ephm_key) +w --> rp: POST **request_uri** (\n[OPTIONALstate,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]w_nonce, \n[OPTIONAL]w_ephm_key) rp --> wm: [OPTIONAL] get wallet metadata wm --> rp: [OPTIONAL] wallet metadata rp -> rp: create and sign (and optionally encrypt) presentation request object (client_id, w_nonce, nonce, response_uri, \npresentation_definition, state) From d198019d52c202afd08479c06bc3f6f4e3b79f3e Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 20 Dec 2023 21:22:29 +0100 Subject: [PATCH 15/91] fixed intendation --- 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 f839df31..376c3eda 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -478,7 +478,7 @@ 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 Mode Create {#response_uri_mode_create} +## Request URI Mode Create {#request_uri_mode_create} This request is offered at the Request URI endpoint by the Verifier. 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]. @@ -492,7 +492,7 @@ The following parameters are defined: `issuer`: : OPTIONAL. A JSON containing an HTTPS URL designating the Issuer URL of the Wallet (acting as a OAuth 2.0 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_metadata`parameter`. -`wallet_metadata`; +`wallet_metadata`: : OPTIONAL. A JSON Object containing metadata parameters as defined in (#as_metadata_parameters). `w_nonce`: From 30d59a87793c1bd10032ae0017941691b36299f6 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Wed, 20 Dec 2023 21:27:52 +0100 Subject: [PATCH 16/91] changed parameter name according to Oliver's suggestion --- 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 376c3eda..e46b3c0a 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -261,8 +261,8 @@ 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_mode`: -: OPTIONAL. A string determining the mode to use the `request_uri` passed in the same request. This specification defines two values for this parameter: `fetch` and `create`. `fetch` is the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `create` is a new mode defined in this specification where the Wallet requests the creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_mode_create). `request_uri_mode` MUST only be present if the request also contains a `request_uri` parameter. It SHOULD be sent in a signed authorization request. If the parameter is not present, the Wallet MUST process the `request_uri` as defined in [@RFC9101]. +`request_uri_method`: +: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` passed in the same request. This specification defines two values for this parameter: `GET` and `POST`. `GET` is the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `POST` is a new mode defined in this specification where the Wallet requests the creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_method_post). `request_uri_mode` MUST only be present if the request also contains a `request_uri` parameter. It SHOULD be sent in a signed authorization request. If the 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]). The following additional considerations are given for pre-existing Authorization Request parameters: @@ -478,7 +478,7 @@ 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 Mode Create {#request_uri_mode_create} +## Request URI Method POST {#request_uri_method_post} This request is offered at the Request URI endpoint by the Verifier. 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]. From 63a86f73cfc60427eb34b5121a23a16155913563 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 6 Jan 2024 10:49:55 +0100 Subject: [PATCH 17/91] fixed request mode in diagram --- diagrams/request_uri_mode_create.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index 2289bd70..dd8c5078 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -19,9 +19,9 @@ end box u --> r : use activate r -r --> u: **signed authorization request**\n(client_id, request_uri, request_uri_mode=create, state) +r --> u: **signed authorization request**\n(client_id, request_uri, request_uri_mode=POST, state) deactivate r -u --> w: **signed authorization request**\n(client_id, request_uri, request_uri_mode=create, state) +u --> w: **signed authorization request**\n(client_id, request_uri, request_uri_mode=POST, state) activate w w --> w: check authorization request signature w --> w: check on trustworthiness of Verifier (approach on trust mechanism) From 70ac39b1db9aa00da8f57f0d35ce0757bb3f75ca Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 6 Jan 2024 11:13:14 +0100 Subject: [PATCH 18/91] renamed w_nonce to issuer_nonce --- diagrams/request_uri_mode_create.md | 6 +++--- openid-4-verifiable-presentations-1_0.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index dd8c5078..54affb71 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -25,11 +25,11 @@ u --> w: **signed authorization request**\n(client_id, request_uri, request_uri_ activate w w --> w: check authorization request signature w --> w: check on trustworthiness of Verifier (approach on trust mechanism) -w --> rp: POST **request_uri** (\n[OPTIONALstate,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]w_nonce, \n[OPTIONAL]w_ephm_key) +w --> rp: POST **request_uri** (\n[OPTIONALstate,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]issuer_nonce, \n[OPTIONAL]w_ephm_key) rp --> wm: [OPTIONAL] get wallet metadata wm --> rp: [OPTIONAL] wallet metadata -rp -> rp: create and sign (and optionally encrypt) presentation request object (client_id, w_nonce, nonce, response_uri, \npresentation_definition, state) -rp --> w: **signed (optionally encrypted) request object** (client_id, w_nonce, nonce, response_uri, \npresentation_definition, state) +rp -> rp: create and sign (and optionally encrypt) presentation request object (client_id, issuer_nonce, nonce, response_uri, \npresentation_definition, state) +rp --> w: **signed (optionally encrypted) request object** (client_id, issuer_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 diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index e46b3c0a..3f31a217 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -495,7 +495,7 @@ The following parameters are defined: `wallet_metadata`: : OPTIONAL. A JSON Object containing metadata parameters as defined in (#as_metadata_parameters). -`w_nonce`: +`issuer_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. `w_ephm_key`: From e35ab320a92f9f79cef2183ebdb593db471c0ff0 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 6 Jan 2024 11:18:35 +0100 Subject: [PATCH 19/91] signed request is sent as request parameter --- diagrams/request_uri_mode_create.md | 4 ++-- openid-4-verifiable-presentations-1_0.md | 8 ++++++++ 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index 54affb71..138b393c 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -19,9 +19,9 @@ end box u --> r : use activate r -r --> u: **signed authorization request**\n(client_id, request_uri, request_uri_mode=POST, state) +r --> u: authorization request\n(client_id, request{request_uri, request_uri_mode=POST, state}) deactivate r -u --> w: **signed authorization request**\n(client_id, request_uri, request_uri_mode=POST, state) +u --> w: authorization request\n(client_id, request{request_uri, request_uri_mode=POST, state}) activate w w --> w: check authorization request signature w --> w: check on trustworthiness of Verifier (approach on trust mechanism) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 3f31a217..efac2692 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -301,6 +301,14 @@ The following is a non-normative example of a request object with a `request_uri } ``` +It is sent to the Wallet using the `request` parameter as defined in [@RFC9101] as shown in the following example. + +``` + GET /authorize? + client_id=https://client.example.org + &request=... 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]. From 8cb645f13e606a61705884fe9e5f553f6f9c5626 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 6 Jan 2024 11:30:52 +0100 Subject: [PATCH 20/91] note on nonce binding of vp_token content --- diagrams/request_uri_mode_create.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index 138b393c..4e145063 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -36,7 +36,7 @@ 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) +w --> rb: POST response \n(vp_token(credential presentation(s) associated with nonce), presentation_submission, state) rb --> w: redirect_url w --> u: response (response_code) u --> r: response (response_code) From 0ced90a04fcfcf24aa408cb73f95ce81adb9ba35 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 6 Jan 2024 11:33:55 +0100 Subject: [PATCH 21/91] Update diagrams/request_uri_mode_create.md Co-authored-by: Oliver Terbu <43441584+awoie@users.noreply.github.com> --- diagrams/request_uri_mode_create.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index 4e145063..887f836e 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -38,7 +38,7 @@ 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 --> w: redirect_url -w --> u: response (response_code) +w --> u: redirect (response_code) u --> r: response (response_code) activate r r --> rb: get presentation response\n (transaction_id, response_code) From 42f68663d5ed5a11988a131f8bdf644aaa77eb6c Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 6 Jan 2024 11:34:19 +0100 Subject: [PATCH 22/91] Update diagrams/request_uri_mode_create.md --- diagrams/request_uri_mode_create.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index 887f836e..1c326099 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -39,7 +39,7 @@ w -> w: create verifiable\npresentation (credential) w --> rb: POST response \n(vp_token(credential presentation(s) associated with nonce), presentation_submission, state) rb --> w: redirect_url w --> u: redirect (response_code) -u --> r: response (response_code) +u --> r: redirect (response_code) activate r r --> rb: get presentation response\n (transaction_id, response_code) rb --> r: presentation response From 4f335fcee8d96de37bc8d92c9b99a491862d9e68 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 6 Jan 2024 11:59:33 +0100 Subject: [PATCH 23/91] added explanation why the first request should be signed --- openid-4-verifiable-presentations-1_0.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index efac2692..d6c4ac09 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -262,7 +262,13 @@ 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` passed in the same request. This specification defines two values for this parameter: `GET` and `POST`. `GET` is the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `POST` is a new mode defined in this specification where the Wallet requests the creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_method_post). `request_uri_mode` MUST only be present if the request also contains a `request_uri` parameter. It SHOULD be sent in a signed authorization request. If the 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]). +: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` passed in the same request. This specification defines two values for this parameter: `GET` and `POST`. `GET` is +the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `POST` is a new mode defined in this specification where the Wallet requests the +creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_method_post). +`request_uri_mode` MUST only be present if the request also contains a `request_uri` parameter. If the 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]). +This parameter SHOULD be sent in a signed authorization request in order to allow the Wallet to authenticate the Verifier before it fetches the presentation request from the Verifier's request URI. +This allows the Wallet to determine whether the Verifier is trustworthy before sending a request to its Request URI. The following additional considerations are given for pre-existing Authorization Request parameters: From bfc2bdcd3ef86161785d1e12688456a1cd49df65 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Sun, 14 Jan 2024 19:49:49 +0100 Subject: [PATCH 24/91] Apply editorial suggestions from Giuseppe Co-authored-by: Giuseppe De Marco --- diagrams/request_uri_mode_create.md | 2 +- openid-4-verifiable-presentations-1_0.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_create.md index 1c326099..277f8350 100644 --- a/diagrams/request_uri_mode_create.md +++ b/diagrams/request_uri_mode_create.md @@ -33,7 +33,7 @@ rp --> w: **signed (optionally encrypted) request object** (client_id, issuer_no 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 +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) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index d6c4ac09..d1160d0d 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -234,7 +234,7 @@ The Authorization Request follows the definition given in [@!RFC6749] taking int 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 an object containing only a subset of parameters needed to, in a subsequent step, request the creation of a request object from the Verifier through an 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]. +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. @@ -494,9 +494,9 @@ Other specifications can define further values for the `client_id_scheme` parame ## Request URI Method POST {#request_uri_method_post} -This request is offered at the Request URI endpoint by the Verifier. 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]. +This request is offered at the Request URI endpoint by the Verifier. 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]. -The request MUST use the POST method, the https scheme and the media type set to "application/oauth-authz-req+jwt". +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: From acd0c135d3cdcbb485286b0911cb1a17a5298f68 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 18 Jan 2024 10:49:17 +0900 Subject: [PATCH 25/91] added text on preceedence of request object claims over request claims or parameters --- 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 d1160d0d..f93d4579 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -262,9 +262,7 @@ 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` passed in the same request. This specification defines two values for this parameter: `GET` and `POST`. `GET` is -the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `POST` is a new mode defined in this specification where the Wallet requests the -creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_method_post). +: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` passed in the same request. This specification defines two values for this parameter: `GET` and `POST`. `GET` is the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `POST` is a new mode defined in this specification where the Wallet requests the creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_method_post). `request_uri_mode` MUST only be present if the request also contains a `request_uri` parameter. If the 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]). This parameter SHOULD be sent in a signed authorization request in order to allow the Wallet to authenticate the Verifier before it fetches the presentation request from the Verifier's request URI. @@ -519,6 +517,8 @@ The following parameters are defined: 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). +The Wallet MUST extract the set of authorization request parameters from the Request Object returned from the Verifier's request URI. The Wallet MUST only use the parameters in this Request Object, even if the same parameter was provided in an authorization request query parameter or a request object passed in the authorization request through the `request` parameter. The Client ID value in the `client_id` authorization request parameter (or `request` object claim) and in the Request Object 'client_id' claim MUST be identical. The Wallet then validates the request, as specified in OAuth 2.0 [RFC6749]. + ### Create Request Error Response TBD From 1101fda75f1f5c2603a5e2fdaa6d9ec5ccfa8b7c Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 18 Jan 2024 10:53:17 +0900 Subject: [PATCH 26/91] adjusted diagram name to parameter name --- diagrams/{request_uri_mode_create.md => request_uri_mode_post.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename diagrams/{request_uri_mode_create.md => request_uri_mode_post.md} (100%) diff --git a/diagrams/request_uri_mode_create.md b/diagrams/request_uri_mode_post.md similarity index 100% rename from diagrams/request_uri_mode_create.md rename to diagrams/request_uri_mode_post.md From c1ee35a52976620c7dfb5e367182761db41a85a7 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 18 Jan 2024 10:59:59 +0900 Subject: [PATCH 27/91] added internal processing at the verifier's response endpoint --- diagrams/request_uri_mode_post.md | 1 + 1 file changed, 1 insertion(+) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 277f8350..114f5abe 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -37,6 +37,7 @@ 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) From 357222c24135c6f75d53d26f64c1ef4bdcb1f9ca Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 18 Jan 2024 11:03:30 +0900 Subject: [PATCH 28/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Giuseppe De Marco --- 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 f93d4579..66e1db2b 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/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]. Additionally, the request can be an object containing only a subset of parameters needed to, in a subsequent step, request the creation of a request object from the Verifier through an HTTPS POST request via a newly introduced `create request endpoint`. +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 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]. From 0844acb11a7079736aac5f13f36fcbfc29b2dbe4 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 18 Jan 2024 11:13:54 +0900 Subject: [PATCH 29/91] fixed description of request_uri_method based on Giuseppe's feedback --- openid-4-verifiable-presentations-1_0.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index f93d4579..5067cd99 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -262,11 +262,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. `request_uri_method`: -: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` passed in the same request. This specification defines two values for this parameter: `GET` and `POST`. `GET` is the mode as defined by in [@RFC9101], where the Wallet sends a GET request to fetch a request object. `POST` is a new mode defined in this specification where the Wallet requests the creation of a fresh request object as defined in [@RFC9101] by sending a POST request to the request URI. The details of this request are defined in (#request_uri_method_post). -`request_uri_mode` MUST only be present if the request also contains a `request_uri` parameter. If the 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]). -This parameter SHOULD be sent in a signed authorization request in order to allow the Wallet to authenticate the Verifier before it fetches the presentation request from the Verifier's request URI. -This allows the Wallet to determine whether the Verifier is trustworthy before sending a request to its Request URI. +: 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]). +The `request_uri_method` parameter SHOULD be sent in a signed authorization request in order to allow the Wallet to authenticate the Verifier before it fetches the presentation request from the Verifier's request URI. This allows the Wallet to determine whether the Verifier is trustworthy prior to retrieving the presentation request from the Verifier's request URI. The following additional considerations are given for pre-existing Authorization Request parameters: @@ -301,7 +299,7 @@ The following is a non-normative example of a request object with a `request_uri "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "request_uri": "https://client.example.org/request", - "request_uri_mode": "create" + "request_uri_method": "post" } ``` From cfb2d36874616624e1b3968abbfd903b5dbfa30f Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 18 Jan 2024 11:16:23 +0900 Subject: [PATCH 30/91] changed text re signed authz request --- 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 9f1b41bf..abcbfc6c 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -264,7 +264,7 @@ A public key to be used by the Wallet as an input to the key agreement to encryp `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]). -The `request_uri_method` parameter SHOULD be sent in a signed authorization request in order to allow the Wallet to authenticate the Verifier before it fetches the presentation request from the Verifier's request URI. This allows the Wallet to determine whether the Verifier is trustworthy prior to retrieving the presentation request from the Verifier's request URI. +The `request_uri_method` parameter SHOULD be sent in a signed authorization request in order to allow the Wallet to authenticate the Verifier before it fetches the presentation request from the Verifier's request URI. This allows the Wallet to authenticate the Verifier (and establish trust in it) prior to retrieving the presentation request from the Verifier's request URI. The following additional considerations are given for pre-existing Authorization Request parameters: From 2c49b9b3cb4c557d180b39c282c73c0057cf349c Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 18 Jan 2024 11:19:33 +0900 Subject: [PATCH 31/91] fixed endpoint naming --- 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 abcbfc6c..3bec118c 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -511,13 +511,13 @@ The following parameters are defined: `w_ephm_key`: : OPTIONAL. A JWK object containing a key the Verifier MUST use to encrypt the request object. -### Create Request Response +### Request URI 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). +The Request URI 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). The Wallet MUST extract the set of authorization request parameters from the Request Object returned from the Verifier's request URI. The Wallet MUST only use the parameters in this Request Object, even if the same parameter was provided in an authorization request query parameter or a request object passed in the authorization request through the `request` parameter. The Client ID value in the `client_id` authorization request parameter (or `request` object claim) and in the Request Object 'client_id' claim MUST be identical. The Wallet then validates the request, as specified in OAuth 2.0 [RFC6749]. -### Create Request Error Response +### Request URI Error Response TBD From 21696fd31c984bf0214e4680f58b5b16650e860a Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 8 Feb 2024 17:21:55 +0100 Subject: [PATCH 32/91] Update diagrams/request_uri_mode_post.md Co-authored-by: Lukasz Jaromin --- diagrams/request_uri_mode_post.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 114f5abe..2968807c 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -25,7 +25,7 @@ u --> w: authorization request\n(client_id, request{request_uri, request_uri_mod activate w w --> w: check authorization request signature w --> w: check on trustworthiness of Verifier (approach on trust mechanism) -w --> rp: POST **request_uri** (\n[OPTIONALstate,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]issuer_nonce, \n[OPTIONAL]w_ephm_key) +w --> rp: POST **request_uri** (\n[OPTIONAL]state,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]issuer_nonce, \n[OPTIONAL]w_ephm_key) rp --> wm: [OPTIONAL] get wallet metadata wm --> rp: [OPTIONAL] wallet metadata rp -> rp: create and sign (and optionally encrypt) presentation request object (client_id, issuer_nonce, nonce, response_uri, \npresentation_definition, state) From 2f08615b6d5dbfc0cf9ef84f39fd0423a906aabc Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Sat, 9 Mar 2024 15:16:26 +0100 Subject: [PATCH 33/91] reworked the PR to reflect recent WG discussions --- diagrams/request_uri_mode_post.md | 15 ++--- openid-4-verifiable-presentations-1_0.md | 81 ++++++++++++++---------- 2 files changed, 52 insertions(+), 44 deletions(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 2968807c..23a5e2fb 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -19,18 +19,13 @@ end box u --> r : use activate r -r --> u: authorization request\n(client_id, request{request_uri, request_uri_mode=POST, state}) +r --> u: authorization request\n(client_id, request_uri, request_uri_mode=POST) deactivate r -u --> w: authorization request\n(client_id, request{request_uri, request_uri_mode=POST, state}) +u --> w: authorization request\n(client_id, request_uri, request_uri_mode=POST) activate w -w --> w: check authorization request signature -w --> w: check on trustworthiness of Verifier (approach on trust mechanism) -w --> rp: POST **request_uri** (\n[OPTIONAL]state,\n[OPTIONAL]issuer, \n[OPTIONAL]wallet_metadata, \n[OPTIONAL]issuer_nonce, \n[OPTIONAL]w_ephm_key) -rp --> wm: [OPTIONAL] get wallet metadata -wm --> rp: [OPTIONAL] wallet metadata -rp -> rp: create and sign (and optionally encrypt) presentation request object (client_id, issuer_nonce, nonce, response_uri, \npresentation_definition, state) -rp --> w: **signed (optionally encrypted) request object** (client_id, issuer_nonce, nonce, response_uri, \npresentation_definition, state) -note over u, w: do we want to allow unsigned presentation request objects, too? +w --> rp: POST **request_uri** (\n[OPTIONAL]issuer_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 diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 3bec118c..1cd2b835 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -263,8 +263,9 @@ A public key to be used by the Wallet as an input to the key agreement to encryp `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]). -The `request_uri_method` parameter SHOULD be sent in a signed authorization request in order to allow the Wallet to authenticate the Verifier before it fetches the presentation request from the Verifier's request URI. This allows the Wallet to authenticate the Verifier (and establish trust in it) prior to retrieving the presentation request from the Verifier's request URI. +`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` `post`, it SHOULD add the `client_metadata` parameter to the authorization request and use it to pass its capabilities. This allows the Wallet to determine the intersection of capabilities between Verifier and Wallet and sent only these in the `wallet_metadata` request parameter of the Request URI POST request. If the Verifier will add a `client_id_scheme` to the Request Object, it MUST also add the same `client_id_scheme` to the Authorization Request. The following additional considerations are given for pre-existing Authorization Request parameters: @@ -288,27 +289,15 @@ 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 `request_uri_mode`: - -``` -{ - "iss": "https://client.example.org", - "aud": "https://server.example.com", - "iat": 1541493724, - "exp": 1516247022, - "state": "af0ifjsldkj", - "nonce": "n-0S6_WzA2Mj", - "request_uri": "https://client.example.org/request", - "request_uri_method": "post" -} -``` - -It is sent to the Wallet using the `request` parameter as defined in [@RFC9101] as shown in the following example. +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=https://client.example.org - &request=... HTTP/1.1 + 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} @@ -490,36 +479,50 @@ Other specifications can define further values for the `client_id_scheme` parame ## Request URI Method POST {#request_uri_method_post} -This request is offered at the Request URI endpoint by the Verifier. 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]. +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: -`state`: -: OPTIONAL. A JSON String containing the value of the corresponding authorization Request's `state` parameter, if present. - -`issuer`: -: OPTIONAL. A JSON containing an HTTPS URL designating the Issuer URL of the Wallet (acting as a OAuth 2.0 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_metadata`parameter`. - `wallet_metadata`: -: OPTIONAL. A JSON Object containing metadata parameters as defined in (#as_metadata_parameters). +: OPTIONAL. A JSON Object containing metadata parameters as defined in (#as_metadata_parameters). -`issuer_nonce`: +`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. -`w_ephm_key`: -: OPTIONAL. A JWK object containing a key the Verifier MUST use to encrypt the 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 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). +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 Wallet MUST extract the set of authorization request parameters from the Request Object returned from the Verifier's request URI. The Wallet MUST only use the parameters in this Request Object, even if the same parameter was provided in an authorization request query parameter or a request object passed in the authorization request through the `request` parameter. The Client ID value in the `client_id` authorization request parameter (or `request` object claim) and in the Request Object 'client_id' claim MUST be identical. The Wallet then validates the request, as specified in OAuth 2.0 [RFC6749]. +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 -TBD +If the Verifier responds with any HTTP error response, the Wallet MUST terminate the process. # Response {#response} @@ -1149,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} @@ -1736,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 From 9a021bb7521a40270a57ec0d3d899fb0260eac3a Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 11:50:46 +0100 Subject: [PATCH 34/91] Apply suggestions from code review apply suggestions from peppelinux Co-authored-by: Giuseppe De Marco --- diagrams/request_uri_mode_post.md | 6 +++--- openid-4-verifiable-presentations-1_0.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 23a5e2fb..18b782fb 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -19,11 +19,11 @@ end box u --> r : use activate r -r --> u: authorization request\n(client_id, request_uri, request_uri_mode=POST) +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) +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]issuer_metadata, \n[OPTIONAL]wallet_nonce) +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 diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 1cd2b835..7f51a3d5 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -265,7 +265,7 @@ A public key to be used by the Wallet as an input to the key agreement to encryp : 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` `post`, it SHOULD add the `client_metadata` parameter to the authorization request and use it to pass its capabilities. This allows the Wallet to determine the intersection of capabilities between Verifier and Wallet and sent only these in the `wallet_metadata` request parameter of the Request URI POST request. If the Verifier will add a `client_id_scheme` to the Request Object, it MUST also add the same `client_id_scheme` to the Authorization Request. +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: @@ -289,7 +289,7 @@ 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` : +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? @@ -1156,7 +1156,7 @@ Whenever TLS is used, a TLS server certificate check MUST be performed, per [@!R ## 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. +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} From 8719239f7e7f21e969e671a9d3aba17380df69eb Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 17:47:06 +0100 Subject: [PATCH 35/91] Apply suggestions from code review Co-authored-by: Daniel Fett --- diagrams/request_uri_mode_post.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 18b782fb..c509d960 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -19,13 +19,13 @@ end box u --> r : use activate r -r --> u: authorization request\n(client_id, request_uri, request_uri_mode=POST, [client_id_scheme]) +r --> u: authorization request\n(client_id, request_uri, request_uri_method=POST, [client_id_scheme]) deactivate r -u --> w: authorization request\n(client_id, request_uri, request_uri_mode=POST, [client_id_scheme]) +u --> w: authorization request\n(client_id, request_uri, request_uri_method=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) +rp --> w: **signed (optionally encrypted) request object** (client_id, client_id_scheme, wallet_nonce, nonce, \nresponse_uri, presentation_definition, state) w -> w: authenticate and\n authorize Verifier note over u, w: User authentication and Credential selection/confirmation From e7b88717438100b74ee6cf823692252747e9697d Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 17:48:03 +0100 Subject: [PATCH 36/91] reverted 3rd paragraph in Authz Request section --- 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 7f51a3d5..39839a66 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -234,7 +234,7 @@ The Authorization Request follows the definition given in [@!RFC6749] taking int 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 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 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 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. From 9d78904398d81bacbfe88497d5a0d018ae1dd13b Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 17:57:57 +0100 Subject: [PATCH 37/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- openid-4-verifiable-presentations-1_0.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 39839a66..f6f120f0 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -232,7 +232,14 @@ 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 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 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 Wallet may want to provide to the Verifier details about its technical capabilities to +allow the Verifier to generate a request that matches technical capabilities of that Wallet. +To enable this, the first Authorization Request can contain `request_uri_method` parameter with the value `post` +that signals to the Wallet that it can make an HTTP POST to the Verifier's `request_uri` +endpoint with the information about its capabilities. The Wallet MAY continue with JAR +when it receives `request_uri_method` parameter with the value `post` but does not support this new 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]. From 0e58e39d424004b907e3be8c540ecb6aae7bf7e9 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 17:58:17 +0100 Subject: [PATCH 38/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 f6f120f0..ebe19d9f 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -269,7 +269,7 @@ 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). +: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two case-insensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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. From af6c5720ee7fec8a1ce77c79e9f286944f5a4c42 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:02:30 +0100 Subject: [PATCH 39/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 ebe19d9f..5d24d3c9 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -296,7 +296,7 @@ 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`): +The following is a non-normative example with a `request_uri_method` parameter (including the additional parameters `client_id_scheme` and `client_metadata`): ``` GET /authorize? From 02a58d05ac7fe5d693fe6f2e14c6464220f2fabe Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:04:15 +0100 Subject: [PATCH 40/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 5d24d3c9..1934e18d 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -304,7 +304,7 @@ The following is a non-normative example with a `request_uri_method` parameter ( &client_id_scheme=x509_san_dns &client_metadata=... &request_uri=https%3A%2F%2Fclient.example.org%2Frequest - &request_uri_mode=post HTTP/1.1 + &request_uri_method=post HTTP/1.1 ``` ## `presentation_definition` Parameter {#request_presentation_definition} From 76098d7fdb04117840ba125aed1d4415ca09f4a7 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:11:02 +0100 Subject: [PATCH 41/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 1934e18d..78feff86 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -486,7 +486,7 @@ Other specifications can define further values for the `client_id_scheme` parame ## Request URI Method POST {#request_uri_method_post} -This request is offered at the Request URI endpoint by the Verifier. +This request is handled by the Request URI endpoint of 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". From 8666529133cca294d0835ec2124579d54dda2962 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:24:28 +0100 Subject: [PATCH 42/91] simplified diagram --- diagrams/request_uri_mode_post.md | 26 +++++++++----------------- 1 file changed, 9 insertions(+), 17 deletions(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index c509d960..2f6126e2 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -3,18 +3,11 @@ autonumber -box "Wallet" -participant "Metadata" as wm -participant "Authorization Endpoint" as w -end box +participant "Wallet" as w participant "User Agent" as u -box "Verifier" -participant "Frontend" as r -participant "Request Endpoint" as rp -participant "Response Endpoint" as rb -end box +participant "Verifier" as r u --> r : use activate r @@ -23,22 +16,21 @@ r --> u: authorization request\n(client_id, request_uri, request_uri_method=POST deactivate r u --> w: authorization request\n(client_id, request_uri, request_uri_method=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, wallet_nonce, nonce, \nresponse_uri, presentation_definition, state) +w --> r: POST **request_uri** (\n[OPTIONAL]wallet_metadata, \n[OPTIONAL]wallet_nonce) +r -> r: create and sign (and optionally encrypt) request object +r --> w: **signed (optionally encrypted) request object** (client_id, client_id_scheme, wallet_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 --> r: POST response \n(vp_token(credential presentation(s) associated with nonce), presentation_submission, state) +r -> r: check state, store vp_token\n & create redirect_url +r --> 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: presentation response r -> r: validate presentation \n(incl. nonce binding) r -> r: use presented credential @enduml From 396f0078cc18ab3e9f3a63707b54cab3b0209640 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:24:39 +0100 Subject: [PATCH 43/91] added processing requirements --- openid-4-verifiable-presentations-1_0.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 39839a66..b09827b5 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -516,7 +516,7 @@ The Wallet MUST process the request process as defined in [@RFC9101]. Additional 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 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. If any of these conditions is not met, the Wallet MUST terminate request processing. The Wallet then validates the request, as specified in OAuth 2.0 [RFC6749]. @@ -751,6 +751,11 @@ This document also defines the following additional error codes and error descri - The Presentation Definition URL can be reached, but the specified `presentation_definition` cannot be found at the URL. +`invalid_request_uri_mode`: + +- The value of the `request_uri_mode` request parameter is neither `get` nor `post`. + + ## VP Token Validation Verifiers MUST validate the VP Token in the following manner: From d9a49d954d0b3b893aa939e8cd651340b1565393 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:33:07 +0100 Subject: [PATCH 44/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 b33b5df7..7c5e3926 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -515,7 +515,7 @@ The following is a non-normative example of a request object: "response_mode": "direct_post", "presentation_definition": {...}, "nonce": "n-0S6_WzA2Mj", - "state" : "eyJhb...6-sVA + "state" : "eyJhb...6-sVA" } ``` From 63d1f7ff98c070e643ca2b5843d55b887c67c4e3 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:33:15 +0100 Subject: [PATCH 45/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 7c5e3926..a529dd18 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -519,7 +519,7 @@ The following is a non-normative example of a request object: } ``` -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 Wallet MUST process the request 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). From 6edd8d1a3d80c4bc8c478008689b258f1920b958 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:34:19 +0100 Subject: [PATCH 46/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Giuseppe De Marco --- 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 a529dd18..0bb57b61 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1168,7 +1168,7 @@ Whenever TLS is used, a TLS server certificate check MUST be performed, per [@!R ## 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. +The Wallet MUST NOT send 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} From e8a6cde853dc300e216f66cf16559c222492bd4a Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:34:28 +0100 Subject: [PATCH 47/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 0bb57b61..f8c95cdc 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -525,7 +525,7 @@ The request object MUST fulfill the requirements as defined in (#vp_token_reques 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. If any of these conditions is not met, the Wallet MUST terminate request processing. -The Wallet then validates the request, as specified in OAuth 2.0 [RFC6749]. +The Wallet then validates the request as specified in OAuth 2.0 [@RFC6749]. ### Request URI Error Response From e1276ec43e7b7de4fa5849a5f79fd79c5267ae28 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 11 Mar 2024 18:35:29 +0100 Subject: [PATCH 48/91] fixed media types --- 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 b33b5df7..af88db11 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -488,15 +488,15 @@ Other specifications can define further values for the `client_id_scheme` parame This request is handled by the Request URI endpoint of 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 request MUST use the HTTP POST method with the https scheme the content type "application/x-www-form-urlencoded" and the accept header 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). +: OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. `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. +: OPTIONAL. A 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. From c4d175b8e1344f3f59d077b968575ee268c71a97 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:16:23 +0100 Subject: [PATCH 49/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> --- openid-4-verifiable-presentations-1_0.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 446a70a1..1188d03f 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -235,10 +235,10 @@ The Authorization Request follows the definition given in [@!RFC6749] taking int 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 Wallet may want to provide to the Verifier details about its technical capabilities to -allow the Verifier to generate a request that matches technical capabilities of that Wallet. -To enable this, the first Authorization Request can contain `request_uri_method` parameter with the value `post` -that signals to the Wallet that it can make an HTTP POST to the Verifier's `request_uri` -endpoint with the information about its capabilities. The Wallet MAY continue with JAR +allow the Verifier to generate a request that matches the technical capabilities of that Wallet. +To enable this, the first Authorization Request can contain a `request_uri_method` parameter with the value `post` +that signals to the Wallet that it can make an HTTP POST request to the Verifier's `request_uri` +endpoint with information about its capabilities. The Wallet MAY continue with JAR when it receives `request_uri_method` parameter with the value `post` but does not support this new 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]. From 3b0a9fba5112ed3d6f366c4b316fb173a33cd274 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:16:42 +0100 Subject: [PATCH 50/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Andrii Deinega --- 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 1188d03f..fe89d656 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -269,7 +269,7 @@ 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 case-insensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as detailed in (#request_uri_method_post). +: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two case-insensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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. From df5d0f17bab4aea41212cb44f557aeaccc1d95d9 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:16:55 +0100 Subject: [PATCH 51/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Andrii Deinega --- 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 fe89d656..9a6e3b1d 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -488,7 +488,7 @@ Other specifications can define further values for the `client_id_scheme` parame This request is handled by the Request URI endpoint of the Verifier. -The request MUST use the HTTP POST method with the https scheme the content type "application/x-www-form-urlencoded" and the accept header set to "application/oauth-authz-req+jwt". +The request MUST use the HTTP POST method with the https scheme, and the content type "application/x-www-form-urlencoded" and the accept header set to "application/oauth-authz-req+jwt". The following parameters are defined: From f4e4236cbd06ec5556cc6bc5e3fcf600f594cd62 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:17:37 +0100 Subject: [PATCH 52/91] removed "new" --- 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 9a6e3b1d..23553551 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -239,7 +239,7 @@ allow the Verifier to generate a request that matches the technical capabilities To enable this, the first Authorization Request can contain a `request_uri_method` parameter with the value `post` that signals to the Wallet that it can make an HTTP POST request to the Verifier's `request_uri` endpoint with information about its capabilities. The Wallet MAY continue with JAR -when it receives `request_uri_method` parameter with the value `post` but does not support this new feature. +when it receives `request_uri_method` parameter with the value `post` but does not 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]. From ac1ffc0a67af5b239f2377c14ba7016d352a4152 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:21:59 +0100 Subject: [PATCH 53/91] fixed wallet_metadata --- 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 23553551..bd5e7d78 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -493,10 +493,10 @@ The request MUST use the HTTP POST method with the https scheme, and the content The following parameters are defined: `wallet_metadata`: -: OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. +: OPTIONAL. OPTIONAL. A String containing a JSON Object containing metadata parameters as defined in (#as_metadata_parameters). `wallet_nonce`: -: OPTIONAL. A String containing as fresh, cryptographically random number with sufficient entropy the Verifier MUST use when creating the signed presentation request object. +: OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. 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. From 803cbe644492ea0cdd9c298ceef3512498a9c455 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:22:55 +0100 Subject: [PATCH 54/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> --- 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 bd5e7d78..2bf865d1 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -498,7 +498,7 @@ The following parameters are defined: `wallet_nonce`: : OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. -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. +If the Wallet wants the Verifier to encrypt the request object, it SHOULD use the `jwks` or `jwks_uri` parameter 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 From 95ac037fe2a5791b47e267acfac25620710a8bdd Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:30:23 +0100 Subject: [PATCH 55/91] added request_uri POST example --- openid-4-verifiable-presentations-1_0.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index bd5e7d78..8074785f 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -500,6 +500,19 @@ The following parameters are defined: 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. +The following is a non-normative example of a request: + +``` + POST /request HTTP/1.1 + Host: client.example.org + Content-Type: application/x-www-form-urlencoded + + wallet_metadata=%7B%22vp_formats_supported%22%3A%7B%22jwt_vc_json%22%3A%7B%22alg_values_supported + %22%3A%5B%22ES256K%22%2C%22ES384%22%5D%7D%2C%22jwt_vp_json%22%3A%7B%22alg_values_supported%22%3A% + 5B%22ES256K%22%2C%22EdDSA%22%5D%7D%7D%7D& + wallet_nonce=qPmxiNFCR3QTm19POc8u +``` + ### 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]. From 148e1bd1da1638eb67b81a75f494e3d4bf4b5768 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:30:55 +0100 Subject: [PATCH 56/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Joseph Heenan --- 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 5b715d2e..90bcfd49 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -515,7 +515,7 @@ The following is a non-normative example of a request: ### 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 Request URI response MUST be an HTTP response with the content type "application/oauth-authz-req+jwt" and the body being a signed, optionally encrypted, request object as defined in [@RFC9101]. The following is a non-normative example of a request object: From ae654532cc5ed4587973934450a27999763138ec Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:33:02 +0100 Subject: [PATCH 57/91] Apply suggestions from code review Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> --- 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 90bcfd49..42b05e36 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -532,11 +532,11 @@ The following is a non-normative example of a request object: } ``` -The Wallet MUST process the request 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 Wallet MUST process the request 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` claim. 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. If any of these conditions is not met, the Wallet MUST terminate request processing. +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. If any of these conditions is not met, the Wallet MUST terminate request processing. The Wallet then validates the request as specified in OAuth 2.0 [@RFC6749]. From e3df8ac8012fb376d9c413a6ddf6d90cef200a8a Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 11:34:36 +0100 Subject: [PATCH 58/91] moved requirement for request object up and fixed grammar nit --- openid-4-verifiable-presentations-1_0.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 42b05e36..a0ce833a 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -488,7 +488,7 @@ Other specifications can define further values for the `client_id_scheme` parame This request is handled by the Request URI endpoint of the Verifier. -The request MUST use the HTTP POST method with the https scheme, and the content type "application/x-www-form-urlencoded" and the accept header set to "application/oauth-authz-req+jwt". +The request MUST use the HTTP POST method with the https scheme, and the content type "application/x-www-form-urlencoded" and the accept header set to "application/oauth-authz-req+jwt". The following parameters are defined: @@ -515,7 +515,7 @@ The following is a non-normative example of a request: ### Request URI Response -The Request URI response MUST be an HTTP response with the content type "application/oauth-authz-req+jwt" and the body being a signed, optionally encrypted, request object as defined in [@RFC9101]. +The Request URI response MUST be an HTTP response with the content type "application/oauth-authz-req+jwt" and the body being a signed, optionally encrypted, request object as defined in [@RFC9101]. The request object MUST fulfill the requirements as defined in (#vp_token_request). The following is a non-normative example of a request object: @@ -534,9 +534,7 @@ The following is a non-normative example of a request object: The Wallet MUST process the request 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` claim. 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. If any of these conditions is not met, the Wallet MUST terminate request processing. +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. If any of these conditions are not met, the Wallet MUST terminate request processing. The Wallet then validates the request as specified in OAuth 2.0 [@RFC6749]. From 0c9413d91249e8cf573beeeaf4bbf0e6f8a7ea21 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 17:03:30 +0100 Subject: [PATCH 59/91] Apply suggestions from code review Co-authored-by: Oliver Terbu --- diagrams/request_uri_mode_post.md | 17 +++++++++-------- openid-4-verifiable-presentations-1_0.md | 5 +++-- 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 2f6126e2..7341b2ed 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -12,9 +12,9 @@ participant "Verifier" as r u --> r : use activate r -r --> u: authorization request\n(client_id, request_uri, request_uri_method=POST, [client_id_scheme]) +r --> u: authorization request\n(client_id, request_uri, request_uri_method=post, [client_id_scheme]) deactivate r -u --> w: authorization request\n(client_id, request_uri, request_uri_method=POST, [client_id_scheme]) +u --> w: authorization request\n(client_id, request_uri, request_uri_method=post, [client_id_scheme]) activate w w --> r: POST **request_uri** (\n[OPTIONAL]wallet_metadata, \n[OPTIONAL]wallet_nonce) r -> r: create and sign (and optionally encrypt) request object @@ -23,14 +23,15 @@ w -> w: authenticate and\n authorize Verifier note over u, w: User authentication and Credential selection/confirmation -w -> w: create verifiable\npresentation (credential) -w --> r: POST response \n(vp_token(credential presentation(s) associated with nonce), presentation_submission, state) -r -> r: check state, store vp_token\n & create redirect_url -r --> w: redirect_url -w --> u: redirect (response_code) -u --> r: redirect (response_code) +w -> w: create credential presentation(s) associated with nonce +w --> r: POST response \n(vp_token(credential presentation(s)), presentation_submission, state) +r -> r: check state, store vp_token\n & create redirect_uri with response_code +r --> w: redirect_uri +w --> u: redirect (redirect_uri) +u --> r: redirect (redirect_uri) activate r r --> r: presentation response +r -> r: validate response \n(incl. response_code) r -> r: validate presentation \n(incl. nonce binding) r -> r: use presented credential @enduml diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index a0ce833a..82154148 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -528,13 +528,14 @@ The following is a non-normative example of a request object: "response_mode": "direct_post", "presentation_definition": {...}, "nonce": "n-0S6_WzA2Mj", + "wallet_nonce": "qPmxiNFCR3QTm19POc8u", "state" : "eyJhb...6-sVA" } ``` The Wallet MUST process the request 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` claim. If it does not, the Wallet MUST terminate request processing. -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. If any of these conditions are not met, the Wallet MUST terminate request processing. +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 Identifier value in the `client_id` Authorization Request parameter and the Request Object 'client_id' claim value MUST be identical. If the Authorization Request contains a `client_id_scheme` parameter, the `client_id_scheme` Authorization Request parameter and the Request Object `client_id_scheme` claim value MUST be identical. If any of these conditions are not met, the Wallet MUST terminate request processing. The Wallet then validates the request as specified in OAuth 2.0 [@RFC6749]. @@ -771,7 +772,7 @@ This document also defines the following additional error codes and error descri `invalid_request_uri_mode`: -- The value of the `request_uri_mode` request parameter is neither `get` nor `post`. +- The value of the `request_uri_method` request parameter is neither `get` nor `post`. ## VP Token Validation From 91f811f1fa3d2a41662cef05101f36990851e095 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 21:05:53 +0100 Subject: [PATCH 60/91] Apply suggestions from code review Co-authored-by: Joseph Heenan --- 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 82154148..f11ba573 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -303,7 +303,7 @@ The following is a non-normative example with a `request_uri_method` parameter ( client_id=client.example.org &client_id_scheme=x509_san_dns &client_metadata=... - &request_uri=https%3A%2F%2Fclient.example.org%2Frequest + &request_uri=https%3A%2F%2Fclient.example.org%2Frequest%2Fvapof4ql2i7m41m68uep &request_uri_method=post HTTP/1.1 ``` From 56ef646be17e5083fc323fc9763b8a59829a7ba1 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Tue, 12 Mar 2024 21:06:26 +0100 Subject: [PATCH 61/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Andrii Deinega --- 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 f11ba573..9884d4aa 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -270,7 +270,7 @@ A public key to be used by the Wallet as an input to the key agreement to encryp `request_uri_method`: : OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two case-insensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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]). +`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 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. From a21eba385a18b147fffe45d85f5d318e7027a637 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 12:48:39 +0100 Subject: [PATCH 62/91] changed text on client_metadata and added case-sensitive to error text --- openid-4-verifiable-presentations-1_0.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 9884d4aa..5e3548ce 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -272,7 +272,8 @@ A public key to be used by the Wallet as an input to the key agreement to encryp : OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two case-insensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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 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. +If the Verifier uses the `request_uri_method` set to `post`, it SHOULD add the `client_metadata` parameter to the authorization request, if there is no other means to convey its capabilities to the Wallet. +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: @@ -772,7 +773,7 @@ This document also defines the following additional error codes and error descri `invalid_request_uri_mode`: -- The value of the `request_uri_method` request parameter is neither `get` nor `post`. +- The value of the `request_uri_method` request parameter is neither `get` nor `post` (case-sensitive). ## VP Token Validation From efd07221298a5f70112d3d21a59024217ab382a7 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 12:57:24 +0100 Subject: [PATCH 63/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Andrii Deinega --- 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 5e3548ce..99e6fd17 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -536,7 +536,7 @@ The following is a non-normative example of a request object: The Wallet MUST process the request 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` claim. If it does not, the Wallet MUST terminate request processing. -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 Identifier value in the `client_id` Authorization Request parameter and the Request Object 'client_id' claim value MUST be identical. If the Authorization Request contains a `client_id_scheme` parameter, the `client_id_scheme` Authorization Request parameter and the Request Object `client_id_scheme` claim value MUST be identical. If any of these conditions are not met, the Wallet MUST terminate request processing. +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 Identifier value in the `client_id` Authorization Request parameter and the Request Object `client_id` claim value MUST be identical. If the Authorization Request contains a `client_id_scheme` parameter, the `client_id_scheme` Authorization Request parameter and the Request Object `client_id_scheme` claim value MUST be identical. If any of these conditions are not met, the Wallet MUST terminate request processing. The Wallet then validates the request as specified in OAuth 2.0 [@RFC6749]. From 4ea299d1d87fc7c5f76ba1f2e1021e049b86a831 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 12:58:11 +0100 Subject: [PATCH 64/91] fixed history --- 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 99e6fd17..e8745903 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1772,7 +1772,7 @@ The technology described in this specification was made available from contribut -21 - * added POST request mode for Request URI + * added POST request method for Request URI -20 From 3208b16128fe02f361bd7cf9df205d9204928565 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 14:29:56 +0100 Subject: [PATCH 65/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 e8745903..8d7f3530 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -489,7 +489,7 @@ Other specifications can define further values for the `client_id_scheme` parame This request is handled by the Request URI endpoint of the Verifier. -The request MUST use the HTTP POST method with the https scheme, and the content type "application/x-www-form-urlencoded" and the accept header set to "application/oauth-authz-req+jwt". +The request MUST use the HTTP POST method with the https scheme, and the content type `application/x-www-form-urlencoded` and the accept header set to `application/oauth-authz-req+jwt`. The following parameters are defined: From 55a4fafb33fc68949c4afcb1e69f99e999078d36 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 14:30:13 +0100 Subject: [PATCH 66/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 8d7f3530..460e2782 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -494,7 +494,7 @@ The request MUST use the HTTP POST method with the https scheme, and the content The following parameters are defined: `wallet_metadata`: -: OPTIONAL. OPTIONAL. A String containing a JSON Object containing metadata parameters as defined in (#as_metadata_parameters). +: OPTIONAL. OPTIONAL. A String containing a JSON-encoded object containing metadata parameters as defined in (#as_metadata_parameters). `wallet_nonce`: : OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. From 5a0b1af14bee49e99e8b7e95e6cf6b7754fe30e1 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 15:38:16 +0100 Subject: [PATCH 67/91] extended privacy considerations --- openid-4-verifiable-presentations-1_0.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index e8745903..f2e33824 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -236,7 +236,7 @@ The Verifier MAY send an Authorization Request as a Request Object either by val The Wallet may want to provide to the Verifier details about its technical capabilities to allow the Verifier to generate a request that matches the technical capabilities of that Wallet. -To enable this, the first Authorization Request can contain a `request_uri_method` parameter with the value `post` +To enable this, the Authorization Request can contain a `request_uri_method` parameter with the value `post` that signals to the Wallet that it can make an HTTP POST request to the Verifier's `request_uri` endpoint with information about its capabilities. The Wallet MAY continue with JAR when it receives `request_uri_method` parameter with the value `post` but does not support this feature. @@ -1181,7 +1181,11 @@ Whenever TLS is used, a TLS server certificate check MUST be performed, per [@!R ## Authorization Requests with Request URI -The Wallet MUST NOT send personally identifiable information (PII) or any other data that could be used for fingerprinting to the Request URI in order to prevent user tracking. +If no user interaction is required before sending the request, it is easy to request on a large scale and in an automated fashion (e.g.) the wallet capabilities from all visitors of a website. Even without PII this can reveal some information about users, like their nationality (e.g., a Wallet with special capabilities only used in one EU member state). + +Mandatory 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 revealing libraries used or their versions. The Wallet MUST NOT send 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} From 286bf6700b63ac04d9b1a5325d34e6354c8f03bc Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 15:40:39 +0100 Subject: [PATCH 68/91] Update diagrams/request_uri_mode_post.md Co-authored-by: Daniel Fett --- diagrams/request_uri_mode_post.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 7341b2ed..7ccb071e 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -16,7 +16,7 @@ r --> u: authorization request\n(client_id, request_uri, request_uri_method=post deactivate r u --> w: authorization request\n(client_id, request_uri, request_uri_method=post, [client_id_scheme]) activate w -w --> r: POST **request_uri** (\n[OPTIONAL]wallet_metadata, \n[OPTIONAL]wallet_nonce) +w --> r: POST **request_uri** ([wallet_metadata][, wallet_nonce]) r -> r: create and sign (and optionally encrypt) request object r --> w: **signed (optionally encrypted) request object** (client_id, client_id_scheme, wallet_nonce, nonce, \nresponse_uri, presentation_definition, state) w -> w: authenticate and\n authorize Verifier From 3c298b70e4b1ad3159aa5db2096e26518feae7f1 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 15:40:52 +0100 Subject: [PATCH 69/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Oliver Terbu --- 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 9fc56007..48d19416 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -272,7 +272,7 @@ A public key to be used by the Wallet as an input to the key agreement to encryp : OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two case-insensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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 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, if there is no other means to convey its capabilities to the Wallet. +If the Verifier uses the `request_uri_method` set to `post`, it SHOULD add the `client_metadata` parameter to the Authorization Request, if there is no other means to convey its capabilities to the Wallet. 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: From 4540ccaa55b9d4a6b20ac36a88f9b42c6ce7533e Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 15:49:41 +0100 Subject: [PATCH 70/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Oliver Terbu --- 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 48d19416..699742cb 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -499,7 +499,7 @@ The following parameters are defined: `wallet_nonce`: : OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. -If the Wallet wants the Verifier to encrypt the request object, it SHOULD use the `jwks` or `jwks_uri` parameter 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. +If the Wallet requires the Verifier to encrypt the Request Object, it SHOULD use the `jwks` or `jwks_uri` parameter 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. If the Wallet requires an encrypted Authorization Response, it SHOULD specify supported encryption algorithms using the `authorization_encryption_alg_values_supported` and `authorization_encryption_enc_values_supported` parameters. Additionally, if the `client_id_scheme` value permits JWS Request Objects, the Wallet SHOULD list supported cryptographic algorithms for securing the Request Object through the `request_object_signing_alg_values_supported` parameter. Conversely, the Wallet MUST NOT include this parameter if the `client_id_scheme` precludes JWS Request Objects. The following is a non-normative example of a request: From e5add86f7265db8f67f27fa559dac1ca20886d33 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 15:51:45 +0100 Subject: [PATCH 71/91] formatted Oliver's contribution --- openid-4-verifiable-presentations-1_0.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 699742cb..d8a20b18 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -499,7 +499,9 @@ The following parameters are defined: `wallet_nonce`: : OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. -If the Wallet requires the Verifier to encrypt the Request Object, it SHOULD use the `jwks` or `jwks_uri` parameter 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. If the Wallet requires an encrypted Authorization Response, it SHOULD specify supported encryption algorithms using the `authorization_encryption_alg_values_supported` and `authorization_encryption_enc_values_supported` parameters. Additionally, if the `client_id_scheme` value permits JWS Request Objects, the Wallet SHOULD list supported cryptographic algorithms for securing the Request Object through the `request_object_signing_alg_values_supported` parameter. Conversely, the Wallet MUST NOT include this parameter if the `client_id_scheme` precludes JWS Request Objects. +If the Wallet requires the Verifier to encrypt the Request Object, it SHOULD use the `jwks` or `jwks_uri` parameter 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. If the Wallet requires an encrypted Authorization Response, it SHOULD specify supported encryption algorithms using the `authorization_encryption_alg_values_supported` and `authorization_encryption_enc_values_supported` parameters. + +Additionally, if the `client_id_scheme` value permits JWS Request Objects, the Wallet SHOULD list supported cryptographic algorithms for securing the Request Object through the `request_object_signing_alg_values_supported` parameter. Conversely, the Wallet MUST NOT include this parameter if the `client_id_scheme` precludes JWS Request Objects. The following is a non-normative example of a request: From 06aef10898a28dcaf958bd3ecc7170d062f68343 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 15:52:33 +0100 Subject: [PATCH 72/91] Apply suggestions from code review Co-authored-by: Daniel Fett --- openid-4-verifiable-presentations-1_0.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index d8a20b18..0865794b 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -507,8 +507,8 @@ The following is a non-normative example of a request: ``` POST /request HTTP/1.1 - Host: client.example.org - Content-Type: application/x-www-form-urlencoded + Host: client.example.org + Content-Type: application/x-www-form-urlencoded wallet_metadata=%7B%22vp_formats_supported%22%3A%7B%22jwt_vc_json%22%3A%7B%22alg_values_supported %22%3A%5B%22ES256K%22%2C%22ES384%22%5D%7D%2C%22jwt_vp_json%22%3A%7B%22alg_values_supported%22%3A% @@ -1183,11 +1183,11 @@ Whenever TLS is used, a TLS server certificate check MUST be performed, per [@!R ## Authorization Requests with Request URI -If no user interaction is required before sending the request, it is easy to request on a large scale and in an automated fashion (e.g.) the wallet capabilities from all visitors of a website. Even without PII this can reveal some information about users, like their nationality (e.g., a Wallet with special capabilities only used in one EU member state). +If no user interaction is required before sending the request, it is easy to request on a large scale and in an automated fashion (e.g.) the wallet capabilities from all visitors of a website. Even without personally identifiable information (PII) this can reveal some information about users, like their nationality (e.g., a Wallet with special capabilities only used in one EU member state). Mandatory 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 revealing libraries used or their versions. The Wallet MUST NOT send personally identifiable information (PII) or any other data that could be used for fingerprinting to the Request URI in order to prevent 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 user tracking. {backmatter} From e437b508dd9ec65510d227c03113692eb798cb28 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 16:45:36 +0100 Subject: [PATCH 73/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> --- 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 0865794b..6dca1941 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -494,7 +494,7 @@ The request MUST use the HTTP POST method with the https scheme, and the content The following parameters are defined: `wallet_metadata`: -: OPTIONAL. OPTIONAL. A String containing a JSON-encoded object containing metadata parameters as defined in (#as_metadata_parameters). +: OPTIONAL. A String containing a JSON-encoded object containing metadata parameters as defined in (#as_metadata_parameters). `wallet_nonce`: : OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. From 4140e35cc036de14e1d2212ff36c7e2419d11e7d Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 16:46:09 +0100 Subject: [PATCH 74/91] Apply suggestions from code review Co-authored-by: Daniel Fett --- 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 6dca1941..97bb9513 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -773,7 +773,7 @@ This document also defines the following additional error codes and error descri - The Presentation Definition URL can be reached, but the specified `presentation_definition` cannot be found at the URL. -`invalid_request_uri_mode`: +`invalid_request_uri_method`: - The value of the `request_uri_method` request parameter is neither `get` nor `post` (case-sensitive). From 1e033f7fd393fcbcd8e8e32c7aeb093acda4c1d4 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 14 Mar 2024 17:02:43 +0100 Subject: [PATCH 75/91] made request_uri_method case-sensitive --- 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 0865794b..f3f4202f 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -269,7 +269,7 @@ 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 case-insensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as detailed in (#request_uri_method_post). +: OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two case-sensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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 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, if there is no other means to convey its capabilities to the Wallet. From fb39140231a959707b39c3536071988580268504 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 12:59:41 +0100 Subject: [PATCH 76/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 13998b07..393687be 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -234,11 +234,11 @@ The Authorization Request follows the definition given in [@!RFC6749] taking int 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 Wallet may want to provide to the Verifier details about its technical capabilities to +This specification defines a new mechanism for the cases when the Wallet wants to provide to the Verifier details about its technical capabilities to allow the Verifier to generate a request that matches the technical capabilities of that Wallet. To enable this, the Authorization Request can contain a `request_uri_method` parameter with the value `post` that signals to the Wallet that it can make an HTTP POST request to the Verifier's `request_uri` -endpoint with information about its capabilities. The Wallet MAY continue with JAR +endpoint with information about its capabilities as defined in {#request_uri_method_post}. The Wallet MAY continue with JAR when it receives `request_uri_method` parameter with the value `post` but does not 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]. From 674d0aae99d989caf7649646091363a8725c0d88 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:02:38 +0100 Subject: [PATCH 77/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 393687be..a5841d2c 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -272,8 +272,8 @@ A public key to be used by the Wallet as an input to the key agreement to encryp : OPTIONAL. A string determining the HTTP method to be used with the `request_uri` included in the same request. Two case-sensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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 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, if there is no other means to convey its capabilities to the Wallet. -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. +If the Verifier set the `request_uri_method` parameter value to `post` and there is no other means to convey its capabilities to the Wallet, it SHOULD add the `client_metadata` parameter to the Authorization Request. +This enables the Wallet to assess the Verifier's capabilities, allowing it to transmit only the relevant capabilities through the `wallet_metadata` parameter in the Request URI POST request. If the Verifier uses the `client_id_scheme` parameter 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: From fe8ae63bb2c26cf7ebe057bb5390887138ad7ef4 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:02:52 +0100 Subject: [PATCH 78/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 a5841d2c..9237ccb8 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -297,7 +297,7 @@ 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_method` parameter (including the additional parameters `client_id_scheme` and `client_metadata`): +The following is a non-normative example of an Authorization Request with a `request_uri_method` parameter (including the additional `client_id_scheme` and `client_metadata` parameters): ``` GET /authorize? From 1088682d5c63e22e34d185efafc1738f16b4cbbb Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:03:07 +0100 Subject: [PATCH 79/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 9237ccb8..2f3d1a60 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -485,7 +485,7 @@ 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} +## Request URI Method `post` {#request_uri_method_post} This request is handled by the Request URI endpoint of the Verifier. From c6057d92089a59e1a85d4a93a2157fa06e5b4ea5 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:07:18 +0100 Subject: [PATCH 80/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 2f3d1a60..9a68c535 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -494,7 +494,7 @@ The request MUST use the HTTP POST method with the https scheme, and the content The following parameters are defined: `wallet_metadata`: -: OPTIONAL. A String containing a JSON-encoded object containing metadata parameters as defined in (#as_metadata_parameters). +: OPTIONAL. A String containing a JSON object containing metadata parameters as defined in (#as_metadata_parameters). `wallet_nonce`: : OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. From e937d3a63ee81711215d7fb89adbf76798eae7ec Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:07:52 +0100 Subject: [PATCH 81/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 9a68c535..4a2bf5e7 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -497,7 +497,7 @@ The following parameters are defined: : OPTIONAL. A String containing a JSON object containing metadata parameters as defined in (#as_metadata_parameters). `wallet_nonce`: -: OPTIONAL. A String containing a value the Verifier MUST use in the `wallet_nonce` authorization parameter when creating the signed presentation request object. For example, a base64url encoded fresh, cryptographically random number with sufficient entropy. +: OPTIONAL. A String value used to mitigate replay attacks of the Authorization Request. When received, the Verifier MUST use it as the `wallet_nonce` value in the signed authorization request object. Value can be a base64url encoded, fresh, cryptographically random number with sufficient entropy. If the Wallet requires the Verifier to encrypt the Request Object, it SHOULD use the `jwks` or `jwks_uri` parameter 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. If the Wallet requires an encrypted Authorization Response, it SHOULD specify supported encryption algorithms using the `authorization_encryption_alg_values_supported` and `authorization_encryption_enc_values_supported` parameters. From f36cfe665ddda85539608a048271c7ed6c4e0efc Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:09:11 +0100 Subject: [PATCH 82/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 4a2bf5e7..fcd9507e 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -536,7 +536,7 @@ The following is a non-normative example of a request object: } ``` -The Wallet MUST process the request 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` claim. If it does not, the Wallet MUST terminate request processing. +The Wallet MUST process the request 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` claim. If it does not, the Wallet MUST terminate request processing. 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 Identifier value in the `client_id` Authorization Request parameter and the Request Object `client_id` claim value MUST be identical. If the Authorization Request contains a `client_id_scheme` parameter, the `client_id_scheme` Authorization Request parameter and the Request Object `client_id_scheme` claim value MUST be identical. If any of these conditions are not met, the Wallet MUST terminate request processing. From cdfea439b82bc9d2c10ae4c7b559bfa1df125cc5 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:09:37 +0100 Subject: [PATCH 83/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Paul Bastian --- 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 fcd9507e..b28cb0b5 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1183,7 +1183,7 @@ Whenever TLS is used, a TLS server certificate check MUST be performed, per [@!R ## Authorization Requests with Request URI -If no user interaction is required before sending the request, it is easy to request on a large scale and in an automated fashion (e.g.) the wallet capabilities from all visitors of a website. Even without personally identifiable information (PII) this can reveal some information about users, like their nationality (e.g., a Wallet with special capabilities only used in one EU member state). +If no user interaction is required before sending the request, it is easy to request on a large scale and in an automated fashion the wallet capabilities from all visitors of a website. Even without personally identifiable information (PII) this can reveal some information about users, like their nationality (e.g., a Wallet with special capabilities only used in one EU member state). Mandatory 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. From 1737a30bfe377e41979bdc77815d5f4ce688e9cd Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:09:58 +0100 Subject: [PATCH 84/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- 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 b28cb0b5..de172336 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -538,7 +538,7 @@ The following is a non-normative example of a request object: The Wallet MUST process the request 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` claim. If it does not, the Wallet MUST terminate request processing. -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 Identifier value in the `client_id` Authorization Request parameter and the Request Object `client_id` claim value MUST be identical. If the Authorization Request contains a `client_id_scheme` parameter, the `client_id_scheme` Authorization Request parameter and the Request Object `client_id_scheme` claim value MUST be identical. If any of these conditions are not met, the Wallet MUST terminate request processing. +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 Identifier value in the `client_id` Authorization Request parameter and the Request Object `client_id` claim value MUST be identical. If the Authorization Request contains a `client_id_scheme` parameter, the `client_id_scheme` Authorization Request parameter and the Request Object `client_id_scheme` claim value MUST be identical. If any of these conditions are not met, the Wallet MUST terminate request processing. The Wallet then validates the request as specified in OAuth 2.0 [@RFC6749]. From d2ba0996138b4d79a6c31b3c23e6557ef7fe4ddb Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:19:35 +0100 Subject: [PATCH 85/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Daniel Fett --- 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 de172336..b68de059 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1778,7 +1778,7 @@ The technology described in this specification was made available from contribut -21 - * added POST request method for Request URI + * added `post` request method for Request URI -20 From a478244bf69c0111572a5541ccd09fc011639b5b Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:20:04 +0100 Subject: [PATCH 86/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 b68de059..7f4bd310 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -489,7 +489,7 @@ Other specifications can define further values for the `client_id_scheme` parame This request is handled by the Request URI endpoint of the Verifier. -The request MUST use the HTTP POST method with the https scheme, and the content type `application/x-www-form-urlencoded` and the accept header set to `application/oauth-authz-req+jwt`. +The request MUST use the HTTP POST method with the `https` scheme, and the content type `application/x-www-form-urlencoded` and the accept header set to `application/oauth-authz-req+jwt`. The following parameters are defined: From c6db7d5f065f239dae8235ad1e400cdd951d7884 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:20:46 +0100 Subject: [PATCH 87/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- openid-4-verifiable-presentations-1_0.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 7f4bd310..0a0520de 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -269,8 +269,7 @@ 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 case-sensitive values are defined for `request_uri_method` in this specification: `get` and `post`. If `request_uri_method` is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` is `post`, a supporting Wallet MUST send the same request using the HTTP POST method as 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 method `post` will send a GET request to the request URI (default behavior as defined in [@RFC9101]). +: OPTIONAL. A string determining the HTTP method to be used when the `request_uri` parameter is included in the same request. Two case-sensitive valid values are defined in this specification: `get` and `post`. If `request_uri_method` value is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` value is `post`, a supporting Wallet MUST send the request using the HTTP POST method as detailed in (#request_uri_method_post). If the `request_uri_method` parameter is not present, the Wallet MUST process the `request_uri` parameter as defined in [@RFC9101]. Wallets not supporting the `post` method will send a GET request to the request URI (default behavior as defined in [@RFC9101]). `request_uri_method` parameter MUST NOT be present if a `request_uri` parameter is not present. If the Verifier set the `request_uri_method` parameter value to `post` and there is no other means to convey its capabilities to the Wallet, it SHOULD add the `client_metadata` parameter to the Authorization Request. This enables the Wallet to assess the Verifier's capabilities, allowing it to transmit only the relevant capabilities through the `wallet_metadata` parameter in the Request URI POST request. If the Verifier uses the `client_id_scheme` parameter in the Request Object, it MUST also add the same `client_id_scheme` value in the Authorization Request. From d3e689409060fc23ed04c34708f7a59a8cbc89c8 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 13:20:58 +0100 Subject: [PATCH 88/91] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 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 0a0520de..9d24ab75 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -498,9 +498,9 @@ The following parameters are defined: `wallet_nonce`: : OPTIONAL. A String value used to mitigate replay attacks of the Authorization Request. When received, the Verifier MUST use it as the `wallet_nonce` value in the signed authorization request object. Value can be a base64url encoded, fresh, cryptographically random number with sufficient entropy. -If the Wallet requires the Verifier to encrypt the Request Object, it SHOULD use the `jwks` or `jwks_uri` parameter 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. If the Wallet requires an encrypted Authorization Response, it SHOULD specify supported encryption algorithms using the `authorization_encryption_alg_values_supported` and `authorization_encryption_enc_values_supported` parameters. +If the Wallet requires the Verifier to encrypt the Request Object, it SHOULD use the `jwks` or `jwks_uri` parameter within the `wallet_metadata` parameter to pass the public key for the input to the key agreement. Other mechanisms to pass the encryption key can be used as well. If the Wallet requires an encrypted Authorization Response, it SHOULD specify supported encryption algorithms using the `authorization_encryption_alg_values_supported` and `authorization_encryption_enc_values_supported` parameters. -Additionally, if the `client_id_scheme` value permits JWS Request Objects, the Wallet SHOULD list supported cryptographic algorithms for securing the Request Object through the `request_object_signing_alg_values_supported` parameter. Conversely, the Wallet MUST NOT include this parameter if the `client_id_scheme` precludes JWS Request Objects. +Additionally, if the `client_id_scheme` value permits signed Request Objects, the Wallet SHOULD list supported cryptographic algorithms for securing the Request Object through the `request_object_signing_alg_values_supported` parameter. Conversely, the Wallet MUST NOT include this parameter if the `client_id_scheme` precludes signed Request Objects. The following is a non-normative example of a request: From 17a60fc95df5d0ebc89f0a8880e1192b1571fa14 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Thu, 21 Mar 2024 16:51:04 +0100 Subject: [PATCH 89/91] added privacy considerations --- openid-4-verifiable-presentations-1_0.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 9d24ab75..884c0347 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1182,6 +1182,8 @@ Whenever TLS is used, a TLS server certificate check MUST be performed, per [@!R ## Authorization Requests with Request URI +If the Wallet is acting within a trust framework that allows the Wallet to determine whether a 'request_uri' belongs to a certain 'client_id', the Wallet is RECOMMENDED to validate the Verifier's authenticity and authorization given by 'client_id' and that the 'request_uri' corresponds to this Verifier. If the link cannot be established in those cases, the Wallet SHOULD refuse the request or ask the End-User for advise. + If no user interaction is required before sending the request, it is easy to request on a large scale and in an automated fashion the wallet capabilities from all visitors of a website. Even without personally identifiable information (PII) this can reveal some information about users, like their nationality (e.g., a Wallet with special capabilities only used in one EU member state). Mandatory 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. From ada0a45e6bdc1dcd44d09f8b69aa911514e0f4ec Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 25 Mar 2024 12:49:35 +0100 Subject: [PATCH 90/91] Update diagrams/request_uri_mode_post.md Co-authored-by: David Chadwick --- diagrams/request_uri_mode_post.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 7ccb071e..44b7f3d2 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -16,6 +16,10 @@ r --> u: authorization request\n(client_id, request_uri, request_uri_method=post deactivate r u --> w: authorization request\n(client_id, request_uri, request_uri_method=post, [client_id_scheme]) activate w +[ w --> w optional. Check client_id with trust framework] + +Note that the client_id is self asserted by the verifier. If the client_id is not trusted, then the user should be informed that an untrusted verifier is requesting information and asked if he/she wants to proceed. If the client_id identifies a trusted verifier, then the request_uri that is responded to should be the one that actually belongs to the trusted client_id, as verified by the trust framework. + w --> r: POST **request_uri** ([wallet_metadata][, wallet_nonce]) r -> r: create and sign (and optionally encrypt) request object r --> w: **signed (optionally encrypted) request object** (client_id, client_id_scheme, wallet_nonce, nonce, \nresponse_uri, presentation_definition, state) From 6f9c661ddaebc0d8e767bdade02fc1cc8c2bf774 Mon Sep 17 00:00:00 2001 From: Torsten Lodderstedt Date: Mon, 25 Mar 2024 12:55:21 +0100 Subject: [PATCH 91/91] changed additional message and note suggested by David to PlantUML format --- diagrams/request_uri_mode_post.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/diagrams/request_uri_mode_post.md b/diagrams/request_uri_mode_post.md index 44b7f3d2..424bc02f 100644 --- a/diagrams/request_uri_mode_post.md +++ b/diagrams/request_uri_mode_post.md @@ -16,10 +16,12 @@ r --> u: authorization request\n(client_id, request_uri, request_uri_method=post deactivate r u --> w: authorization request\n(client_id, request_uri, request_uri_method=post, [client_id_scheme]) activate w -[ w --> w optional. Check client_id with trust framework] - -Note that the client_id is self asserted by the verifier. If the client_id is not trusted, then the user should be informed that an untrusted verifier is requesting information and asked if he/she wants to proceed. If the client_id identifies a trusted verifier, then the request_uri that is responded to should be the one that actually belongs to the trusted client_id, as verified by the trust framework. - +w --> w: [optional. Check client_id with trust framework] +note over r,w + Note that the client_id is self asserted by the verifier. If the client_id is not trusted, then the user should be informed that an untrusted + verifier is requesting information and asked if he/she wants to proceed. If the client_id identifies a trusted verifier, then the request_uri + that is responded to should be the one that actually belongs to the trusted client_id, as verified by the trust framework. +end note w --> r: POST **request_uri** ([wallet_metadata][, wallet_nonce]) r -> r: create and sign (and optionally encrypt) request object r --> w: **signed (optionally encrypted) request object** (client_id, client_id_scheme, wallet_nonce, nonce, \nresponse_uri, presentation_definition, state)