Trust Validation Overview¶

This chapter defines how ecosystem participants establish and validate trust in the German EUDI Wallet ecosystem. It covers the validation of PIDs, Wallet Unit Attestations (WUA), and Wallet Relying Party certificates, using trust lists based on the ETSI TS 119 602 specification.

Credential-type-specific trust anchors

This chapter defines who is trusted (roles, trust lists, certificates). For credential-type-specific trust anchors—which issuers are authorized for which EAA types—see the Catalogue of Attestations. The catalog's trustedAuthorities field references the trust lists defined in this chapter.

Actors & Roles¶

The following table summarizes the roles and the dependencies for trust validation.

A Wallet Relying Party (WRP) is any entity that interacts with the Wallet Unit via digital interaction. This includes all attestation providers (PID, EAA, QEAA, PubEAA) and Relying Parties. All WRPs require Access Certificates (WRPAC) and Registration Certificates (WRPRC) to interact with the wallet.

Role	WRP	Issues	Credentials Needed	Validates
PID PROVIDER	✓	Person Identification Data (PID)	WRPAC	WUA
EAA PROVIDER	✓	Electronic Attestation of Attributes	WRPAC, WRPRC	WUA (optional)
QEAA PROVIDER	✓	Qualified Electronic Attestation of Attr.	WRPAC, WRPRC, TL entry	WUA (optional)
PubEAA PROVIDER	✓	Public Electronic Attestation of Attr.	WRPAC, WRPRC, TL entry	WUA (optional)
RELYING PARTY (RP)	✓	—	WRPAC, WRPRC	PID, attestations
WALLET PROVIDER	—	Wallet Unit Attestation (WUA)	TL entry	—
WALLET UNIT	—	—	WUA	PID, WRPAC, WRPRC
REGISTRAR	—	—	TL entry	WRP identity data
PROVIDER OF ACCESS CERTIFICATES (ACA)	—	Access Certificates (WRPAC)	TL entry	WRP identity (via Registrar)
PROVIDER OF REGISTRATION CERTIFICATES (PRC)	—	Registration Certificates (WRPRC)	TL entry	WRP identity (via Registrar)

Column definitions

WRP: Indicates if the role is a Wallet Relying Party (interacts with wallet via digital interaction)
Issues: The artefact(s) issued by that role
Credentials Needed: What the role needs to operate (either certificates or a Trust List entry)
Validates: What the role validates before issuing or accepting credentials

In the Implementing Acts, the Provider of Registration Certificates is called Registration Certificate Authority.

PID provider without WRPRC

The PID Provider does not need a registration certificate since we will have only one entity in the German ecosystem issuing PIDs. Therefore, the PID Provider can be uniquely identified by its access certificate (WRPAC) alone.

Wallet Provider vs. Wallet Unit

Wallet Provider and Wallet Unit are distinct roles with different responsibilities:

Wallet Provider: The organization operating the backend infrastructure that issues Wallet Unit Attestations (WUA).
Wallet Unit: The application instance running on the user's device that holds credentials and performs cryptographic operations.

The Wallet Provider issues the WUA to authenticate the Wallet Unit towards the PID Provider during issuance flows.

Role-Specific Notes¶

PID Provider¶

Keys/Certificates: PID signing keys (for PIDs and for status lists) under a CA chaining to a TL-listed Trusted Entity Certificate; access cert (ACA) for service access as needed.
Validation duties: Validate WUA; validate payload from authentic source to issue PID.
Revocation: Revoke PID signing and access certs promptly; publish CRL.

PID Provider Notification Requirements

Per Commission Implementing Regulation (EU) 2024/2980 (Art. 4-5), Germany must:

Notify the European Commission of the PID Provider information with serviceTypeIdentifier values:
- http://uri.etsi.org/19602/SvcType/PID/Issuance for the issuance service
- http://uri.etsi.org/19602/SvcType/PID/Revocation for the revocation service
The Commission establishes, maintains and publishes the EU PID Providers List (http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList) compiling information from all Member States.

There is no separate national list for PID Providers; the EC-published list is the authoritative source for cross-border trust discovery.

EAA Provider¶

