Skip to main content

Trust establishment

In the EUDI Wallet ecosystem, multiple parties must trust each other without prior relationships. A bank in Germany needs to trust a PID issued in Portugal. A wallet in France needs to verify that a Relying Party in Spain is legitimate. Trust establishment defines how this works using government authorities as trust anchors and X.509 certificates as the primary verification mechanism.

For PIDs, QEAAs, PuB-EAAs, and access certificates, interoperability is achieved through a PKI following X.509 certificate standards. Non-qualified EAAs may adopt alternative trust models and verification mechanisms as defined in their Attestation Rulebooks.

The Truvity EUDIW Connector automates trust verification on both sides of the presentation flow.

The trust model​

Government as trust anchor​

Member state governments act as trusted third parties that vouch for ecosystem participants. Instead of parties trusting each other directly, all parties trust the governance framework established by the member states.

All trust paths lead back to government trust anchors. A credential issued in one member state is trusted in another because both chain back to their respective government authorities, and EU member states recognize each other's trust anchors.

Provider registration and notification​

PID Providers and Attestation Providers register with a Registrar in their member state. After successful registration, the member state conditionally notifies the Provider to the European Commission. This notification determines whether the Provider's trust anchors appear in Trusted Lists or Lists of Trusted Entities (LoTEs).

RP registration​

As a Relying Party, you register with a Registrar in your member state. As a result of successful registration, an Access Certificate Authority associated with the Registrar issues X.509 access certificates for your Relying Party Instances. These certificates authenticate your identity to wallets during a presentation request.

The ARF distinguishes between a Relying Party (the legal entity) and Relying Party Instances (the technical systems that interact with Wallet Units). A single Relying Party can operate multiple Relying Party Instances, for example for load distribution or business continuity. Each Relying Party Instance receives its own access certificate.

note

Access certificates authenticate the RP's identity. They do not indicate which data the RP intends to request. That information is provided by registration certificates or the Registrar's online service. See certificates for details on the distinction between access certificates and registration certificates.

Trust infrastructure​

The trust model relies on a hierarchical infrastructure of trust lists:

  1. Trust anchors: Member state authorities maintain trust anchors that are trusted unconditionally within the ecosystem.
  2. Commission trust infrastructure: The European Commission maintains a common trust infrastructure that enables discovery of all Trusted Lists and LoTEs in the ecosystem.
  3. Trusted Lists and LoTEs: Each member state publishes Trusted Lists (for QEAA Providers and PuB-EAA Providers) and Lists of Trusted Entities (for PID Providers, Wallet Providers, Access Certificate Authorities, and Providers of registration certificates).

Access Certificate Authority trust anchors are published in a LoTE. Wallet Units use these trust anchors to verify the certificate chains of access certificates presented by Relying Parties.

To verify a credential or request, systems build a chain of trust from the entity's certificate up to a trust anchor. If the chain is valid and the trust anchor appears in the relevant Trusted List or LoTE, the entity is considered trusted.

RP-to-wallet trust​

When you request credentials, the wallet must verify your identity to prevent phishing and unauthorized data access.

The connector signs your authorization request using the private key associated with your X.509 access certificate. The wallet validates this signature and checks your certificate chain against the trust anchors published in the Access Certificate Authority's LoTE. The wallet also validates the revocation status of every certificate in the trust chain, including the access certificate, any intermediate certificates, and potentially the trust anchor itself. If any certificate in the chain is invalid or revoked, the wallet blocks the request.

To protect the privacy of the response, the connector generates ephemeral encryption keys for each request. The wallet encrypts its response using the ephemeral public key, ensuring only the requesting Relying Party can read it.

Wallet-to-RP trust​

The connector verifies that credentials presented by wallets are authentic, valid, and belong to the user:

  • Issuer signature: Each credential contains a digital signature from the issuer. The connector verifies this signature to confirm the data has not been tampered with and was issued by a valid authority.
  • Key binding: The connector verifies that the presenter controls the private key bound to the credential, proving legitimate possession.
  • Revocation checking: The connector checks the current status of the credential to ensure it has not been revoked by the issuer.

Trust in different environments​

The trust model adapts to the deployment environment:

  • Production: Uses CA-issued certificates from member state accredited Registrars. The trust chain links back to official government trust anchors published in Trusted Lists and LoTEs.
  • Sandbox: Uses self-signed certificates generated automatically by the connector. These allow you to test the full flow without requiring official registration. In this mode, the wallet or test tool must be configured to trust the self-signed certificates explicitly.

Further reading​