-
Notifications
You must be signed in to change notification settings - Fork 21
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
base: versione-corrente
Are you sure you want to change the base?
Changes from 1 commit
d95d12a
fe74eec
6d3bf87
20b041e
5ac1a62
acade52
6ae7c1a
d78b98c
3a527f4
c9cf8fc
55ba6b7
5eecc69
5f519ea
3458233
8fea41d
69cc4bc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
|
||
Offline Trust Attestation Mechanisms | ||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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?