Keys/Certificates: Attestation signing keys; access cert (WRPAC) and registration cert (WRPRC) for wallet interaction.
Validation duties: Validate WUA (optional); verify user identity/entitlements from authentic sources.
Revocation: Revoke attestation signing certs and status credentials as needed.

QEAA Provider¶

Keys/Certificates: Qualified attestation signing keys under TL-listed Trusted Entity Certificate; access cert (WRPAC) and registration cert (WRPRC) for wallet interaction.
Validation duties: Validate WUA (optional); verify user identity/entitlements; meet QTSP requirements.
Revocation: Revoke attestation signing certs and status credentials; comply with QTSP revocation obligations.

QEAA Provider Publication Requirements

QEAA Providers are Qualified Trust Service Providers (QTSPs) and are published in the national eIDAS Trusted List (ETSI TS 119 612), not in the TS 119 602 LoTE.

Per eIDAS 2.0 requirements, Germany must:

Publish each QEAA Provider in the national eIDAS Trusted List with the appropriate QTSP service type.
The Commission aggregates national eIDAS Trusted Lists into the EU List of Trusted Lists (LoTL).

Each entry must include:

Appropriate status (granted/suspended/withdrawn)
Certificate chains to a Trusted Entity Certificate (TEC) published in the same trust list
Required service metadata and contact information

PubEAA Provider¶

Keys/Certificates: Public attestation signing keys under TL-listed Trusted Entity Certificate; access cert (WRPAC) and registration cert (WRPRC) for wallet interaction.
Validation duties: Validate WUA (optional); verify data from authentic source under public authority responsibility.
Revocation: Revoke attestation signing certs and status credentials as needed.

PubEAA Provider Notification Requirements

Per Commission Implementing Regulation (EU) 2024/2980 (Art. 4-5), Germany must:

