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

Conversation

cmarco0
Copy link
Contributor

@cmarco0 cmarco0 commented Jun 3, 2024

this PR aims to close #258

this answer 2 questions:

-how a WI can trust the WP
-how a WP can trust the WI

how a WP can trust the WI and the other way round
docs/en/wallet-attestation.rst Outdated Show resolved Hide resolved
docs/en/wallet-attestation.rst Outdated Show resolved Hide resolved
docs/en/wallet-attestation.rst Outdated Show resolved Hide resolved
docs/en/trust.rst Outdated Show resolved Hide resolved
docs/en/trust.rst Outdated Show resolved Hide resolved
@peppelinux peppelinux changed the title Update Wallet Attestation process Additional Clarification About the Trust establishment between WI and WP and viceversa Jun 17, 2024
@peppelinux peppelinux changed the title Additional Clarification About the Trust establishment between WI and WP and viceversa Additional Clarifications About the Trust establishment between WI and WP and viceversa Jun 17, 2024
cmarco0 and others added 2 commits June 17, 2024 14:13
the sentence about the WI verification from WP is a requirement and has beed moved in that section.
Co-authored-by: Giuseppe De Marco <[email protected]>
^^^^^^^^^^^^^^^

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.
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

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.
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.

@peppelinux peppelinux added this to the 0.8.1 milestone Jun 26, 2024
replace NAB with Supervisory Body
@peppelinux peppelinux changed the title Additional Clarifications About the Trust establishment between WI and WP and viceversa [EU Trusted Lists] Additional Clarifications About the Trust establishment between WI and WP and viceversa Jul 11, 2024
Copy link
Collaborator

@fmarino-ipzs fmarino-ipzs left a comment

Choose a reason for hiding this comment

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

I have a couple of comments on this:

  1. I would remove any real reference in terms of URL or Organizations etc. from the text.
  2. the trust list section is something that is not currently in the scope of this technical specification at this moment. I would postpone this to a future release.

@peppelinux peppelinux modified the milestones: 0.8.1, 0.9.0 Jul 16, 2024
@peppelinux peppelinux changed the title [EU Trusted Lists] Additional Clarifications About the Trust establishment between WI and WP and viceversa EU Trusted Lists Section Jul 16, 2024
@peppelinux peppelinux marked this pull request as draft July 16, 2024 14:27
@peppelinux
Copy link
Member

This section requires to be moved to a file dedicated to the european trusted lists

peppelinux added a commit that referenced this pull request Jul 16, 2024
This PR adds clarifications about how the wallet provider should check the mobile application wallet instance using the OS API, it takes parts of #303
@peppelinux peppelinux added the invalid This doesn't seem right label Jul 16, 2024
@peppelinux
Copy link
Member

@SaraConsoliACN this PR doesn't answer to the point raised here: #258 (comment)

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right trust-model
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Wallet Attestation - Dynamic Component View ] Process
5 participants