%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
graph TB
classDef titleBox fill:none,stroke:none,font-weight:bold,font-size:16px,color:black;
subgraph MS["Member State"]
Registrar[Registrar<br/>Reg_01, Reg_02]
AccessCA[Access Certificate Authority<br/>Reg_10, Reg_11]
RegCertProv[Provider of Registration Certificates<br/>RPRC_01, RPRC_02]
TLProvider[Trusted List Provider<br/>MS Component]
Registry[Registry<br/>Reg_03, Reg_04]
WP[Wallet Provider<br/>Notified by MS to Commission<br/>Not registered with Registrar]
Registry ~~~ WP
end
subgraph EC["European Commission"]
ECNotify[Notification System<br/>GenNot_01, GenNot_02]
ECVerify[Verification System<br/>GenNot_04]
LoTLCompile[LoTL Compilation<br/>ETSI TS 119612 D.5]
LoTL[List of Trusted Lists<br/>Signed/Sealed by EC]
end
subgraph EntitiesScope[ ]
EntitiesTitle["Registered Entities<br/>(Register with Registrar)"]:::titleBox
PID[PID Provider<br/>Registers with Registrar<br/>Also notified to Commission<br/>PPNot_02]
AP[QEAA and EAA Providers<br/>Registers with Registrar<br/>Reg_21]
RP[Relying Party<br/>Reg_25]
RPI[Relying Party Intermediary<br/>Reg_25, RPI_01]
EntitiesTitle ~~~ PID
EntitiesTitle ~~~ AP
EntitiesTitle ~~~ RP
EntitiesTitle ~~~ RPI
end
subgraph TL["Published Trusted Lists"]
WPTL[Wallet Provider TL<br/>Compiled by EC<br/>WPNot_04, WPNot_05]
PIDTL[PID Provider TL<br/>Compiled by EC<br/>PPNot_05]
APTL[Attestation Provider TLs<br/>Compiled by MS TLP]
ACATL[Access CA TL<br/>Compiled by EC<br/>PPNot_06, RPACANot_04]
RegCertTL[Registration Cert Provider TL<br/>Compiled by EC<br/>RPACANot_04]
end
PID -->|Register with identification & entitlements<br/>Reg_01, Reg_19| Registrar
AP -->|Register with identification & entitlements<br/>Reg_01, Reg_21| Registrar
RP -->|Register with identification, Services and entitlements<br/>Reg_01, Reg_10a, Reg_25| Registrar
RPI -->|Register self + each intermediated RP<br/>RPI_01, RPI_03, RPI_04, Reg_34a| Registrar
WP -.->|MS notifies WP to Commission<br/>GenNot_01, WPNot_01, WPNot_02| ECNotify
PID -.->|After registration, MS notifies PID Provider to Commission<br/>GenNot_01, PPNot_01, PPNot_02| ECNotify
AccessCA -.->|MS notifies Access CA to Commission<br/>GenNot_01, RPACANot_01, RPACANot_02| ECNotify
RegCertProv -.->|MS notifies Registration Cert Provider to Commission<br/>GenNot_01, RPACANot_01, RPACANot_02| ECNotify
Registrar -->|Approve & Register<br/>Reg_19, Reg_21| Registry
Registrar -->|Request Access Cert<br/>Reg_10| AccessCA
AccessCA -->|Issue Access Certificate<br/>Reg_10, Reg_12| EntitiesScope
Registrar -.->|Optional: Request Reg Cert<br/>RPRC_09, RPRC_13| RegCertProv
RegCertProv -.->|Issue Registration Certificate<br/>RPRC_02| EntitiesScope
Registrar -->|Registration Complete<br/>Triggers TLP for Attestation Providers| TLProvider
Registry -.->|TLP accesses Registry data<br/>Extracts Trust Anchors for Attestation Providers| TLProvider
TLProvider -->|Compile, Sign & Publish<br/>national EAA Provider TL and MS QTSP TL for QEAA| APTL
TLProvider -->|Submit TL URL<br/>GenNot_01| ECNotify
ECNotify -->|Commission compiles & publishes<br/>Wallet Provider TL<br/>WPNot_04, WPNot_05| WPTL
ECNotify -->|Commission compiles & publishes<br/>PID Provider TL<br/>PPNot_05| PIDTL
ECNotify -->|Commission compiles & publishes<br/>Access CA TL<br/>PPNot_06, RPACANot_04| ACATL
ECNotify -->|Commission compiles & publishes<br/>Registration Cert Provider TL<br/>RPACANot_04| RegCertTL
ECNotify -->|Verify TL completeness<br/>GenNot_04| ECVerify
ECVerify -->|Compile LoTL<br/>ETSI TS 119612 D.5| LoTLCompile
LoTLCompile -->|Sign & Publish LoTL<br/>TLPub_06| LoTL
LoTL -->|Contains pointers to| TL
style MS fill:#e1f5ff
style EC fill:#fff4e1
style EntitiesScope fill:#e8f5e9
style TL fill:#f3e5f5
Trust Ecosystem
The appendix describes the full trust ecosystem for the EUDI Wallet and European Business Wallet, including roles and responsibilities of Member States and the European Commission. It provides a more complete view of the target ecosystem beyond the WE BUILD pilot context, which operates with adapted or simulated components.
The trust infrastructure for the EU Digital Identity and European Business Wallet ecosystem rests on three distinct but complementary processes: registration/onboarding of participants, notification of certain entities to the European Commission, and publication of Trusted Lists (or Lists of Trusted Entities) that provide cryptographic trust anchors for validation. WE BUILD aligns with the EUDI Wallet Architecture and Reference Framework (ARF) and the trust-infrastructure model described in the WP4 Trust Group deliverables.
2 Working group scope: [MVP] and [MVP+]
In line with the EUDI Wallet ARF, the WP4 Trust Group focuses on defining architectural patterns and profiles, not on specifying Member State-specific policies or operating production infrastructure. To make this concrete, the trust and security work is scoped in two steps:
- [MVP] (Minimum Viable Prototype):
- Implements the core onboarding scenarios from Task 1 (Subtask 1.1) for PID Providers, Attestation Providers, Wallet Providers, Relying Parties, and Certificate Authorities. [MVP] currently covers direct RP presentation (Wallet ↔︎ RP WRPAC / WRPRC in the request, RPRC_19). The WP4 Trust Registry Task 1 already includes intermediary indication and intermediary reference(s), including Service identifier (RPRC_04, Reg_34a). See WP4 Trust Group UC-RPI-01.
- Implements the basic trust‑registry scenarios from Task 1 (Subtask 1.2) needed to create, publish and consume Trusted Lists / Lists of Trusted Entities and registry entries for these actors.
- Demonstrates end‑to‑end flows for registration, access‑certificate issuance, trust‑anchor publication and consumption, reusing the ARF and ETSI TS 119 602/119 612/119 615 patterns without introducing new normative profiles.
- [MVP+] (Extended prototype):
- Completes the remaining Task 1 onboarding and trust‑registry scenarios, including more advanced evaluation, maintenance, revocation and discovery cases.
- Covers richer combinations of participants and roles (e.g. multiple types of Attestation Providers and more complex Relying Party ecosystems, including Topic 52 intermediated presentation: Wallet ↔︎ RPI on behalf of RP; Wallet authenticates the intermediary WRPAC (Reg_34a) and SHALL NOT display intermediary trade names (RPI_07)) while staying within the WP4 Trust Registry Task 2 trust framework and trust-infrastructure schema.
- May introduce pilot‑specific configurations or conventions (e.g. additional metadata, policy examples, or Trusted List extensions) as long as these remain compatible with the underlying ARF and ETSI models and are clearly marked as non‑normative.
- Completes the remaining Task 1 onboarding and trust‑registry scenarios, including more advanced evaluation, maintenance, revocation and discovery cases.
The boundary of the working group is therefore to: (a) define the trust‑infrastructure architecture, profiles, and flows needed for [MVP] and [MVP+]; (b) document how to apply ETSI TS 119 602/119 612/119 615 and the ARF in these scenarios; and (c) leave Member State policy choices (approval criteria, national extensions, operational SLAs) and long‑term production operation out of scope.
3 Trust infrastructure architecture (overview)
The following diagram summarises the roles of Member State and European Commission, the split between registration and notification, and how Trusted Lists and the LoTL are produced and consumed. Source: WP4 Trust Group Task 2, trust-infrastructure schema.
Note: WP4 is going to expose trust infrastructure depicted on this diagram, mimicking the infrastructure of at least one Member State. In the case of mimicking more than a single Member State, WE BUILD participants willing to register are going to be able to select a registry in which they are going to be registered, or the WP4 registrar, if single, is going to place them in one of the registries. For the sake of simplicity, in such a case, not all the technical components depicted in the diagram within a Member State will have to be multiplied; e.g. there may be multiple registries but a single trusted list across the countries to which all wallet-relying parties are provisioned.
4 Security Measures
From an architectural perspective, security in the wallet ecosystem is structured in four dimensions. (1) Trust anchor layer: cryptographic validation and key lifecycle management, including revocation of keys, certificates, and services. Trust Anchors are published by Trusted Lists and related mechanisms (ETSI TS 119 602/119 612/119 615), applying to the entities and roles described in the Trust Ecosystem (PID Providers, Attestation Providers, Wallet Providers, Access CAs, etc.). (2) Identity assurance: the level of assurance (LoA) of the identities involved is maintained across the full lifecycle of those identities. (3) Device and execution environment: the security of the devices and execution environments that host Wallet Instances and cryptographic material (WSCA/WSCD) is addressed by the wallet secure cryptographic application/device (WSCA/WSCD) architecture for wallet-side components, to be specified by the Architecture and Wallets groups (and, for remote WSCA/WSCD, together with the QTSP group). Secure environments operated by PID Providers, Pub-EAA and QEAA Providers, and Trust Service Providers (TSPs) are addressed by applicable eIDAS and ETSI requirements for TSP and provider infrastructure. (4) Protocol and policy layer: authentication (verifying who or what is acting) and authorization (what the subject is allowed to do, driven by policies) are realised in conformance with the ARF and related technical specifications, per application-specific flow and per attestation data format.
4.1 Authentication
Authentication in the WE BUILD architecture closely follows the standards and flows of the underlying protocols (OpenID for Verifiable Credentials, ISO 18013-5, and other application-specific communication protocols).
For organizational entities that register with the Registrar (PID Providers, Attestation Providers and other Issuers, Relying Parties, and intermediaries), authentication is primarily established using access certificates issued by the Access Certificate Authority, validated against up-to-date Trusted Lists or Lists of Trusted Entities (ARF and ETSI TS 119 602 / 119 612 / 119 615). In an intermediated presentation the Wallet Unit authenticates the intermediary’s WRPAC associated to that RP/Service (RPI_06, RPA_04, Reg_34a). Wallet Providers are notified by Member States to the European Commission (they do not register with the Registrar); their authenticity is established via the Wallet Provider Trusted List and related attestations (e.g. Wallet Unit Attestation). Mutual trust is strictly required in application-specific protocol flow specifications, and consolidated through OpenID HAIP and ARF HLRs, with certificate-bound tokens and protocol-level message signatures along with endpoint authentication and message integrity.
According to the ARF, the Relying Party cannot request the Wallet Unit Attestation (WUA) during the presentation flow. Presentation requests address PID and attestations only (ARF Topic 1, OIA_01); the WUA is presented to the PID Provider or Attestation Provider during issuance of a PID or device-bound attestation, not to the Relying Party (ARF Topic 9, WUA_03, WUA_05, WUA_05a). The ARF explicitly states that there is no separate mechanism for the Relying Party to verify the revocation status of a Wallet Unit directly with the Wallet Provider (ARF Section 6.6.3.12). Trust in the Wallet Unit is therefore mediated by a trusted third party: the PID Provider or Attestation Provider that belongs to a Trust Anchor (Trusted List) and that received the WUA at issuance. That trust is indirect from the Relying Party’s perspective. The PID Provider or EAA Provider periodically checks the revocation status of the Wallet Unit to which it has issued credentials (using the revocation information in the WUA received at issuance; ARF Topic 9 WUA_02, ARF Section 6.6.2.4). If the Wallet Unit is revoked, the PID Provider or Attestation Provider SHALL revoke the credentials it issued to that Wallet Unit (Article 5, 4.(b), European Digital Identity Regulation; ARF Section 6.6.2.4). By verifying the revocation status of the PID or attestation, the Relying Party implicitly relies on the issuer’s verification of the Wallet Unit.
For attestation holders (individual end-users and the corresponding wallets), authentication requirements leverage possession-based proofs and, where applicable, identity schemes notified to the European Commission that attest Level of Assurance High according to the eIDAS Framework. Local user authentication (e.g., via PIN, password, device biometrics) must fulfill the minimum Level of Assurance required by the credential or attestation type and is enforced by policy prior to any issuance or presentation flow.
Wallet Units are expected to combine protocol-specific authentication mechanisms (as per OpenID4VC and ISO 18013-5) with validation of trust anchors and up-to-date Trusted Lists, covering both participant and credential authenticity.
4.3 Certificates and cryptographic anchors
- Trusted Lists / Lists of Trusted Entities (LoTE) (ETSI TS 119 612, TS 119 602) are pivotal trust anchors in the ecosystem. LoTE entries publish the keys and related metadata for the entity types described in the Trust Ecosystem (Wallet Providers, PID Providers, Attestation Providers, Access CAs, Registration Cert Providers). Validation of trust service outputs against these lists SHALL follow ETSI TS 119 615 (procedures for using and interpreting EUMS national trusted lists).
- Access certificates are issued by the Access Certificate Authority to registered PID Providers, Attestation Providers and other Issuers, Relying Parties, and intermediaries. Issuance SHALL comply with ETSI TS 119 411-8; the Authority SHALL comply with at least ETSI EN 319 411-1 Normalised Certificate Policy (NCP) requirements. Each registering entity receives at least one access certificate per Service (Reg_10a, Reg_33, Reg_34). Intermediaries receive a separate WRPAC set per intermediated RP (Reg_34a, RPI_01). Access certificates authenticate entities in protocol exchanges and are validated by Wallet Units using the trust anchors in the Access CA LoTE entries.
- Registration certificates SHALL be issued by the Provider of Registration Certificates after registration: one per intended use × Service for Relying Parties (RPRC_09); one per Service for PID/Attestation Providers (RPRC_13). The presentation request SHALL include a single WRPRC by value (RPRC_19). The Wallet SHALL verify that WRPRC (RPRC_17, RPRC_17a, RPRC_21); if it is absent or invalid, warn the User at approval. RPRC_16, RPRC_18, and RPRC_19a are empty in ARF v3.0.0. Registry APIs remain for publication (Reg_03, Reg_06).
For reference on relying party access certificates and relying party registration certificates, see the RPAC/RPRC documentation.
4.4 Key lifecycle and Trusted Lists
Key lifecycle for trust anchors and for services listed in Trusted Lists is reflected in list content and status (e.g. service status, status determination approach, and history where required by the profile). Updates and revocation of listed services follow the applicable ETSI trusted list profiles (TS 119 612 / TS 119 602) and are consumed per ETSI TS 119 615. Certificate policies and Certificate Transparency (SCT) where applicable are specified in the referenced ETSI standards.
5 Relying Party Registration & Access Certificates
Relying Parties (verifiers) register with the Member State Registrar before being able to securely identify themselves to Wallet Units. Registration includes identification data, Services (Reg_10a), the attributes the RP intends to request, the intended use mapped to each Service (Reg_10d), and, if applicable, use of intermediaries. The Registrar approves the RP (per ARF Reg_25) and publishes the entry in the Registry. An intermediary registers itself as a Relying Party (RPI_01) and registers each intermediated RP with evidence of the contract (RPI_03, RPI_04). The Access Certificate Authority then issues access certificates per Service (Reg_10a, Reg_33, Reg_34); an intermediary receives a separate set per intermediated RP (Reg_34a). WRPRCs are issued automatically (RPRC_09). In an intermediated transaction the Wallet Unit authenticates the intermediary’s WRPAC, not the intermediated RP’s (RPI_06, RPA_04, Reg_34a); the intermediated RP is identified from the WRPRC in the request (RPRC_19, RPRC_04). Wallet Units authenticate a direct RP by validating its WRPAC against the Access CA trust anchors and by verifying the WRPRC in the same request (RPA_04, RPRC_17, RPRC_21). The common API for RP registration information (e.g. TS5) and the common set of RP information (e.g. TS6) are specified in the EUDI Wallet technical specifications. Detailed flows and diagrams are in the WP4 Trust Group trust-infrastructure schema (v0.9). Certificate issuance aspects are coordinated with the QTSP group.
The following sequence illustrates how a Wallet Instance discovers and validates Relying Party policy during presentation (WRPAC = access certificate; WRPRC = registration certificate). Source: WP4 Trust Group, EUDI Wallet Trust and Entitlement Discovery.
sequenceDiagram
participant W as Wallet Instance
participant RP as Relying Party or Intermediary
participant TL as Trusted List or List of Trusted Entities
participant OCSP as OCSP/CRL Responder
participant RCStatus as WRPRC Status List API
RP->>W: 1. Presentation Request (WRPAC + WRPRC by value)
Note over W: 2. Extract WRPAC of the Wallet-facing party<br/>(RP or intermediary per Reg_34a)
W->>TL: 3. Fetch Trusted List or List of Trusted Entities
TL-->>W: 4. Trusted List or List of Trusted Entities Response
Note over W: 5. Validate WRPAC<br/>- Check CA in Access CA LoTE<br/>- Verify service status: granted
W->>OCSP: 6. HTTPS GET /ocsp or /crl<br/>for WRPAC status
OCSP-->>W: 7. OCSP/CRL HTTP Response
Note over W: 8. Validate WRPRC in the request (RPRC_17)<br/>- Verify WRPRC Provider in Trusted List or List of Trusted Entities<br/>- If intermediated: WRPRC shows this intermediary (RPRC_04, RPRC_17a)<br/>- If absent or invalid: warn User at approval
W->>RCStatus: 9. HTTPS GET /wrprc/status-list<br/>(WRPRC status check)
RCStatus-->>W: 10. Status List HTTP Response
Note over W: 11. Verify requested attributes in the same WRPRC (RPRC_21)
Note over W: 12. Extract and Verify Entitlements from WRPRC<br/>- Parse entitlements<br/>- Validate requested attributes against entitlements
If the presentation is intermediated, the Wallet Unit authenticates the intermediary’s WRPAC, not the intermediated RP’s. The intermediated RP is identified from the WRPRC in the request (RPRC_19); the WRPRC association to the intermediary must match the authenticated WRPAC (RPI_06, RPRC_04, RPRC_17a; ETSI TS 119 475 §4.5). The Wallet SHALL NOT display the intermediary’s trade names (RPI_07). See Relying Party Intermediaries in the Trust Ecosystem.
6 Validation Functions for Relying Parties
Relying Parties need to authenticate and validate the Person Identification Data (PID) and attestations (e.g. LPID/EBWOID, EAA) received from Wallet Units. Validation relies on the trust infrastructure as follows:
- PID and LPID/EBWOID: Relying Parties validate the PID (or equivalent) signature using the List of Trusted Entities (LoTE) for PID Providers, i.e. the PID Provider Trusted List compiled by the European Commission and referenced from the LoTL. Procedures for authenticating the LoTL and national/EU trusted lists and for obtaining listed services are given in ETSI TS 119 615.
- Attestations (EAA): Relying Parties validate qualified EAA (QEAA) signatures using the Member State QTSP Trusted Lists (per Article 22 eIDAS) and PuB-EAA (and, where applicable, national non-qualified EAA) using the relevant Attestation Provider Trusted Lists. Trust anchors and service types are defined in ETSI TS 119 602 profiles (e.g. Annex H for Pub-EAA and national EAA provider lists).
- Wallet and RP side: Wallet Units verify RPs via the WRPRC in the presentation request and Access CA Trusted Lists or List of Trusted Entities (see Relying Party Registration & Access Certificates). Registry APIs remain for publication. PID Providers and Attestation Providers verify Wallet Providers against the Wallet Provider Trusted List before issuing credentials.
- Intermediated presentation: PID/QEAA/PuB-EAA/EAA validation (OIA_12–OIA_15) may be performed by the intermediary if contractually agreed. That does not make issuer trust “direct”: it remains TL/LoTE-based. The Wallet Unit’s trust in the requestor is the Access CA LoTE (intermediary WRPAC, Reg_34a) plus the intermediated RP’s WRPRC in the request.
The PID Providers group defines validation semantics for PID/LPID/EBWOID; the QTSP group covers EAA and certificate aspects. Exact validation requirements (e.g. OIA_12, OIA_13, OIA_14) and consumption procedures are documented in the WP4 Trust Group trust-infrastructure schema and ETSI trusted lists implementation profile.
6.1 Establishing trust with a Credential Issuer
Wallet Units and Relying Parties establish trust in a Credential Issuer (PID Provider or Attestation Provider) and in the credentials they issue by combining Trusted List entries (trust anchors and, where applicable, authorised attestation types) with registration data (Registry or registration certificate). The catalogue of attestation schemes defines what credential types exist; Trusted Lists and registration define who is allowed to issue which types. The flow below is aligned with the WP4 Trust Group credential catalogue and issuer constraints: the verifier accepts a credential only if the issuer is present in the applicable Trusted List and the credential’s attestation type is among the issuer’s authorised types (ISSU_24, ISSU_24a, ISSU_34, ISSU_34a for Wallet Units; OIA_12, OIA_13, OIA_14, OIA_15 for Relying Parties).
flowchart TB
subgraph Verifier["Wallet Unit or Relying Party"]
A[Receive credential or<br/>issuance request]
B[Read attestation type identifier<br/>and identify issuer from<br/>signing certificate]
C[Fetch applicable Trusted List<br/>PID Provider TL / Attestation Provider TL<br/>per LoTL]
D[Locate issuer entry in Trusted List]
E{Allowed attestation types<br/>in TL entry?}
F[Use list from TL<br/>serviceInformationExtensions]
G[Resolve via registration certificate<br/>or Registrar API<br/>ISSU_24a / ISSU_34a]
H[Validate credential signature<br/>using trust anchor from TL]
I{Issuer in TL and attestation type<br/>in authorised list?}
J[Accept credential]
K[Reject credential]
end
subgraph Sources["Trust sources"]
TL[(Trusted List<br/>trust anchor + metadata)]
RegCert[Registration certificate<br/>RPRC_15: attestation types]
Registry[Registry / Registrar API<br/>TS5, TS6]
end
A --> B
B --> C
C --> D
D --> E
E -->|Self-contained TL entry| F
E -->|Pointer to Reg Cert or Registry| G
F --> H
G --> H
H --> I
I -->|Yes| J
I -->|No| K
D -.-> TL
G -.-> RegCert
G -.-> Registry
6.2 Establishing trust with a Wallet Solution
Trust in a Wallet Solution (Wallet Provider and Wallet Unit) is established by Credential Issuers (PID Providers and Attestation Providers) before issuing a PID or attestation. The flow is mandated by the ARF (Topic 9 Wallet Unit Attestation, Topic 31 notification and Trusted Lists), uses OpenID4VCI 1.0 for the issuance protocol and issuer metadata (ISSU_22, ISSU_22a, ISSU_22b), and is reinforced by OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 for authenticity, holder authentication, and certificate-bound tokens. The Wallet Unit presents a Wallet Unit Attestation (WUA) to the Issuer during the issuance request; the Issuer verifies the Wallet Provider against the Wallet Provider Trusted List and validates the WUA (ARF ISSU_19, ISSU_21 for PID; ISSU_28, ISSU_30 for Attestation Providers; WUA_02, WUA_03, WUA_05, WUA_05a). The Wallet Provider Trusted List is compiled by the European Commission from Member State notifications (WPNot_01–WPNot_05).
flowchart TB
subgraph Ecosystem["Trust anchor establishment"]
MS[Member State<br/>notifies Wallet Provider]
EC[European Commission<br/>compiles & seals]
WPTL[(Wallet Provider Trusted List<br/>WPNot_04, WPNot_05)]
MS -->|GenNot_01, WPNot_01, WPNot_02| EC
EC -->|Trust anchors for WUA auth| WPTL
end
subgraph Issuance["Issuance flow (OpenID4VCI 1.0 + HAIP)"]
WU[Wallet Unit]
Issuer[Credential Issuer<br/>PID Provider or Attestation Provider]
WUA[Wallet Unit Attestation<br/>WUA_02, WUA_03, WUA_05, WUA_05a]
WU -->|1. Request credential<br/>present WUA| Issuer
Issuer -->|2. Resolve LoTL / fetch<br/>Wallet Provider TL| WPTL
Issuer -->|3. Verify Wallet Provider<br/>from WUA in TL<br/>ISSU_19, ISSU_21 / ISSU_30| WPTL
Issuer -->|4. Authenticate & validate WUA<br/>using trust anchor from TL<br/>verify WUA not revoked| WUA
end
WPTL -.-> Issuance
Issuer -->|5. Trust established?<br/>Issue credential| WU
6.3 Relying Party Intermediaries in the Trust Ecosystem
Intermediaries are a special class of Relying Party. Article 5b(10) of the European Digital Identity Regulation states that intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction. An intermediary connects to Wallet Units on behalf of one or more intermediated Relying Parties, requests the attributes those parties need, forwards the presented attributes, and then deletes them. High-level requirements are in ARF Topic 52 (v3.0.0); certificate binding follows ETSI TS 119 475 and CIR (EU) 2025/848 as amended by CIR (EU) 2026/1730.
Protocol split: RPI WRPAC authenticates the channel (bound to this RP/Service per Reg_34a); RP WRPRC identifies the beneficiary. Do not write that intermediated RPs “do not receive a WRPAC”. They do not present one in this flow and will not need one for that role (ARF §6.6.5).
Registration (two distinct acts):
- The intermediary registers itself as a Relying Party, indicating that it intends to act as an intermediary (RPI_01, Reg_26). It obtains a separate set of access certificates per intermediated RP, each associated to that RP’s unique identifier and Service identifier (Reg_34a). A WRPRC may be issued to the intermediary for direct use of its own Services; it is not used in intermediated presentation (ARF §6.6.5; ETSI TS 119 475 §5.2.4 NOTE 4: WRPRCs are not issued for WRPs registered solely as intermediaries).
- The intermediary then registers each intermediated Relying Party at a Registrar in the Member State where that Relying Party is established (RPI_03), providing legally valid evidence of the contractual relationship (RPI_04). WRPRCs are issued automatically per intended use × Service of the intermediated RP (RPRC_09), containing the association to the intermediary (RPRC_04). The intermediated RP indicates which single WRPRC to include (RPI_05).
Direct vs indirect trust. Trust mediated by a trusted third party (Access CA, Trusted List / LoTE, Registrar, CAB / certification scheme) is indirect. Direct trust is only the bilateral operational or contractual relationship that is not established through those third parties.
| Relationship | Kind | Mechanism |
|---|---|---|
| Intermediary ↔︎ intermediated Relying Party | Direct (contractual) | Principal–agent service contract. The Registrar records evidence of that contract (RPI_04); it does not create the relationship. |
| Wallet Provider ↔︎ Wallet Instances | Direct (operational) | Deployment, WUA issuance, and instance lifecycle under the Wallet Provider. |
| Wallet Unit → intermediary identity (channel) | Indirect | Validate the intermediary’s WRPAC against Access CA LoTE(s) (RPA_04, RPI_06, Reg_34a). |
| Wallet Unit → intermediated RP identity, Service, intended use, and RPI–RP binding | Indirect | WRPRC in the request (RPRC_19, RPRC_17, RPRC_17a, RPRC_21). WRPRC association must match the intermediary WRPAC (RPRC_04; ETSI TS 119 475 §4.5). RPRC_16, RPRC_18, RPRC_19a, and RPI_07a are empty. |
| Wallet Unit / RP / RPI → Credential Issuer | Indirect | PID Provider LoTE, MS QTSP TL, or Attestation Provider TL plus CAs (OIA_12–OIA_15). |
| Credential Issuer → Wallet Solution | Indirect | Wallet Provider Trusted List compiled by the Commission from MS notification (ISSU_19, ISSU_21 / ISSU_28, ISSU_30), after certification-scheme evaluation (CAB → scheme authority). |
Presentation transaction (ARF §6.6.5, RPI_05–RPI_10):
- The intermediated RP asks the intermediary to request attributes and indicates which single WRPRC to include (RPI_05).
- The intermediary sends the presentation request with the applicable WRPAC (Reg_34a) and that WRPRC by value (RPI_06, RPRC_19).
- The Wallet Unit authenticates the intermediary via the WRPAC / Access CA LoTE, and verifies the intermediated RP and the RPI–RP association from the WRPRC (RPRC_17, RPRC_17a, RPRC_04). If the WRPRC is absent or invalid, warn the User at approval (RPRC_17).
- The Wallet Unit SHALL NOT display the intermediary or intermediary-Service trade names (RPI_07). It displays the intermediated RP and its Service.
- If the parties so agreed, the intermediary may perform PID/attestation validation on behalf of the RP (delegation of Article 5b(9) checks: OIA_12–OIA_15). What is validated is a contractual choice; the ARF does not mandate the RPI–RP interface, nor end-to-end encryption to the RP. Forward only to that RP; verify if agreed; delete immediately (RPI_08–RPI_10).
- The intermediary forwards attributes to the RP and deletes PIDs, attestations, and transaction-content data immediately (Article 5b(10); ARF §6.6.5).
sequenceDiagram
participant RP as Intermediated RP
participant RPI as Intermediary
participant W as Wallet Unit
participant ACA as Access CA LoTE
participant RCP as WRPRC Provider LoTE
participant ITL as Issuer TLs / LoTEs
RP->>RPI: Which WRPRC to include (RPI_05)
RPI->>W: Presentation request<br/>RPI WRPAC (Reg_34a) + RP WRPRC (RPRC_19)
W->>ACA: Validate RPI WRPAC (RPA_04)
W->>RCP: Validate RP WRPRC (RPRC_17, RPRC_17a, RPRC_04)
Note over W: Display intermediated RP only (RPI_07)
W-->>RPI: Presented attributes
opt Contractual delegation of Art. 5b(9)
RPI->>ITL: Validate PID / QEAA / PuB-EAA / EAA
end
RPI->>RP: Forward attributes (RPI_08/09)
Note over RPI: Delete transaction content (Art. 5b(10), RPI_10)
- Wallet holders must be able to verify both RPI and RP identities
7 Governance Responsibilities
Trust and security responsibilities are split between Member States, the European Commission, and participating entities as follows:
| Responsibility | Owner (normative) | [MVP] | [MVP+] |
|---|---|---|---|
| Registration of PID Providers, Attestation Providers, Relying Parties | Member State Registrar | WE BUILD (mock Registrar) | MS Registrar or WE BUILD |
| Registry publication and common API (e.g. TS5, TS6) | Member State | WE BUILD (the WP4 reference registry or an other WP4 registry listed in LoTL) | Member State or WE BUILD |
| Access certificate issuance | Access Certificate Authority (notified by MS to Commission) | WE BUILD (Access CAs listed in LoTL) | Access CA (notified) or WE BUILD (Access CAs listed in LoTL) |
| Optional registration certificates | Provider of Registration Certificates (notified by MS to Commission) | WE BUILD (WP4 RegCert Providers listed in LoTL) | RegCert Provider (notified) or WE BUILD (WP4 RegCert Providers listed in LoTL) |
| Compilation and publication of Wallet Provider, PID Provider, Access CA, RegCert Provider Trusted Lists | European Commission | WE BUILD (reference TLs) | European Commission or WE BUILD |
| Compilation and publication of national EAA Provider TLs and MS QTSP Trusted Lists for QEAA | Member State Trusted List Provider | WE BUILD (mock MS TLP) | MS TLP or WE BUILD |
| List of Trusted Lists (LoTL), OJEU publication | European Commission | WE BUILD (reference LoTL) | European Commission or WE BUILD |
| Trust evaluation in Wallet Units and RPs (use of TL/LoTE and Registry per ARF) | Wallet / PID / Attestation / RP implementations | Wallet / PID / Attestation / RP implementations | Wallet / PID / Attestation / RP implementations |
Within WE BUILD, the consortium clarifies which roles are assumed by MVP infrastructure (e.g. mock or real Registrars, TLPs, Access CAs) and which are assumed to be provided by Member State or EU infrastructure. Policy and conflicts (e.g. credential-type or authorization collisions) are handled according to the dispute resolution and collision-prevention mechanisms described in the WP4 Trust Group authentication-authorization and policy framework.