-
Notifications
You must be signed in to change notification settings - Fork 41
wb-147: Add ecosystem overview diagram to architecture overview #199
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
base: main
Are you sure you want to change the base?
Changes from 4 commits
a0a9c5e
91ee3fa
e7e1169
b0caf6b
24d479e
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 |
|---|---|---|
|
|
@@ -10,11 +10,20 @@ While the previous chapter describes the regulatory and architectural frameworks | |
|
|
||
| ## The Ecosystem at a Glance | ||
| The EUDI Wallet and EBW ecosystem follows the common three-party attestation model. In this model, three primary actors interact: issuer, holder and verifier. A trust framework supports these actors by providing the trust anchors used for validation. | ||
| 1. **Holder** – the wallet controlled by a natural or legal person. | ||
| 1. **Holder** – the wallet controlled by a natural person or economic operator. | ||
| 2. **Issuer** – an entity that issues attestations to the Holder. | ||
|
Collaborator
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. Suggests to rephrase as: A trusted source that verifies the holder's information and issues cryptographically signed credentials of that information.
Contributor
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. Instead of “trusted source”, “trust service provider”? To keep the distinction from authentic sources. In general however I’d prefer to drop the issuer-holder-verifier terminolgoy from D4.1 and just use ARF terminology such as PID/EAA Provider, Relying Party Instance, etc.
Collaborator
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.
I support trust service provider, but not ARF terminology as it rarely uses normed, without being standardized, terms and/or definitions. Imo, holder/issuer/verifier is easily understandably, following norms and used by many outside of ARF space. |
||
| 3. **Verifier** – a relying party that receives and validates attestations presented by the Holder. | ||
|
Collaborator
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. Suggests to rephrase as: an economic operator or natural person that requests and verifies the authenticity and validity of a holder's credential. |
||
| 4. **Trust framework** – the infrastructure used to validate trust relationships between ecosystem participants (described in Chapter 6). | ||
|
|
||
| The diagram below shows the **WE BUILD reference pattern** for the ecosystem. | ||
|
|
||
|  | ||
| *Figure 1: WE BUILD reference pattern for the EUDIW / EBW ecosystem.* | ||
|
|
||
| In this reference pattern, Issuers use the issuance capabilities of the European Business Wallet (EBW) to issue attestations to the Holder; the Holder uses the EUDI Wallet (for natural persons) or the European Business Wallet (for economic operators) to present attestations to the Verifier; and Verifiers use the verification capabilities of the European Business Wallet to validate the attestations presented by the Holder. The foundation of the ecosystem is the Trust framework, where Issuers publish keys, identifiers and schemas, and Verifiers register as Relying Parties. | ||
|
|
||
| The EBW is an architectural construct (a defined role and set of capabilities), not a regulated entity, certification artefact, or deployment specification. The reference pattern is what the WE BUILD pilots are designed to evidence; it does not preclude conformant implementations that follow a different architectural choice. Regulatory paths follow the attestation tier: QEAAs are issued via the QEAASP path under eIDAS2 with the EBW operating outside that certified scope, while PuB-EAAs (including the EBWOID) are anchored in the relevant authentic source. | ||
|
|
||
| ## System Landscape | ||
| The diagram below illustrates the baseline trust topology of the EU wallet ecosystem. Issuers provide attestations to holders, holders present them to verifiers, and all actors validate trust relationships using the trusted lists. | ||
| The trusted lists specify the recognised participants in schemes for electronic identification and trust services. | ||
|
|
||
|
Contributor
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. plese use mermaid to facilitate the review process with commitable suggestions, raster images are heavy for this
Contributor
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. I completely agree that code would be preferred here, but mermaid tends to jump around quite a bit and is has it's own drawbacks, but that could of course be my lack of mermaid-skillz ;) |
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.
Holder is the role of a natural person or an EO, not the wallet. Suggest to rephrase as: Natural prson or economic operator recieving, storing and sharing credentials.