From d95d12a41874f223b7262f903ddb4eabfde0cefd Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Mon, 3 Jun 2024 18:39:08 +0200 Subject: [PATCH 01/15] Update Wallet Attestation process how a WP can trust the WI and the other way round --- docs/en/wallet-attestation.rst | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 9ea8feff6..be046c8c3 100644 --- a/docs/en/wallet-attestation.rst +++ b/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,10 @@ 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:: + + The Trust Framework works in a way that the Wallet Providers though their Trust Chain Root Authorities are anchored in Trust List managed by appointed Supervisory Body or by a delegated authority. This ensures the integrity and authenticity of wallet solutions are rigorously maintained. These layers of security and oversight create a trusted environment, allowing users to rely on the legitimacy and safety of their wallet instances. Consequently, this robust framework significantly mitigates the risk of fraudulent redirections, safeguarding users' 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 +191,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 From fe74eecab61a68edc29fc54538ffea2f96c832b1 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 4 Jun 2024 11:53:07 +0200 Subject: [PATCH 02/15] Editorial change in the note, trust framework defines and not work --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index be046c8c3..a8accfebe 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -76,7 +76,7 @@ The verification process to establish the trustworthiness of a WI for the WP beg .. note:: - The Trust Framework works in a way that the Wallet Providers though their Trust Chain Root Authorities are anchored in Trust List managed by appointed Supervisory Body or by a delegated authority. This ensures the integrity and authenticity of wallet solutions are rigorously maintained. These layers of security and oversight create a trusted environment, allowing users to rely on the legitimacy and safety of their wallet instances. Consequently, this robust framework significantly mitigates the risk of fraudulent redirections, safeguarding users' transactions and data. + The Trust Framework defines that the Wallet Providers though their Trust Chain Root Authorities are anchored in Trust List managed by appointed Supervisory Body or by a delegated authority. This ensures the integrity and authenticity of wallet solutions are rigorously maintained. These layers of security and oversight create a trusted environment, allowing users to rely on the legitimacy and safety of their wallet instances. The 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`_. From 6d3bf87ea0b636810b0be4281081a6ed9cdc8413 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Thu, 13 Jun 2024 12:29:19 +0200 Subject: [PATCH 03/15] update trust list infrastructure section details about superior trust lists and the national ones --- docs/en/trust.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 8fd26a866..309d1a5d6 100644 --- a/docs/en/trust.rst +++ b/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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From 20b041e3559269594cfb299137694a81b538ca93 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Thu, 13 Jun 2024 12:41:54 +0200 Subject: [PATCH 04/15] update the part strictly related to the wallert solution --- docs/en/wallet-attestation.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index a8accfebe..5255d2b7d 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -76,7 +76,8 @@ The verification process to establish the trustworthiness of a WI for the WP beg .. note:: - The Trust Framework defines that the Wallet Providers though their Trust Chain Root Authorities are anchored in Trust List managed by appointed Supervisory Body or by a delegated authority. This ensures the integrity and authenticity of wallet solutions are rigorously maintained. These layers of security and oversight create a trusted environment, allowing users to rely on the legitimacy and safety of their wallet instances. The Framework helps prevent fraudulent redirections, protecting user transactions and data. +As explained in the chapter `Trust Infrastructure `_ section `Trust Chain `_ 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`_. From 5ac1a62da2fe4e909c28c7e914d9312ad0aee2eb Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Mon, 17 Jun 2024 14:13:24 +0200 Subject: [PATCH 05/15] editorial change the sentence about the WI verification from WP is a requirement and has beed moved in that section. --- docs/en/wallet-attestation.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 5255d2b7d..0ad26a588 100644 --- a/docs/en/wallet-attestation.rst +++ b/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. @@ -61,7 +61,6 @@ Wallet Instance Initialization and Registration .. 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. From acade5234d1482c6196be4fa7558c8a9fb06cee3 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Mon, 17 Jun 2024 15:55:01 +0200 Subject: [PATCH 06/15] editorial change Co-authored-by: Giuseppe De Marco --- docs/en/trust.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 309d1a5d6..97d1df274 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -578,7 +578,7 @@ 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. +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. From 6ae7c1aab706fffca27d5baa9f6dcc097524cb73 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Mon, 17 Jun 2024 16:21:31 +0200 Subject: [PATCH 07/15] Edit from GUID to UUID --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 0ad26a588..3bb614b7e 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -62,7 +62,7 @@ Wallet Instance Initialization and Registration .. 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 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. +The verification process to establish the trustworthiness of a WI for the WP begins with the initial app launch during which a UUID is generated, serving as the WI's identifier. During the *Initialization and Registration* process, the WI transmits this UUID to the WP, which in turn generates a key pair and signs the UUID with the private key. This signed UUID is then retained by the WI. Subsequently, when the WI requests WIA, it includes the signed UUID. To verify the request's reliability, the WP utilizes the public key generated before to authenticate the UUID. **Step 2:**: The Wallet Instance: From d78b98cd22a139d1d811457d1189e2e396074430 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 18 Jun 2024 11:12:37 +0200 Subject: [PATCH 08/15] editorial update replace UUID with Cryptographic Hardware Key Tag --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 3bb614b7e..0dc5f121f 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -62,7 +62,7 @@ Wallet Instance Initialization and Registration .. 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 UUID is generated, serving as the WI's identifier. During the *Initialization and Registration* process, the WI transmits this UUID to the WP, which in turn generates a key pair and signs the UUID with the private key. This signed UUID is then retained by the WI. Subsequently, when the WI requests WIA, it includes the signed UUID. To verify the request's reliability, the WP utilizes the public key generated before to authenticate the UUID. +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: From 3a527f4a25be44585db3419f2cf51ac8b92ba643 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 18 Jun 2024 11:16:58 +0200 Subject: [PATCH 09/15] editorial update --- docs/en/trust.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 97d1df274..cb7272f12 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -604,8 +604,6 @@ 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. From c9cf8fc7a2841ad5120d16615846e94c3ad980d7 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 18 Jun 2024 11:52:40 +0200 Subject: [PATCH 10/15] editorial update --- docs/en/wallet-attestation.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 0dc5f121f..ad98b6593 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -62,7 +62,8 @@ Wallet Instance Initialization and Registration .. 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. + 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: @@ -75,7 +76,7 @@ The verification process to establish the trustworthiness of a WI for the WP beg .. note:: -As explained in the chapter `Trust Infrastructure `_ section `Trust Chain `_ it ensures the integrity and authenticity of wallet solutions are rigorously maintained. + As explained in the chapter `Trust Infrastructure `_ section `Trust Chain `_ 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`_. From 55ba6b7447e31af141cf8ffefb1d9c7a013a214b Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:09:37 +0200 Subject: [PATCH 11/15] editorial update href --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index ad98b6593..15e917ddc 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -76,7 +76,7 @@ Wallet Instance Initialization and Registration .. note:: - As explained in the chapter `Trust Infrastructure `_ section `Trust Chain `_ it ensures the integrity and authenticity of wallet solutions are rigorously maintained. + As explained in the chapter `Trust Infrastructure `_ section `Trust Chain `_ 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`_. From 5eecc690a8f32f26f991e41dd4b74bff95b7c9b8 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Thu, 20 Jun 2024 15:59:32 +0200 Subject: [PATCH 12/15] editorial change; missing indent --- docs/en/wallet-attestation.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/wallet-attestation.rst b/docs/en/wallet-attestation.rst index 15e917ddc..6178efa66 100644 --- a/docs/en/wallet-attestation.rst +++ b/docs/en/wallet-attestation.rst @@ -77,7 +77,7 @@ Wallet Instance Initialization and Registration .. note:: As explained in the chapter `Trust Infrastructure `_ section `Trust Chain `_ it ensures the integrity and authenticity of wallet solutions are rigorously maintained. -The Trust Framework helps prevent fraudulent redirections, protecting user transactions and data. + 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`_. From 5f519ea70bb0f114846779a79043da945f5f9196 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Fri, 21 Jun 2024 16:52:48 +0200 Subject: [PATCH 13/15] created Trust List section --- docs/en/trust.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index cb7272f12..21aeffd3d 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -576,9 +576,7 @@ The Wallet Instance provides its Wallet Attestation within the signed request du 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. +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. Below is an abstract representation of a Trust Chain. @@ -604,11 +602,16 @@ 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 +^^^^^^^^^^^^^^^ + +The Wallet Providers MUST be published in a Trust List managed by the designed Federation authority. + 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. +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, Devices Registries etc...) and to the Superior Trust List for each centrally managed cross-border Thematic Trust List, unique to all member states. Offline Trust Attestation Mechanisms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From 34582333257416c1098b8fd105cde03f3ef75b73 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Mon, 24 Jun 2024 16:05:47 +0200 Subject: [PATCH 14/15] added non-normative example --- docs/en/trust.rst | 142 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 139 insertions(+), 3 deletions(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index 21aeffd3d..054d042af 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -607,11 +607,147 @@ Trust List The Wallet Providers MUST be published in a Trust List managed by the designed Federation authority. -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. +To ensure coherent and efficient management of trust lists across Europe, the following structured approach must be implemented. This includes the creation and governance of a Superior Trust List at the European level and National Trust Lists at the member state level. The sections below provide specific implementation details for each type of trust list, including formats and examples. + +The **Superior Trust List** must 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. + +Below is a non-normative example of a Superior Trust List in XML format: + +.. code-block:: xml + + + + + 5 + 342 + http://uri.etsi.org/TrstSvc/TrustedList/TSLType/EUlistofthelists + + European Commission + Commission européenne + Commissione europea + + + + + Rue de la Loi/Wetstraat 200 + Brussels + 1049 + BE + + + Rue de la Loi 200 + Bruxelles + 1049 + BE + + + + mailto:EC-TL-Service@ec.europa.eu + https://ec.europa.eu/digital-agenda/en/eu-trusted-lists-certification-service-providers + + + + EU: List of trusted service providers + UE : Liste des prestataires de services de confiance + UE: Elenco dei prestatori di servizi fiduciari + + + https://ec.europa.eu/tools/lotl/eu-lotl-pivot-341.xml + https://ec.europa.eu/tools/lotl/eu-lotl-legalnotice.html#en + + http://uri.etsi.org/TrstSvc/TrustedList/StatusDetn/EUlistofthelists + + http://uri.etsi.org/TrstSvc/TrustedList/schemerules/EUlistofthelists + + EU + + This list is maintained by the European Commission and contains information provided by Member States. + Cette liste est maintenue par la Commission européenne et contient des informations fournies par les États membres. + Questo elenco è mantenuto dalla Commissione europea e contiene informazioni fornite dagli Stati membri. + + + + +The **National Trust List** ia managed by a National Accreditation Body (NAB). 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 and to the Superior Trust List for each centrally managed cross-border thematic Trust List, unique to all member states. + +The Trusted Lists exist for the following entities: + +* Wallet Providers +* PID Providers +* QEAA Providers +* PuB-EAA Providers +* Access Certificate Authorities for: + * Relying Parties + * PID Providers + * QEAA Providers + +Below is a non-normative example of a National Trust List in XML format: + +.. code-block:: xml + + + + + 5 + 1 + http://uri.etsi.org/TrstSvc/TrustedList/SchemeType/EUgeneric + + Agenzia per l'Italia Digitale + + + http://uri.etsi.org/TrstSvc/TrustedList/SchemeType/Community + + + + http://example.com/other-tsl.xml + + + + + + + + Example Service Italia S.p.A. + + + + + Via Nazionale, 50 + Roma + 00184 + IT + + + + + http://www.exampleserviceitalia.it/info + + + + + + http://uri.etsi.org/TrstSvc/Svctype/CA/QC + + CN=XYZ Extended Validation SHA256 - CA 3, OU=Trust Service Provider, O=XYZ S.p.A., C=IT + + granted + 2023-06-01T00:00:00Z + + + MIIBIjANBgkq... + + + + + + + + -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. +.. note:: + + The National and Superior Trust List are in XML format, following the schema defined by the `the European Commission `_. -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, Devices Registries etc...) and to the Superior Trust List for each centrally managed cross-border Thematic Trust List, unique to all member states. Offline Trust Attestation Mechanisms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From 69cc4bc4cd57273e8a8c2cea9b6576e7c15300c5 Mon Sep 17 00:00:00 2001 From: cmarco0 <146938645+cmarco0@users.noreply.github.com> Date: Tue, 2 Jul 2024 11:33:25 +0200 Subject: [PATCH 15/15] editorial update replace NAB with Supervisory Body --- docs/en/trust.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/trust.rst b/docs/en/trust.rst index cd124a4e4..34313c4d1 100644 --- a/docs/en/trust.rst +++ b/docs/en/trust.rst @@ -694,7 +694,7 @@ Below is a non-normative example of a Superior Trust List in XML format: -The **National Trust List** ia managed by a National Accreditation Body (NAB). 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 and to the Superior Trust List for each centrally managed cross-border thematic Trust List, unique to all member states. +The **National Trust List** ia managed by a Supervisory Body. 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 and to the Superior Trust List for each centrally managed cross-border thematic Trust List, unique to all member states. The Trusted Lists exist for the following entities: