Skip to content

Trust Management and Infrastructure

Overview

Trust between the participating parties is a fundamental prerequisite for a functioning EUDI Wallet ecosystem. For personal identities of EU citizens that are issued to Wallets as PIDs, this trust is based on eIDAS regulations and a trust framework with centralized trust lists and certifications of technical implementations.

Note

The following overview shows the main actors and the trust relationships between them for the use case of issuing and presenting a PID. Trust relationships for other use cases, e.g., EAA presentation and QES will be added later.

Trust

Figure 1: High-level overview of trust for PID use case

Note

Only a single PID Provider is planned for the EUDI Ecosystem in Germany at the moment.

Technical Mechanisms

Trust in the Wallet ecosystem is enforced using technical means, allowing automated verification of trust relationships and their revocation.

These mechanisms include:

  • centrally managed trusted lists of qualified trust services (akin to the EU List of Trusted Lists (LOTL) of qualified trust service providers),
  • certificates, e.g., access certificates for authentication,
  • trust chains, to verify the trust status of an issuing PKI for a certificate, and
  • revocation and status lists, e.g., Certificate Revocation Lists (CRL) of invalidated certificates or Token Status Lists (TSL) with status information on issued tokens, see Status Management.

Trust in PID Issuance and Presentation

Note

A more detailed document in this Blueprint about trust validation for the PID use case will follow soon.

The technical implementation of trust relationships for issuing and verifying a presented PID introduces additional actors to the Wallet infrastructure:

  • Platform Provider of the operating environment for a Wallet Unit, e.g., a mobile operating system
  • Wallet Provider, implementing and providing a Wallet solution
  • Wallet Provider Backend, operating as a backend service for installed Wallet units of this provider
  • Registrar to register and manage Relying Parties; in the case of the German Ecosystem, the Ecosystem Management Portal (EMP) will provide the frontend to this registrar
  • Access and Registration Certificate Providers issuing certificates for registered parties

Information about national trusted entities, their roles and digital identities is published and maintained in national trusted lists.

The technical trust architecture for the PID-related use cases is shown in the following figure:

Trust

Figure 2: Technical trust architecture for PID issuance and presentation

This trust architecture is used by several trust-related processes during the lifecycle of a PID, see the structured list below. More information on the management of trust relationships is then given in the following chapters.

Before PID issuance:

  • Wallet app is verified by the Platform Provider and available for installation (e.g. Platform Provider app store)
  • Wallet Provider is included in the national Wallet providers list
  • PID Provider is included in the national PID providers list
  • access certificate and registration certificate providers with their CAs are included into the respective national access certificate and registration certificate providers lists
  • PID Provider is registered and got an access certificate
  • Wallet app is installed on a user device (Wallet Unit) and activated

During PID issuance:

  • Wallet Unit presents a Wallet Attestation and Key Attestation(s) to the PID Provider
  • PID Provider checks the attestations and the Wallet Provider trust status via the national Wallet providers list
  • PID Provider presents its access certificate to the Wallet when requesting eID data from the user's ID card
  • Wallet checks the trust status of the access certificate via the national access certificate providers list and the validity via its revocation list
  • Wallet Unit checks the trust status of the PID Provider via the national PID providers list

Before PID presentation:

  • Relying Party Instance is registered and got access and registration certificate

During PID presentation and validation:

  • Relying Party Instance presents its access certificate and registration certificate to the Wallet Unit when requesting a PID presentation
  • Access and registration certificates of the RP are verified by the Wallet Unit via the national access certificate and registration certificate providers lists and the corresponding revocation / status lists
  • trust status of Wallet and PID Providers is checked by the Relying Party Instance via the national Wallet and PID providers lists

Wallet Trust Management

Within the eIDAS ecosystem, Wallets need to authenticate toward the PID Provider 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" within this document. 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 and associate various Wallet Attestations with this user account.

Before issuing a Wallet Attestation, the Wallet Provider backend checks various inputs, including information from the Platform Provider 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 published on the national Wallet providers list. By presenting the Wallet Attestation during the PID issuance process, the PID Provider may validate the authenticity of the Wallet Unit and verify that certain requirements for PID issuance can be met.

Note

Details of the Wallet Attestation and Key Attestations are currently under discussion and will be added later.

Wallet Providers are published on the national Wallet providers list in their role WALLET_PROVIDER after certification. In Germany this certification is done based on the BSI TR-03189 (draft, not published yet).

During PID presentation, an RP does not directly verify the validity of the Wallet Unit but can do so implicitly by verifying the presented PID.

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 the details are subject to change.

A more detailed, generic flow for the issuance of a Wallet Attestation to the Wallet Unit is shown in this Description of the generic Wallet Attestation flow.

For RPs it would be helpful if all wallet implementations in Europe are sharing the same invocation mechanism. To ensure that only valid Wallets can be addressed we created the following proposal.

PID Provider Trust Management

The PID Provider issues PIDs to Wallet users according to a policy given by eIDAS and requiring Level of Assurance High. Trust in the PID Provider is based on a national certification, in Germany based on the BSI TR-03189. The PID Providers services (issuing and revocation of PIDs) are published in a National Trust List with the role PID_PROVIDER and their digital identity. This includes information about the certificate used by the PID Provider to sign PIDs and status lists.

Additionally, the PID Provider registers at the national registrar and gets an access certificate. Because of the PID Provider publication in the National Trust List there is no need for a registration certificate.

Wallet Providers verify the access certificate of the PID Provider during the issuance process. The trust status and role of the PID provider are checked against the national PID providers list.

RPs do not directly communicate with PID providers but verify presented PIDs. This verification includes the trust status and role of the issuing PID Provider. The national PID providers list provides this information, as well as information about the PID signing certificate to check the PID signature.

Relying Party Trust Management

RPs register as a legal entity at a national registrar to be able to request PID presentations. A part of this registration is the "intended use", capturing which attributes an RP wants to request from Wallets.

After successful validation of the RP's legal identity, an access (X.509) and a registration certificate are issued to the RP. The corresponding certificate providers are published on the national access certificate providers list and registration certificate providers list. Using the EU LOTL, every EUDI Wallet can authenticate and authorize RPs registered in any of the EU member states.

The access certificate is used by the RP to authenticate itself to Wallets. Additional information about the authenticated RP, e.g., the intended use, can be obtained from the registration certificates (or requested from the registrar) and shown to the user to confirm a PID presentation.

The authorization to request PID presentations can be revoked for a given RP by revoking its access certificate.

The concrete mechanisms to register RPs is out of scope of this document.

Transparency features accompany the aforementioned trust mechanisms:

  • The Wallet instance makes all transactions like PID issuance and presentation transparent to the user after the fact, e.g., through a dashboard. Such information should be managed and stored by the Wallet unit only.
  • Registration information of RPs including history is made public in order to ensure that a public audit is possible.