Alignments with OpenID4VP Draft 22 #507
Conversation
peppelinux
requested review from
fmarino-ipzs,
m-basili,
giadas and
grausof
and removed request for
fmarino-ipzs and
m-basili
| @@ -232,16 +238,27 @@ Below a non-normative example of the HTTP Request to the status endpoint, where | |||
|
|
|||
| When the status endpoint returns **200 OK**, it means that the User authentication is successful and the JavaScript code will use the returned location where the user-agent will be redirect to continue the navigation. | |||
|
|
|||
| Even if an adversary were to steal the random value used in the request to the status endpoint, their user-agent would be rejected due to the missing cookie in the request. | |||
|
|
|||
|
|
|||
| Request Object Details | |||
| ---------------------- | |||
|
|
|||
| Below a non-normative example of HTTP request made by the Wallet Instance to the Relying Party. | |||
There was a problem hiding this comment.
Normative details of the Request URI request are missing
There was a problem hiding this comment.
see my previous comment. I'd prefer to not redefine those parameters but reference the section where they are defined.
| "client_id": "https://relying-party.example.org", | ||
| "response_mode": "direct_post.jwt", | ||
| "response_type": "vp_token", | ||
| "dcql_query": { |
There was a problem hiding this comment.
Normative details of the DCQL query are missing
There was a problem hiding this comment.
| @@ -559,7 +572,8 @@ When the Wallet sends a response using ``direct_post.jwt`` to the Relying Party, | |||
| Redirect URI | |||
There was a problem hiding this comment.
Normative details of the response at the Authorization Response endpoint are missing
There was a problem hiding this comment.
See my suggestion below
| @@ -303,14 +343,12 @@ The JWT payload parameters are described herein: | |||
|
|
|||
| * - **Name** | |||
There was a problem hiding this comment.
wallet_nonce is optional, I have added it anyway.
|
The current structure of the Remote Flow section is not easy to follow. For example, it starts with the details of the Request URI POST, even if in the flow this request occurs after the Authorization Request. To follow the order of the requests and responses presented in the flow, I suggest restructuring this section. Here a proposal Remote Flow
|
| @@ -329,29 +367,21 @@ The JWT payload parameters are described herein: | |||
| - String determining the HTTP method to be used with the `request_uri` endpoint to provide the Wallet Instance metadata to the Relying Party. The value is case-insensitive and can be set to: `get` or `post`. The GET method, as defined in [@RFC9101], involves the Wallet Instance sending a GET request to retrieve a Request Object. The POST method involves the Wallet Instance requesting the creation of a new Request Object by sending an HTTP POST request, with its metadata, to the request URI of the Relying Party. | |||
There was a problem hiding this comment.
I think that the request_uri_method should be removed from the request object. The Wallet has already performed the GET/POST request to the Request URI to obtain the Request Object, it does not need this info here.
There was a problem hiding this comment.
the way we have included it in the qrcode is pretty custom and in the form of an hint to anticipate its use and then to have a more efficient flow
The place of the request_uri_method is in the request response object
Co-authored-by: Giada Sciarretta <[email protected]>
| Even if an adversary were to steal the random value used in the request to the status endpoint, their user-agent would be rejected due to the missing cookie in the request. | ||
|
|
||
|
|
||
| Request URI Request | ||
| ---------------------- | ||
|
|
There was a problem hiding this comment.
| The request and its parameters are defined in Section number 5 (Authorization Request) of `OpenID4VP`_. |
Co-authored-by: Giada Sciarretta <[email protected]>
| * - **response_type** | ||
| - It MUST be set to ``vp_token``. |
There was a problem hiding this comment.
| * - **response_type** | |
| - It MUST be set to ``vp_token``. | |
| * - **response_type** | |
| - It MUST be set to ``vp_token``. | |
| * - **wallet_nonce** | |
| - OPTIONAL. A String value used to mitigate replay attacks of the Authorization Request, as defined in Section 5.11 (Request URI Method) of `OpenID4VP`_. |
| @@ -559,7 +569,8 @@ When the Wallet sends a response using ``direct_post.jwt`` to the Relying Party, | |||
| Redirect URI | |||
| ------------ | |||
|
|
|||
| When the Relying Party provides the redirect URI, the Wallet Instance MUST send the user-agent to this redirect URI. The redirect URI allows the Relying Party to continue the interaction with the End-User on the device where the Wallet Instance resides after the Wallet Instance has sent the Authorization Response to the response URI. | |||
| When the Relying Party provides the redirect URI, the Wallet Instance MUST redirect the user-agent to the location defined in the redirect URI. | |||
| The redirect URI allows the Relying Party to continue the interaction with the End-User on the device where the Wallet Instance resides after the Wallet Instance has sent the Authorization Response to the response URI. | |||
|
|
|||
There was a problem hiding this comment.
| The response provided by Relying Party, and the parameters and values contained in it, are defined in Section 7.2. (Response Mode "direct_post") of the OpenID4VP specification. | |
This PR:
In general, this PR has introduced the following breaking changes:
presentation_definition_supportedwallet_relying_partytoopenid_credential_verifierclient_id_schemerequest parameterstatein the presentation requestpresentation_definitionclient_id_schemes_supportedin the wallet metadata during presentationclient_id_schemes_supportedin wallet attestationvc+sd-jwtrenamed todc+sd-jwtvp_tokenis not an array but a json objectapplication/x-www-form-urlencoded