Trust in the Wallet Ecosystem
When a wallet receives a credential from an issuer, or responds to a request from a verifier, it needs a way to answer a simple question: can this party be trusted? Because you choose your wallet from any certified provider and a verifier may be an organisation you have never dealt with, that link cannot be assumed; it has to be proven. A valid cryptographic signature proves that a credential was not tampered with, but it does not, on its own, prove who the signer is or whether that signer is a recognised, accountable entity. Establishing that link between a key and a real, recognised organisation is the job of a trust framework.
This page explains how the iGrant.io Data Wallet and Organisation Wallet establish trust in the parties they interact with, the trust mechanisms they support, and how the result of that check is shown to the user.
The bigger picture: Layers of trust
Trust in the EU Digital Identity ecosystem is not a single check but several layers, each resting on the one below. It helps to see where the checks on this page fit.
- Legal foundation. eIDAS 2.0 and its Implementing Acts define the roles, certification and supervision for everyone.
- Ecosystem trust (who is who). Trusted Lists record which providers, issuers and relying parties are recognised, so parties that have never met can verify each other.
- Wallet and device trust. The Wallet Unit Attestation proves a wallet is genuine and that its keys are in secure hardware. See Wallet Unit Attestation (WUA).
- Credential trust. Credentials are signed by trusted issuers and bound to the holder's keys, so they cannot be forged or copied.
- Transaction trust. At each exchange, the parties prove themselves before any data is shared.
This page focuses on Layer 2: how the wallet checks that an issuer or verifier is a recognised entity (against the EU Trust List and related mechanisms), and how it surfaces the result (Layer 5).
What is being checked
This page concentrates on the ecosystem-trust layer: confirming that an issuer or verifier is a recognised entity. The other layers are covered in separate articles, for example Wallet Unit Attestation (WUA) for wallet and device trust and the credential issuance lifecycle for how credentials are issued and bound to the holder.
Trust is evaluated for the two roles a wallet interacts with:
- Issuers, also called service providers in the wallet interface, who issue credentials into the wallet during an issuance (OpenID4VCI) flow.
- Verifiers, also called relying parties, who request credentials from the wallet during a presentation (OpenID4VP) flow.
In both cases the wallet attempts to match the party's identity (for example, its certificate, decentralised identifier, or registered entity details) against one or more trusted sources. If a match is found, the party is treated as trusted and its verified details can be shown to the user. If no match is found, the wallet displays a "not verified" notice. See The "not verified" provider notice for what that notice means and how to resolve it.
Supported trust mechanisms
The wallet can validate issuers and verifiers against several trust mechanisms. The most relevant for European Digital Identity (EUDI) scenarios is the EU Trust List.
| Mechanism | Description |
|---|---|
| EU Trust List (as per ETSI TS 119 612) | Each EU member state publishes a trusted list of qualified and non-qualified trust service providers. These national lists are aggregated through the European List of Trusted Lists (LoTL). The wallet checks whether the issuer or verifier appears on a list it validates against. Most established issuers in the EUDI framework are included. |
| EBSI | The European Blockchain Services Infrastructure trust model, where an issuer is onboarded through a trust chain (Root Trust Anchor Operator, Trust Anchor Operator, Trusted Issuer) and recorded in the EBSI Trust Registry. |
| X.509 certificates | Trust is anchored in a Public Key Infrastructure (PKI) certificate chain that terminates at a recognised root or intermediate certificate authority. |
| Verifier knows Issuers | A configured allow list of issuers that a given verifier deployment chooses to trust directly. |
| OpenID Federation | Trust established through an OpenID Federation trust chain. Support is on the roadmap (coming soon). |
The mechanisms available to a specific deployment depend on how its trust authorities are configured. See the Trust Anchor APIs and the trust authority configuration endpoints for how these are managed.
EU Trust List validation versus Trust Anchor onboarding
These two terms are easy to confuse, so it is worth being precise about the difference.
- EU Trust List validation answers "is this issuer or verifier on a recognised trusted list?". It is a lookup the wallet performs against published trusted lists (ETSI TS 119 612 and the LoTL). It is the mechanism most often behind the "not verified" notice.
- Trust Anchor onboarding is the process of registering an entity into a trust framework, so that it becomes trusted in the first place. The exact mechanism depends on the framework. In EBSI, for example, it is the trust chain of Root TAO, TAO and Trusted Issuer, exposed through the Trust Anchor APIs. Onboarding can also be established by other means, such as X.509 certificates: this is how a relying party is registered on the NXD Test Network so the Data Wallet treats it as trusted, described in Register as a Wallet-Relying Party.
In short: onboarding puts an entity into a trust framework, and trust list validation checks an entity against the trusted lists at the time of issuance or presentation. An issuer that has not been onboarded to any framework the wallet recognises, and that does not appear on a trusted list the wallet validates against, will be shown as an untrusted service provider.
How trust status is surfaced
After the wallet evaluates a party, the outcome is exposed both in the wallet interface and in the API. For a presentation flow, the verification response includes:
isVerifiedWithTrustList: a boolean indicating whether the party was matched against a configured trust list.trustServiceProvider: an object carrying the verified trust service provider details when a match is found.
When isVerifiedWithTrustList is false, the wallet shows the "not verified" notice to the user.