Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EU Trusted Lists Section #303

Draft
wants to merge 16 commits into
base: versione-corrente
Choose a base branch
from
11 changes: 7 additions & 4 deletions docs/en/trust.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Wallet Providers MUST be published in a Trust List managed by the designed Federation authority.
The Trust Chain including Wallet Provider MUST be anchored in a Trust List/Registry managed by the appointed Supervisory Body, where its Public Keys are available for validation purposes. It’s responsibility of the Supervisory Body to ensure that any Trust Chain anchored, contains exclusively certified Wallet Providers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@peppelinux Does this review allow the closure of issue #258?


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this sounds more like a proposal, while the scope of this technical specification is not to share proposal but to offer clear implementation configurations and examples. Not sure about this editorial cut

here I expect to get how the trust list must be implemented, the format used and the non normative examples about requests and responses


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should -> must

national coordinating entity is too much generic and therefore not actionable ... We need to use a clear terminology using an established role within the ecosystem. Please find it in the european regulations.

I don't like using etc... we need to enumerate all the entities required to be published within the trusted list. When this information is not clear and neither in our possession, we may think to explain one or more open points in the form of a note.


Offline Trust Attestation Mechanisms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Expand Down
Loading