Notify the European Commission of each PubEAA Provider with serviceTypeIdentifier values:
- http://uri.etsi.org/19602/SvcType/PubEAA/Issuance for the issuance service
- http://uri.etsi.org/19602/SvcType/PubEAA/Revocation for the revocation service
The Commission establishes, maintains and publishes the EU PubEAA Providers List (http://uri.etsi.org/19602/LoTEType/EUPubEAAProvidersList) compiling information from all Member States.

Each notification must include:

Appropriate status (granted/suspended/withdrawn)
Certificate chains to a Trusted Entity Certificate (TEC)
Required service metadata and contact information

There is no separate national list for PubEAA Providers; the EC-published list is the authoritative source for cross-border trust discovery.

Wallet Provider¶

Keys/Certificates: WUA signing keys under Trusted Entity Certificate.
Validation duties: Validate device attestation and Wallet Unit integrity before issuing WUA.
Revocation: Revoke WUA series if compromised/deregistered; publish status.

Wallet Provider Notification Requirements

Per Commission Implementing Regulation (EU) 2024/2980 (Art. 4-5), Germany must:

Notify the European Commission of each Wallet Provider with serviceTypeIdentifier values:
- http://uri.etsi.org/19602/SvcType/WalletSolution/Issuance for the issuance service
- http://uri.etsi.org/19602/SvcType/WalletSolution/Revocation for the revocation service
The Commission establishes, maintains and publishes the EU Wallet Providers List (http://uri.etsi.org/19602/LoTEType/EUWalletProvidersList) compiling information from all Member States.

The notification must include the Wallet Provider's Trusted Entity Certificate (TEC) and WUA signing keys. This is necessary so that:

PID Providers can validate WUA authenticity
Verifiers can check the authenticity of Wallet Unit Attestations
Cross-border wallet interoperability is ensured through the EU-published list

There is no separate national list for Wallet Providers; the EC-published list is the authoritative source for cross-border trust discovery.

Registrar¶

Duties: Validate RP identity data from authentic sources; notify ACA/PRC on changes; host and maintain the Catalogue of Attestations.

Registrar Notification Requirements

Per Commission Implementing Regulation (EU) 2024/2980 (Art. 4-5), Germany must:

Notify the European Commission of each Registrar with serviceTypeIdentifier set to http://uri.etsi.org/19602/SvcType/Register.
The Commission establishes, maintains and publishes the EU Registrars and Registers List (http://uri.etsi.org/19602/LoTEType/EURegistrarsAndRegistersList) compiling information from all Member States.

There is no separate national list for Registrars; the EC-published list is the authoritative source for cross-border trust discovery.

Access CA (ACA)¶

Duties: Issue access certs to RPs after Registrar validation.
Revocation: Revokes certificates when not aligned with Registrar anymore. Publish status list for issued certs.

Access CA Notification Requirements

Per Commission Implementing Regulation (EU) 2024/2980 (Art. 4-5), Germany must:

Notify the European Commission of each Access CA with serviceTypeIdentifier values:
- http://uri.etsi.org/19602/SvcType/WRPAC/Issuance for the issuance service
- http://uri.etsi.org/19602/SvcType/WRPAC/Revocation for the revocation service
The Commission establishes, maintains and publishes the EU WRPAC Providers List (http://uri.etsi.org/19602/LoTEType/EUWRPACProvidersList) compiling information from all Member States.

There is no separate national list for Access CAs; the EC-published list is the authoritative source for cross-border trust discovery.

Provider of Registration Certificates (PRC)¶

Duties: Issue registration certs to RPs after Registrar validation.
Revocation: Revokes certificates when not aligned with Registrar anymore. Publish status list for issued certs.

PRC Notification Requirements

Per Commission Implementing Regulation (EU) 2024/2980 (Art. 4-5), Germany must:

Notify the European Commission of each PRC with serviceTypeIdentifier values:
- http://uri.etsi.org/19602/SvcType/WRPRC/Issuance for the issuance service
- http://uri.etsi.org/19602/SvcType/WRPRC/Revocation for the revocation service
The Commission establishes, maintains and publishes the EU WRPRC Providers List (http://uri.etsi.org/19602/LoTEType/EUWRPRCProvidersList) compiling information from all Member States.

There is no separate national list for PRCs; the EC-published list is the authoritative source for cross-border trust discovery.

Relying Party (RP)¶

Holds: Access + registration certificates.
Duties: Validate presented PID; monitor own certificate expiry/rotation.

Revocation semantics (applies to all): Treat revoked as deny. unknown/network errors are policy-defined; for PID/WUA issuer checks Germany adopts fail-closed.

EU Trust Lists (Schema)¶

Per Commission Implementing Regulation (EU) 2024/2980, Member States notify the European Commission of their trusted entities. The Commission then establishes, maintains and publishes the Lists of Trusted Entities following the ETSI TS 119 602 specification as signed JSON documents (JWS). Each role type has its own list structure as defined in the specification's Annexes D-I.

There are no separate national trust lists for these roles. The EC-published lists are the single authoritative source, compiling notifications from all Member States into separate EU-wide lists per role type:

Each service entry in the trust list follows the TS 119 602 schema (see Annexes D-I for role-specific profiles), containing:

entity — the organization operating the service
serviceTypeIdentifier — canonical identifier for the service type (Issuance/Revocation)
policySet — applicable policies
status — current status (granted, suspended, withdrawn)
Certificates — trust anchors and signing certificates
Metadata — contact information and additional attributes

Separate Lists per Role Type

TS 119 602 defines separate profiles and list types for each role (Annexes D-I). The Commission establishes, maintains and publishes separate EU-wide lists for each role type, compiling notifications from all Member States. There are no national trust lists to aggregate—the EC-published lists are the authoritative source.

Service Type Identifier Mapping¶

The following table maps ecosystem roles to their canonical serviceTypeIdentifier values as defined in ETSI TS 119 602 (Annexes D-I):

Role	serviceTypeIdentifier
PID Provider (Issuance)	`http://uri.etsi.org/19602/SvcType/PID/Issuance`
PID Provider (Revocation)	`http://uri.etsi.org/19602/SvcType/PID/Revocation`
Wallet Provider (Issuance)	`http://uri.etsi.org/19602/SvcType/WalletSolution/Issuance`
Wallet Provider (Revocation)	`http://uri.etsi.org/19602/SvcType/WalletSolution/Revocation`
WRPAC Provider (Issuance)	`http://uri.etsi.org/19602/SvcType/WRPAC/Issuance`
WRPAC Provider (Revocation)	`http://uri.etsi.org/19602/SvcType/WRPAC/Revocation`
WRPRC Provider (Issuance)	`http://uri.etsi.org/19602/SvcType/WRPRC/Issuance`
WRPRC Provider (Revocation)	`http://uri.etsi.org/19602/SvcType/WRPRC/Revocation`
PubEAA Provider (Issuance)	`http://uri.etsi.org/19602/SvcType/PubEAA/Issuance`
PubEAA Provider (Revocation)	`http://uri.etsi.org/19602/SvcType/PubEAA/Revocation`
Register	`http://uri.etsi.org/19602/SvcType/Register`

LoTE Type URIs¶

TS 119 602 defines the following LoTE type URIs (see Annex C.2.1) for the aggregated EU lists:

LoTE Type	URI
PID Providers List	`http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList`
Wallet Providers List	`http://uri.etsi.org/19602/LoTEType/EUWalletProvidersList`
WRPAC Providers List	`http://uri.etsi.org/19602/LoTEType/EUWRPACProvidersList`
WRPRC Providers List	`http://uri.etsi.org/19602/LoTEType/EUWRPRCProvidersList`
PubEAA Providers List	`http://uri.etsi.org/19602/LoTEType/EUPubEAAProvidersList`
Registrars and Registers List	`http://uri.etsi.org/19602/LoTEType/EURegistrarsAndRegistersList`

Service Type Identifiers

Service type identifiers distinguish between Issuance and Revocation services. Implementers should refer to ETSI TS 119 602 Annexes D-I for the complete profile specifications for each role.

Sandbox vs. Production Environments¶

Both environments are following the same architecture and validation rules, but are strictly separated:

Separate TL URLs/signing keys, PKIs, policy OIDs, DNS/SANs, CRL endpoints.
Clients for SANDBOX must only trust SANDBOX TL; ditto for PROD.
Prefer short-lived certs in TEST; re-issue under PROD PKI for go-live.

The production trusted entities will be notified to the European Commission and included in the respective EU Lists of Trusted Entities (per role type) as per Commission Implementing Regulation (EU) 2024/2980. The sandbox trusted entities will not be notified to the EC, but the endpoints will be made available in the Sandbox environment for testing purposes.

Validation flow

The development guide will provide detailed validation flow to help implementers understand how to validate the various artefacts using the trust lists.

Wallet Attestation¶

Within the eIDAS ecosystem, Wallets need to authenticate toward PID Providers and EAA issuers to prove their authenticity and trustworthiness. Therefore, Wallet Providers issue assertions regarding particular Wallet Units. These assertions are referred to as Wallet Attestation and Key Attestation.

Attestation Flow¶

Before issuing a Wallet Attestation, the Wallet Provider backend checks various inputs, including information from the Platform Provider (e.g., mobile OS) about the integrity and version of the Wallet app on the user's device.
Wallet Attestation and Key Attestations are signed by the Wallet Provider backend.
The corresponding Wallet Provider certificates are included in the EU Wallet Providers List (published by the EC based on MS notifications).
By presenting the Wallet Attestation during issuance, the PID Provider validates the authenticity of the Wallet Unit.

There may be multiple Key Attestations from a Wallet Unit during one OpenID4VCI flow. The Wallet Provider may set up a pseudonymous user account for a particular user during the installation and activation of the Wallet Unit.

Technical Format¶

For the OpenID for Verifiable Credentials protocol family, the Wallet Attestations are JWTs conforming to the definition given in the OpenID4VC High Assurance Interoperability Profile with SD-JWT VC.

The Wallet Attestation mechanism (OAuth 2.0 Attestation-Based Client Authentication) is yet to be finalized, so details are subject to change.

Implementation Details

A detailed flow for the issuance of a Wallet Attestation to the Wallet Unit is available in the Wallet Attestation flow description.

Wallet Invocation¶

For Relying Parties it would be helpful if all wallet implementations in Europe share the same invocation mechanism. To ensure that only valid Wallets can be addressed, see the EUDI-link governance proposal.

Transparency and Auditability¶

Transparency features accompany the trust mechanisms:

User transparency: The Wallet Unit makes all transactions (PID/EAA issuance and presentations) transparent to the user, e.g., through a dashboard. This information is managed and stored by the Wallet Unit only.
Public auditability: Registration information of RPs, including history, is made public to ensure that public audit is possible.