Merge branch 'versione-corrente' into wallet-attestation

docs/en/contribute.rst

@@ -41,6 +41,7 @@ implementation profile and to the initial set of implementations.
 - Michele Silletti
 - Nicola Saitto
 - Niels van Dijk
+- Oliver Terbu
 - Paul Bastien
 - Pasquale De Rose
 - Peter Altmann

docs/en/remote-flow.rst

@@ -19,9 +19,9 @@ Once the Wallet Instance establishes the trust with the Relying Party and evalua
 A High-Level description of the remote flow, from the User's perspective, is given below:
 
   1. the Wallet Instance obtains an URL in the Same Device flow or a QR Code containing the URL in Cross Device flow;
-  2. the Wallet Instance extracts from the payload the following parameters: ``client_id``, ``request_uri``, ``state``, ``request_uri_methods`` and ``client_id_scheme``;
+  2. the Wallet Instance extracts from the payload the following parameters: ``client_id``, ``request_uri``, ``state``, ``request_uri_method`` and ``client_id_scheme``;
   3. If the ``client_id_scheme`` is provided and set with the value ``entity_id``, the Wallet Instance MUST collect and validate the OpenID Federation Trust Chain related to the Relying Party. If the ``client_id_scheme`` is either not provided or is assigned a value different from ``entity_id``, the Wallet Instance MUST establish the trust by utilizing the ``client_id`` or an alternative ``client_id_scheme`` value. This alternative value MUST enable the Wallet Instance to establish trust with the Relying Party, ensuring compliance with the assurance levels mandated by the trust framework;
-  4. If ``request_uri_methods`` is provided and set with the value ``post``, the Wallet Instance SHOULD transmit its metadata to the Relying Party's ``request_uri`` endpoint using the HTTP POST method and obtain the signed Request Object. If ``request_uri_methods`` is set with the value ``get`` or not present, the Wallet Instance MUST fetch the signed Request Object using an HTTP request with method GET to the endpoint provided in the ``request_uri`` parameter;
+  4. If ``request_uri_method`` is provided and set with the value ``post``, the Wallet Instance SHOULD transmit its metadata to the Relying Party's ``request_uri`` endpoint using the HTTP POST method and obtain the signed Request Object. If ``request_uri_method`` is set with the value ``get`` or not present, the Wallet Instance MUST fetch the signed Request Object using an HTTP request with method GET to the endpoint provided in the ``request_uri`` parameter;
   5. the Wallet Instance verifies the signature of the signed Request Object, using the public key obtained with the trust chain, and that its issuer matches the ``client_id`` obtained at the step number 2;
   6. the Wallet Instance evaluates the requested Digital Credentials and checks the elegibility of the Relying Party in asking these by applying the policies related to that specific Relying Party, obtained with the trust chain;
   7. the Wallet Instance asks User disclosure and consent;

docs/en/wallet-attestation.rst

@@ -497,7 +497,7 @@ The body of the Wallet Attestation JWT MUST contain:
 Wallet Instance Lifecycle
 -----------------------------
 
-The ability of the Wallet Instance to obtain a Wallet Attestation is bound to its current state. 
+The ability of the Wallet Instance to obtain a Wallet Attestation is bound to its current state.
 The Wallet Instance assesses its current state based on the Credentials stored locally and the Wallet Attestation issued by the Wallet Provider.
 
 The lifecycle of a Wallet Instance encompasses all the potential states it can configure, along with the transitions from one state to another. This lifecycle is depicted in the diagram below:
@@ -550,7 +550,7 @@ Transitions
 
 Revocations
 ~~~~~~~~~~~~~~~~~~
-As mentioned in the *Wallet Instance initialization and registration* section above, a Wallet Instance is bound to a Wallet Hardware Key and it's uniquely identified by it. 
+As mentioned in the *Wallet Instance initialization and registration* section above, a Wallet Instance is bound to a Wallet Hardware Key and it's uniquely identified by it.
 The Wallet Instance SHOULD send its public Wallet Hardware Key with the Wallet Provider, thus the Wallet Provider MUST identify a Wallet Instance by its Wallet Hardware Key.
 
 When a Wallet Instance is not usable anymore, the Wallet Provider MUST revoke it. The revocation process is a unilateral action taken by the Wallet Provider, and it MUST be performed when the Wallet Instance is in the `Operational` or `Valid` state.

requirements-dev.txt

@@ -6,7 +6,7 @@ commonmark==0.9.1
 doc8==0.11.1
 docs-italia-theme @ git+https://github.com/italia/docs-italia-theme.git@3209d99db00ef965c528fd2932ae7da7dcee26b0
 docutils==0.18.1
-idna==3.3
+idna==3.7
 imagesize==1.3.0
 Jinja2==3.1.3
 MarkupSafe==2.1.1