Skip to main content

Certificates in EUDI

In the EUDI Wallet ecosystem, trust is bidirectional. While the Relying Party (RP) verifies the user's credentials, the EUDI Wallet must also verify the RP's identity before presenting sensitive personal data. This verification relies on certificates issued as part of the RP registration process.

Certificate types​

The EUDI ecosystem defines two certificate types for Relying Parties. These are fundamentally different technical artifacts despite both being called "certificates."

Access certificates​

An access certificate is an X.509 certificate that binds your organization's identity to a public key. EUDI Wallets use this certificate to verify who is requesting data and to confirm that the request has not been tampered with.

When the Truvity EUDIW Connector creates an authorization request, it signs the request using the private key associated with your access certificate (referred to as the "signing identity key" in the connector's configuration). The wallet validates the signature, checks the certificate chain against trusted roots, and verifies that the certificate has not been revoked. Only after these checks pass does the wallet show the consent screen to the user.

Access certificates identify the entity but do not indicate the entity type (Relying Party, PID Provider, or attestation provider) or the attestation types the entity has registered to issue or request. That information is provided by registration certificates or the Registrar's online service.

Access certificates may be logged in Certificate Transparency logs per CIR 2025/848, enabling detection of erroneously or fraudulently issued certificates.

Registration certificates​

A registration certificate is a signed data object, formatted as a JWT or CWT, that describes your organization's registered intended uses and indicates which attributes you have registered to intend to request from users. Unlike access certificates, registration certificates are not X.509 certificates.

note

Registration certificates are optional. Whether they are issued depends on Member State policy. When registration certificates are not available, the wallet retrieves the same information from the Registrar's online service using the Registrar URL and Relying Party identifier from the presentation request.

How the connector uses certificates​

The connector uses your access certificate in the OID4VP protocol flow. When you create a presentation request, the connector signs the authorization request using the private key associated with your access certificate (the signing identity key). The signed request includes your certificate chain, allowing the wallet to:

  1. Verify the signature to confirm the request has not been altered.
  2. Validate the certificate chain from your certificate up to a trusted root recognized by the wallet.
  3. Check that the certificate has not been revoked.

If any check fails, the wallet rejects the request. For details on wallet-facing error responses, see Error codes.

Your responsibilities​

You are responsible for obtaining and managing your own certificates:

  • Obtain certificates: Get your X.509 access certificate from an Access Certificate Authority associated with the Registrar in your member state.
  • Configure the connector: Provide your certificate and the associated private key (signing identity key) to the connector at deployment time.
  • Monitor expiration: Track certificate validity and handle renewals before expiration.
  • Handle revocation: If a private key is compromised, revoke the certificate and deploy a new one. Wallets check revocation status and reject requests signed with revoked certificates.

Sandbox and development​

For development and testing, the connector can generate self-signed certificates automatically. These allow you to test the full verification flow without obtaining a production certificate. Production EUDI Wallets reject self-signed certificates because they do not chain to a trusted root. Use development-enabled wallets or test harnesses for integration testing.

Trust anchors​

The ARF defines a trust anchor as a combination of a public key and the identifier of the associated entity. For a certificate to be accepted by a production EUDI Wallet, it must chain up to a trust anchor published in a List of Trusted Entities (LoTE). Access Certificate Authority trust anchors are published in LoTEs, and wallets use these to verify the certificate chains of access certificates presented by Relying Parties.

Revocation​

Certificates can be revoked before they expire (for example, if a private key is compromised). Wallets check revocation status using mechanisms defined in the certificate. If your certificate is revoked, wallets stop accepting presentation requests signed with that certificate until you deploy a new valid one.

Further reading​

  • Encryption and key management—how the connector manages signing and encryption keys, including the signing identity key used with access certificates
  • OID4VP protocol—the protocol that uses signed authorization requests to verify credentials between wallets and Relying Parties
  • Trust establishment—how wallets, attestation providers, and Relying Parties establish mutual trust using government authorities as trust anchors
  • Trust lists—how Trusted Lists and Lists of Trusted Entities publish the trust anchors that wallets use to validate certificate chains