fix: Wallet Instance Attestation renamed to Wallet Attestation (#182)

* fix: Wallet Instance Attestation renamed to Wallet Attestation

* fix: wia -> wa

docs/en/defined-terms.rst

@@ -35,7 +35,7 @@ Below are the description of acronyms and definitions which are useful for furth
      - An instance of the Wallet Solution, installed on a personal mobile device and controlled by a specific User who is its sole owner. It is the application that enables citizens to fully and autonomously manage their digital identity and EAAs.
    * - Wallet Provider
      - All public and/or private entities, conforming to a technical profile and accredited by the Federation Authority, that provide citizens with an IT Wallet Instance.
-   * - Wallet Instance Attestation
+   * - Wallet Attestation
      - Verifiable Attestation, issued by the Wallet Provider, that proves the security compliace of the Wallet Instance.
    * - App Attestation Service
      - Device manufacturer service that allows you to certify the authenticity of the mobile app (Wallet Instance).

docs/en/index.rst

@@ -27,7 +27,7 @@ This documentation defines the national implementation profile of EUDI Wallet, c
  - PID/EAA in MDL CBOR format.
  - PID/EAA in `SD-JWT`_ format.
  - Wallet Solution general architecture.
- - Wallet Instance Attestation.
+ - Wallet Attestation.
  - Issuance of PID/EAA according to `OpenID4VCI`_.
  - Presentation of PID/EAA according to `OpenID4VP`_.
  - Presentation of pseudonyms according to `SIOPv2`_.
@@ -44,7 +44,7 @@ Index of content
    defined-terms.rst
    trust.rst
    wallet-solution.rst
-   wallet-instance-attestation.rst
+   wallet-attestation.rst
    pid-eaa-data-model.rst
    pid-eaa-issuance.rst
    relying-party-solution.rst

docs/en/relying-party-solution.rst

@@ -1,6 +1,6 @@
 .. include:: ../common/common_definitions.rst
 
-.. _Wallet Instance Attestation: wallet-instance-attestation.html
+.. _Wallet Attestation: wallet-attestation.html
 .. _Trust Model: trust.html
 
 .. _relying-party-solution:
@@ -19,7 +19,7 @@ In this section the following flows are described:
 In the **Same Device** and **Cross Device** Flows described in this chapter, the User interacts with a remote Relying Party.
 
 .. note::
-    The provisioning of the Wallet Instance Attestation from the Wallet Instace to the Relying Party is 
+    The provisioning of the Wallet Attestation from the Wallet Instace to the Relying Party is 
     under discussion within the international standardization working groups. At the current stage of the draft of this implementation profile,
     a mechanism based on `OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop>`_
     is used.
@@ -60,9 +60,9 @@ The details of each step shown in the previous picture are described in the tabl
   * - **6**, **7**, **8**, **9**
     - In the **Cross Device Flow**: the Request URI is provided in the form of a QR Code that is shown to the User. The User frames the QRCode with the Wallet Instance and extracts the Request URI. In the **Same Device Flow** the Relying Party responses with the Request URI in the form of HTTP Redirect Location (302). 
   * - **10**
-    - The Wallet Instance requests the content of the Authorization Request by invoking the Request URI, passing an Authorization DPoP HTTP Header containing the Wallet Instance Attestation and the DPoP proof HTTP Header.
+    - The Wallet Instance requests the content of the Authorization Request by invoking the Request URI, passing an Authorization DPoP HTTP Header containing the Wallet Attestation and the DPoP proof HTTP Header.
   * - **11**
-    - The Relying Party attests the trust to the Wallet Instance using the Wallet Instance Attestation and evaluates the Wallet Instance capabilities.
+    - The Relying Party attests the trust to the Wallet Instance using the Wallet Attestation and evaluates the Wallet Instance capabilities.
   * - **12**
     - The Relying Party issues a signed Request Object, returning it as response. The ``exp`` value of the signed Request Object MUST be no more than 240 seconds.
   * - **13**, **14**, **15**, **16**
@@ -168,7 +168,7 @@ The following actions are made by the Wallet Instance:
 - scan the QR Code (Cross Device only);
 - extract from the payload the ``request_uri`` parameter;
 - invoke the retrieved URI;
-- provide in the request its Wallet Instance Attestation, using :rfc:`9449` to proof the legitimate possession of it;
+- provide in the request its Wallet Attestation, using :rfc:`9449` to proof the legitimate possession of it;
 - obtain the signed Request Object from the Relying Party.
 - evaluate the trust with the Relying Party, by evaluating the Trust Chain related to it.
 
@@ -182,9 +182,9 @@ Below a non-normative example of HTTP request made by the Wallet Instance to the
   DPoP: $WalletInstanceAttestationProofOfPossession
 
 
-More detailed information about the `Wallet Instance Attestation`_ is available in its dedicated section of this technical specification.
+More detailed information about the `Wallet Attestation`_ is available in its dedicated section of this technical specification.
 
-To attest a high level of security, the Wallet Instance submits its Wallet Instance Attestation to the Relying Party, disclosing its capabilities and the security level attested by its Wallet Provider.
+To attest a high level of security, the Wallet Instance submits its Wallet Attestation to the Relying Party, disclosing its capabilities and the security level attested by its Wallet Provider.
 
 Below the description of the parameters defined in *OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)*.
 
