Skip to content
Open
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion blueprint/03-architecture-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Copy link
Copy Markdown
Collaborator

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.

2. **Issuer** – an entity that issues attestations to the Holder.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

@sander sander Jun 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

![Ecosystem overview](../images/ecosystem-overview.png)
*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.
Expand Down
Binary file added images/ecosystem-overview.png

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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 ;)

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.