Skip to content

Trust Validation Overview

This chapter defines how a Relying Party establishes trust in PIDs, WALLET UNIT Attestations (WUA), and RP certificates in Germany, using trust lists based on the ETSI TS 119 602 specification.

Trust & Credentialing in the German PID flow.

  • Blue = governance/accreditation
  • Red = operational roles listed in the national TL
  • Green = signed artefact
  • Yellow = trust anchors

Trust Validation Overview

These roles are operated by different entities:

  • Orchestrator: Registrar, Provider of Access Certificates (ACA), Provider of Registration Certificates (PRC)
  • Bundesdruckerei: PID Provider

While these four roles are only represented once in the ecosystem, there will be multiple Wallet Providers and Relying Parties (RPs) operating in the ecosystem.

Actors & Roles

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

  • role: the service type as listed in the TL
  • issues: the artefact(s) issued by that role
  • required evidences: the minimum set of evidences that must be presented to validate the attestations/certificates
  • validates: the artefact(s) that role validates before issuing
  • depends on: other roles that are required to issue or consume the attestations/certificates
Role Issues Required Evidences Validates Depends on
PID PROVIDER Personal Identification (PID) TL entry with Trusted Entity Certificate, intermediate/issuing CA, policy OIDs WUA WALLET PROVIDER, ACA, PRC
WALLET PROVIDER WALLET UNIT Attestation (WUA) - WRPAC, WRPRC. -
WALLET UNIT - TL entry with Trusted Entity Certificate, policy OIDs PID PID PROVIDER, ACA, PRC
REGISTRAR — TL entry with Trusted Entity Certificate; authentic-source access RP identity data National registries
PROVIDER OF ACCESS CERTIFICATES (ACA) Access certificates (WRPAC) TL entry with Trusted Entity Certificate; CA policy; Registrar data RP identity (via Registrar) REGISTRAR
PROVIDER OF REGISTRATION CERTIFICATES (PRC) Registration certificates (WRPRC) TL entry with Trusted Entity Certificate; CA policy; Registrar data RP identity (via Registrar) REGISTRAR
RELYING PARTY (RP) — Access cert (ACA), Registration cert (PRC) PID *

In the Implementing acts, the Provider of Registration Certificates is called Registration Certificate Authority. The WALLET UNIT depends on the PID provider because it will need to validate the PID before storing it.

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 under a CA chaining to a TL-listed Trusted Entity Certificate; access cert (ACA) and registration cert (PRC) 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.

Wallet Provider

  • Keys/Certificates: WUA signing keys under Trusted Entity Certificate.
  • Validation duties: Validate PID signatures; validate ACA/PRC when interacting with RPs.
  • Revocation: Revoke WUA series if compromised/deregistered; publish status.

Registrar

  • Duties: Validate RP identity data from authentic sources; notify ACA/PRC on changes.

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.

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.

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.

National Trust List Content (Schema)

Each member state maintains multiple trust lists:

  • PID Provider TL
  • Wallet Provider TL
  • Registrar TL
  • ACA TL
  • PRC TL

Each lists includes entries for the respective roles, with the following structure:

  • contact information
  • serviceType
  • policySet
  • status (granted/suspended/withdrawn)
  • public keys/certificates (Trusted Entity Certificates)

All lists share the same schema defined in ETSI TS 119 602, with role-specific serviceType and policySet values. The lists will be published by the Member State as a signed JSON Web Token (JWT).

The keys to validate the national trust lists can be fetched from the EU List of Trusted Lists (LoTL) as per eIDAS 2.0 requirements.

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 lists will be also referenced in the EU List of Trusted Lists (LoTL) as per eIDAS 2.0 requirements. The sandbox lists will not be included in the LoTL, 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.