EU Trusted Lists Section

docs/en/trust.rst

@@ -578,6 +578,8 @@ Trust Chain
 
 The Trust Chain is a sequence of verified statements that validates a participant's compliance with the Federation. It has an expiration date time, beyond which it MUST be renewed to obtain the fresh and updated metadata. The expiration date of the Trust Chain is determined by the earliest expiration timestamp among all the expiration timestamp contained in the statements. No Entity can force the expiration date of the Trust Chain to be higher than the one configured by the Trust Anchor.
 
+The Wallet Providers MUST be published in a Trust List managed by the designed Federation authority. 
+
 Below is an abstract representation of a Trust Chain.
 
 .. code-block:: python
@@ -602,6 +604,11 @@ Below is a non-normative example of a Trust Chain in its original format (JSON A
 
     The entire Trust Chain is verifiable by only possessing the Trust Anchor's public keys.
 
+To ensure coherent and efficient management of trust lists across Europe, a structured approach has been proposed. This involves creating and governing a Superior Trust List at the European level and National Trust Lists at the member state level. The following sections provide the implementation details for each type of trust list.
+
+The **Superior Trust List** should be managed by a central entity at the European level, such as the European Commission. It will include direct references to each National Registry and each centrally managed Thematic Registry, unique for all member states. The governance is centralized under a single EU authority, authorized to add, remove, or update entries in the registry.
+
+The **National Trust List** should be managed by a national coordinating entity, ideally the National Supervisory Body or an entity delegated by it. This entity will receive requests from accredited and authoritative entities for the respective themes they manage. The Trust List will include direct references to each National List (Thematic, Wallet, TSP, and Devices Registries) and to the Superior Trust List for each centrally managed cross-border Thematic Trust List, unique to all member states.
 
 Offline Trust Attestation Mechanisms
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

docs/en/wallet-attestation.rst

@@ -15,7 +15,7 @@ The following requirements for the Wallet Attestation are met:
 - The Wallet Attestation MUST use the signed JSON Web Token (JWT) format;
 - The Wallet Attestation MUST give all the relevant information to attests the **integrity** and **security** of the device where the Wallet Instance is installed.
 - The Wallet Attestation MUST be signed by the Wallet Provider that has authority over and that is the owner of the Wallet Solution, as specified by the overseeing registration authority. This ensures that the Wallet Attestation uniquely links the Wallet Provider to this particular Wallet Instance.
-- The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties.
+- The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties. The Wallet Provider MUST also verify the Wallet Instance by using the App Store vendor's API, for Android is *Play Integrity API* and for iOS is *DeviceCheck*, these services are defined in this specification as **Device Integrity Service (DIS)**.
 - The Wallet Attestation MUST have a mechanism in place for revoking the Wallet Instance, allowing the Wallet Provider to terminate service for a specific instance at any time.
 - The Wallet Attestation MUST be securely bound to the Wallet Instance ephemeral public key.
 - The Wallet Attestation MAY be usable multiple times during its validity period, allowing for repeated authentication and authorization without the need to request new attestations with each interaction.
@@ -59,6 +59,12 @@ Wallet Instance Initialization and Registration
 
 **Step 1:**: The User starts the Wallet Instance mobile app for the first time.
 
+.. note::
+
+  The EUDIW Application MUST also implement the integrity services from the vendor's SDK, this service has already beed defined as **Device Integrity Service (DIS)** in this specification. The DIS helps by detecting potentially risky and fraudulent interactions, such as from tampered app versions and untrustworthy environments.
+  The verification process to establish the trustworthiness of a WI for the WP begins with the initial app launch during which a Cryptographic Hardware Key Tag is generated, serving as the WI's identifier. During the *Initialization and Registration* process, the WI transmits this Cryptographic Hardware Key Tag to the WP, which in turn generates a key pair and signs the Cryptographic Hardware Key Tag with the private key. The signed Cryptographic Hardware Key Tag is then retained by the WI.
+  Subsequently, when the WI requests WIA, it includes the signed Cryptographic Hardware Key Tag. To verify the request's reliability, the WP utilizes the public key generated before to authenticate the Cryptographic Hardware Key Tag.
+
 **Step 2:**: The Wallet Instance:
 
   * check if Device Integrity Service is available.
@@ -68,6 +74,11 @@ Wallet Instance Initialization and Registration
 
     **Federation Check:** The Wallet Instance needs to check if the Wallet Provider is part of the Federation, obtaining its protocol specific Metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the Wallet Provider is represented within the section `Wallet Provider metadata`_.
 
+.. note::
+
+    As explained in the chapter `Trust Infrastructure <https://github.com/cmarco0/eudi-wallet-it-docs-fork/blob/cmarco0-DynamicComponentViewProcess/docs/en/trust.rst#the-infrastructure-of-trust>`_  section `Trust Chain <https://github.com/cmarco0/eudi-wallet-it-docs-fork/blob/cmarco0-DynamicComponentViewProcess/docs/en/trust.rst#trust-chainit>`_ it ensures the integrity and authenticity of wallet solutions are rigorously maintained.
+The Trust Framework helps prevent fraudulent redirections, protecting user transactions and data.
+
 **Steps 3-5:**: The Wallet Instance sends a request to the Wallet Provider Backend and receives a one-time ``challenge``. This "challenge" is a ``nonce``, which must be unpredictable to serve as the main defense against replay attacks. The backend must generate the ``nonce`` value in a manner that ensures it is single-use and valid only within a specific time frame. This endpoint is compliant with the specification `OAuth 2.0 Nonce Endpoint`_.
 
 
@@ -181,7 +192,6 @@ This section describes the Wallet Attestation format and how the Wallet Provider
   2. MUST generates an ephemeral asymmetric key pair whose public key will be linked with the Wallet Attestation.
   3. MUST check if Wallet Provider is part of the federation and obtain its metadata.
 
-
 **Steps 4-6:**: The Wallet Instance solicits a one-time "challenge" from the Wallet Provider Backend. This "challenge" takes the form of a "nonce," which is required to be unpredictable and serves as the main defense against replay attacks. The backend MUST produce the "nonce" in a manner that ensures its single-use within a predetermined time frame.
 
 .. code-block:: http