Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alignments with OpenID4VP Draft 22 #507

Open
wants to merge 5 commits into
base: versione-corrente
Choose a base branch
from

Conversation

peppelinux
Copy link
Member

@peppelinux peppelinux commented Nov 25, 2024

This PR:

In general, this PR has introduced the following breaking changes:

  • removed custom RP metadata parameterpresentation_definition_supported
  • renamed metadata type name wallet_relying_party to openid_credential_verifier
  • aligned JARM ref to the latest release
  • definitively removed deprecated client_id_scheme request parameter
  • additional clarifications about the importance of the parameter state in the presentation request
  • introduces dcql query, removed the dependency from presentation_definition
  • removed scopes in the rp requests
  • added client_id_schemes_supported in the wallet metadata during presentation
  • added client_id_schemes_supported in wallet attestation
  • typ value vc+sd-jwt renamed to dc+sd-jwt
  • when DCQL is used, vp_token is not an array but a json object
  • add further clarifications against the endpoint mixup attacks and using the endpoints attested within the federation trust chain metadata
  • fix the request-uri request including the wallet metadata using the application/x-www-form-urlencoded

docs/en/remote-flow.rst Outdated Show resolved Hide resolved
docs/en/remote-flow.rst Outdated Show resolved Hide resolved
"dcql_query": {
"credentials": [
{
"id": "perdonal id data",
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"id": "perdonal id data",
"id": "personal id data",

@@ -16,13 +16,13 @@ Technical References
* - `EIDAS-ARF`_
- EUDI Wallet - Architecture and Reference Framework.
* - `OpenID4VP`_
- Terbu, O., Lodderstedt, T., Yasuda, K., Looker, T., "OpenID for Verifiable Presentations", November 2023, Draft 20.
- Terbu, O., Lodderstedt, T., Yasuda, K., Looker, T., "OpenID for Verifiable Presentations", October 2024, Draft 22.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Terbu, O., Lodderstedt, T., Yasuda, K., Looker, T., "OpenID for Verifiable Presentations", October 2024, Draft 22.
- Terbu, O., Lodderstedt, T., Yasuda, K., Looker, T., "OpenID for Verifiable Presentations", December 2024, Draft 23.


The ``wallet_nonce`` parameter is RECOMMENDED for Wallet Instances that wants to prevent reply of their http requests to the Relying Parties.
When present, the RTelying Party MUST evaluate it.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When present, the RTelying Party MUST evaluate it.
When present, the Relying Party MUST evaluate it.

"claims": [
{"path": ["given_name"]},
{"path": ["family_name"]},
{"path": ["tax_id_code", "personal_administrative_number"]}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
{"path": ["tax_id_code", "personal_administrative_number"]}
{"path": ["personal_administrative_number"]}

@@ -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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Request Object Details
Request URI Request


The ``wallet_nonce`` parameter is RECOMMENDED for Wallet Instances that wants to prevent reply of their http requests to the Relying Parties.
When present, the RTelying Party MUST evaluate it.

Request URI Response
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Request URI Response
Request Object Details

@@ -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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normative details of the Request URI request are missing

"client_id": "https://relying-party.example.org",
"response_mode": "direct_post.jwt",
"response_type": "vp_token",
"dcql_query": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normative details of the DCQL query are missing

@@ -559,7 +572,8 @@ When the Wallet sends a response using ``direct_post.jwt`` to the Relying Party,
Redirect URI
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normative details of the response at the Authorization Response endpoint are missing

@@ -303,14 +343,12 @@ The JWT payload parameters are described herein:

* - **Name**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wallet_nonce is missing

@@ -124,7 +124,8 @@ A non-normative example of the HTTP request is represented below:
"request_object_signing_alg_values_supported": [
"ES256"
],
"presentation_definition_uri_supported": false
"presentation_definition_uri_supported": false,
"client_id_schemes_supported": ["https"]
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This non-normative example must be removed as it is not updated. The correct one is in line 251 (with wallet_metadata and wallet_nonce)

* - **state**
- OPTIONAL. A unique identifier for the current transaction generated by the Relying Party. The value SHOULD be opaque to the Wallet Instance.
- RECOMMENDED. A unique identifier for the current transaction generated by the Relying Party. The value SHOULD be opaque to the Wallet Instance.
* - **request_uri_method**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

.. warning::

The current OpenID4VP specification outlines various error responses that a Wallet Instance may return to the Relying Party (Verifier) in case of faulty requests (OpenID4VP, Section 6.4. Error Response). For privacy enhancement, Wallet Instances SHOULD NOT notify the Relying Party of faulty requests in certain scenarios. This is to prevent any potential misuse of error responses that could lead to gather informations that could be exploited.
The current OpenID4VP specification outlines various error responses that a Wallet Instance may return to the Relying Party (Verifier) in case of faulty requests. For privacy enhancement, Wallet Instances SHOULD NOT notify the Relying Party of faulty requests in certain scenarios. This is to prevent any potential misuse of error responses that could lead to gather informations that could be exploited.


Authorization Response Details
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Below the reference to Section 6.3 should be updated in Section 7.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
2 participants