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 Trust Framework establishes that Wallet Providers, through their Trust Chain Root Authorities, are anchored in a Trust List managed by an appointed Supervisory Body or a delegated authority. This multi-layered security and oversight system creates a reliable and secure environment, ensuring users can trust the legitimacy and safety of their wallet instances.
+
 Below is an abstract representation of a Trust Chain.
 
 .. code-block:: python
@@ -602,6 +604,13 @@ 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.
 
+**Trust List implementation**
+
+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

@@ -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 WP MUST verify the WI by using the app store vendors 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 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 GUID is generated, serving as the WI's identifier. During the *Initialization and Registration* process, the WI transmits this GUID to the WP, which in turn generates a key pair and signs the GUID with the private key. This signed GUID is then retained by the WI. Subsequently, when the WI requests WIA, it includes the signed GUID. To verify the request's reliability, the WP utilizes the public key generated before to authenticate the GUID.
+
 **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