National EUDI Wallet Trust List Publication Procedure
1. Purpose and Scope
Until the relevant EUDI Wallet ecosystem entities are reliably available through the European Commission trust infrastructure, a national mechanism is required to publish the trust anchors needed for operation of the German EUDI Wallet ecosystem.
The national trust infrastructure covers five roles:
- PID Providers;
- Wallet Providers;
- Wallet Relying Party Access Certificate Providers (WRPAC Providers / Access Certificate Providers);
- Wallet Relying Party Registration Certificate Providers (WRPRC Providers / Registration Certificate Providers); and
- Registrars and Registers.
Public-sector EAA Providers are outside the scope of this procedure.
The national solution is intended as a temporary mechanism until the corresponding European Commission infrastructure can be used operationally. No fixed end date is defined; operation may be required for one or several years.
The solution is based on the List of Trusted Entities (LoTE) data model defined in ETSI TS 119 602. ETSI defines separate profiles for PID Providers, Wallet Providers, WRPAC Providers, WRPRC Providers, Public EAA Providers and Registrars/Registers. (ETSI)
1.1 Separation from the existing German eIDAS Trusted List
The existing German eIDAS Trusted List is designed for trust service providers and trust services. It does not provide the EUDI-specific role model required to determine, for example, whether an entity is authorized as a PID Provider, Wallet Provider or Registrar.
A separate national EUDI Wallet LoTE infrastructure is therefore established.
The term National EUDI LoTE is used to distinguish this infrastructure from the existing eIDAS Trusted List infrastructure.
2. Scheme Operator
The LoTE Scheme Operator is:
Common Codes GmbH
Common Codes GmbH is responsible for establishing, maintaining, signing and publishing the national EUDI LoTEs and for operating the associated controlled publication process.
The SchemeOperatorName of the lists SHALL identify Common Codes GmbH consistently with the identity contained in the certificate used for signing the lists.
3. Architecture
A separate LoTE SHALL be maintained for each of the five supported roles.
A legal entity MAY occur in more than one LoTE where it has been authorized for more than one role.
Example:
An entry in one LoTE SHALL NOT imply authorization for another role.
This design follows the role separation of the European Commission-oriented profiles defined by ETSI TS 119 602. For example, ETSI defines EUPIDProvidersList specifically for lists of PID Providers notified by Member States. (ETSI)
A single combined list containing all roles was considered but is not used. Separate lists provide clearer semantics and allow existing implementations to determine the intended role directly from the LoTE type.
4. National Derivation from the European Commission Approach
The national lists are designed as a national derivation of the European Commission LoTE profiles defined in ETSI TS 119 602.
The objective is to remain as close as possible to the final European structure so that consumers do not require a separate German-specific LoTE parser.
4.1 LoTE types
The corresponding ETSI LoTE type identifiers SHALL be reused:
| National list | LoTE type |
|---|---|
| PID Providers | http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList |
| Wallet Providers | http://uri.etsi.org/19602/LoTEType/EUWalletProvidersList |
| WRPAC Providers | http://uri.etsi.org/19602/LoTEType/EUWRPACProvidersList |
| WRPRC Providers | http://uri.etsi.org/19602/LoTEType/EUWRPRCProvidersList |
| Registrars & Registers | http://uri.etsi.org/19602/LoTEType/EURegistrarsAndRegistersList |
This preserves the role semantics used by ETSI and reduces implementation differences between the temporary national infrastructure and the future European infrastructure.
4.2 Scheme territory
The national lists SHALL use:
SchemeTerritory = "DE"
This is a deliberate national derivation from the corresponding European Commission profile.
ETSI defines SchemeTerritory as the country or territory in which the scheme is established and applies. (ETSI)
The ETSI EU-specific PID Provider profile specifies SchemeTerritory = "EU". (ETSI)
For the temporary national infrastructure, however:
- the scheme is established in Germany;
- the Scheme Operator is Common Codes GmbH;
- the signing certificate identifies the German Scheme Operator; and
- the scheme applies to the German national interim infrastructure.
DE therefore represents the actual national scheme more accurately.
The national lists SHALL consequently not be presented as lists published by the European Commission. They are ETSI TS 119 602-based national LoTEs derived from the corresponding EU profiles.
4.3 Other scheme-specific metadata
Where ETSI EU profiles contain values whose semantics specifically refer to a European Commission-operated scheme, the national LoTE SHALL contain national scheme information where necessary.
In particular, the following SHALL describe the national scheme operated by Common Codes GmbH:
SchemeOperatorName;SchemeOperatorAddress;SchemeInformationURI;- applicable scheme rules or policy information;
PolicyOrLegalNotice;SchemeTerritory.
The entity structures, service types and LoTE types SHALL otherwise remain as close as possible to the corresponding ETSI EU profiles.
5. Root of Trust
The authenticity of a published national LoTE SHALL be established cryptographically and SHALL NOT depend solely on the security of the hosting platform.
5.1 Qualified electronic seal
Common Codes GmbH SHALL obtain a qualified electronic seal from a QTSP.
The intended certificate lifetime is equal or more than two years.
The seal SHALL be used to sign the national LoTEs.
ETSI TS 119 602 requires LoTEs to be signed using an AdES signature at Baseline B level. (ETSI)
For the PID Provider profile, ETSI specifically requires a compact JAdES Baseline B signature. The corresponding Wallet, WRPAC and WRPRC profiles use the same approach. (ETSI)
The national JSON LoTEs SHALL therefore use compact JAdES Baseline B.
5.2 Publication of the signing certificate
The complete certificate used to sign the LoTEs SHALL be published by BMDS in the Bundesanzeiger.
This publication establishes an independent, authoritative binding between the national LoTE infrastructure and the certificate of Common Codes GmbH.
The Bundesanzeiger is not expected to provide a convenient machine-readable bootstrap mechanism. This is intentional: the publication provides the authoritative out-of-band trust anchor rather than serving as the operational distribution endpoint.
A comparable trust-bootstrap concept exists in the European trust-list infrastructure, where information published by the European Commission includes the locations of national Trusted Lists and the certificates used to sign them.
6. Publication and Freshness
Every LoTE SHALL be freshly generated and signed at least once every three months.
Example:
ListIssueDateTime: 2026-10-01T00:00:00Z
NextUpdate: 2027-01-01T00:00:00Z
The corresponding ETSI EU PID Provider profile permits a maximum interval of six months between ListIssueDateTime and NextUpdate.
The national three-month interval therefore provides a stricter freshness policy.
A new version SHALL also be published whenever a trust-relevant change has to be reflected before the scheduled publication.
7. Deployment Endpoints
The national EUDI LoTEs are published in two separate environments to support both production and testing scenarios.
7.1 Production Deployment
The production deployment serves the operational German EUDI Wallet ecosystem.
Endpoint: https://trustlists.eudihub.de
This is the authoritative source for all national LoTEs consumed by production wallet implementations and relying parties.
7.2 Sandbox Deployment
The sandbox deployment provides a testing environment for wallet providers, PID providers, EAA providers, and relying parties to validate their implementations against test trust lists.
Endpoint: https://trustlists-sandbox.eudihub.de
The sandbox LoTEs follow the same technical structure and update requirements as production LoTEs, enabling functional testing without affecting production operations.
The sandbox environment allows ecosystem participants to:
- Test integration with dynamic trust list retrieval
- Validate trust list validation and verification logic
- Prepare for production deployment with realistic trust infrastructure
- Develop and test support for new entity types before production rollout