@@ -193,7 +193,7 @@ If the DPoP HTTP Header is missing, the Relying Party would assume the lowest at
 DPoP HTTP Header
 ^^^^^^^^^^^^^^^^
 
-A **DPoP proof** is included in the request using the HTTP Header ``DPoP`` and containing a JWS. The JWS MUST be verified with the public key made available in the Wallet Instance Attestation (``Authorization: DPoP``).
+A **DPoP proof** is included in the request using the HTTP Header ``DPoP`` and containing a JWS. The JWS MUST be verified with the public key made available in the Wallet Attestation (``Authorization: DPoP``).
 
 The JOSE header of the **DPoP JWS** MUST contain at least the following parameters:
 
@@ -237,7 +237,7 @@ The payload of a **DPoP proof** MUST contain at least the following claims:
       - UNIX Timestamp with the time of JWT issuance, coded as NumericDate as indicated in :rfc:`7519`. 
       - [:rfc:`7519`. Section 4.1.6].
     * - **ath**
-      - Hash of the Wallet Instance Attestation. 
+      - Hash of the Wallet Attestation. 
       - [:rfc:`9449`. Section 4.2].
 
 

docs/en/trust.rst

@@ -29,7 +29,7 @@ except for Wallet Instances which are End-User's personal devices certified by t
 .. note::
     The Wallet Instance, as a personal device, is certified as reliable through a verifiable attestation issued and signed by a trusted third party.
 
-    This is called *Wallet Instance Attestation* and is documented in `the dedicated section  <Wallet Instance Attestation>`_.
+    This is called *Wallet Attestation* and is documented in `the dedicated section  <Wallet Attestation>`_.
 
 
 Below the table with the summary of the Federation Entity roles, mapped on the corresponding EUDI Wallet roles, as defined in the `EIDAS-ARF`_.
@@ -515,9 +515,9 @@ The concatenation of the statements, through the combination of these signing me
 The Trust Chains can also be verified offline, using one of the Trust Anchor's public keys.
 
 .. note::
-    Since the Wallet Instance is not a Federation Entity, the Trust Evaluation Mechanism related to it **requires the presentation of the Wallet Instance Attestation during the credential issuance and presentation phases**.
+    Since the Wallet Instance is not a Federation Entity, the Trust Evaluation Mechanism related to it **requires the presentation of the Wallet Attestation during the credential issuance and presentation phases**.
 
-    The Wallet Instance Attestation conveys all the required information pertaining to the instance, such as its public key and any other technical or administrative information, without any User's personal data.
+    The Wallet Attestation conveys all the required information pertaining to the instance, such as its public key and any other technical or administrative information, without any User's personal data.
 
 
 Relying Party Attestation
@@ -534,14 +534,14 @@ The Trust Chain SHOULD be contained within the signed request in the form of a J
 In offline flows, Trust Chain verification enables the assessment of the reliability of Trust Marks and Attestations contained within.
 
 
-Wallet Instance Attestation
+Wallet Attestation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The Wallet Provider issues the Wallet Instance Attestation, certifying the operational status of its Wallet Instances and including one of their public keys. 
+The Wallet Provider issues the Wallet Attestation, certifying the operational status of its Wallet Instances and including one of their public keys. 
 
-The Wallet Instance Attestation contains the Trust Chain that attests the reliability for its issuer (Wallet Provider) at the time of issuance.
+The Wallet Attestation contains the Trust Chain that attests the reliability for its issuer (Wallet Provider) at the time of issuance.
 
-The Wallet Instance provides its Wallet Instance Attestation within the signed request during the PID issuance phase, containing the Trust Chain related to the Wallet Provider. 
+The Wallet Instance provides its Wallet Attestation within the signed request during the PID issuance phase, containing the Trust Chain related to the Wallet Provider. 
 
 
 Trust Chain
@@ -584,7 +584,7 @@ Offline EUDI Wallet Trust Attestation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Given that the Wallet Instance cannot publish its metadata online at the *.well-known/openid-federation* endpoint, 
-it MUST obtain a Wallet Instance Attestation issued by its Wallet Provider. The Wallet Instance Attestation MUST contain all the relevant information regarding the security capabilities of the Wallet Instance and its protocol related configuration. It SHOULD contain the Trust Chain related to its issuer (Wallet Provider).
+it MUST obtain a Wallet Attestation issued by its Wallet Provider. The Wallet Attestation MUST contain all the relevant information regarding the security capabilities of the Wallet Instance and its protocol related configuration. It SHOULD contain the Trust Chain related to its issuer (Wallet Provider).
 
 
 Offline Relying Party Metadata