The "Issuer / service provider not verified" notice
While using the iGrant.io Data Wallet you may see an "Issuer not verified" notice when receiving a credential from an issuer, or a "Service provider not verified" notice when responding to a verifier. This page explains what the notice means, when it appears, and what you can do about it.
What it means
The notice is a trust status indicator. It means the credential's issuer (or, during a presentation, the verifier) could not be matched against a recognised trust list that the wallet validates against, primarily the EU Trust List (ETSI TS 119 612).
When it appears
The notice can appear in either direction of a credential exchange, with wording matched to the context:
- During issuance (OpenID4VCI), "Issuer not verified": when a credential is offered by an issuer that the wallet cannot match to a trust list it validates against. This is common when evaluating credentials from an issuer other than iGrant.io's own issuer.
- During presentation (OpenID4VP), "Service provider not verified": when a verifier requesting credentials cannot be matched to a trust list.
What you see in the wallet
Trusted providers are shown with a verified badge and their trust service provider details, the entry matched on the trust list.
Providers that cannot be verified trigger a warning popup (a bottom sheet) instead of continuing silently. It contains:
- a heading, "Issuer not verified" (issuance) or "Service provider not verified" (presentation), with the subtitle "Not found on the Trust List";
- a warning that the party's identity could not be verified against the trust list, so the credential is not trustworthy, and that the details shown were supplied by the party and are unverified;
- the organisation name, marked "Self-declared, not verified"; and
- an "Are you the operator of this service?" prompt with a "Register your service" button for getting listed (see How to resolve it).
Trusted versus untrusted
The wallet's trust check is reflected in the records of the holder wallet: a credential has credentialSignerTrustedListCheck for its signer, and a presentation has relyingPartyTrustedListCheck for the signer of the relying party's request. A verifier reads the trust result of each issuer in presentationValidity[].credentialSignerTrustedListCheck of its verification record.
| Wallet display | API state | Meaning |
|---|---|---|
| Trusted Service Provider (verified provider details shown) | For an issuer, credentialSignerTrustedListCheck of the held credential; for a verifier, relyingPartyTrustedListCheck of the presentation: verified: true, result: trusted, entry has the provider | The issuer or verifier was matched in one of the organisation's trust sources for the role, and its trust service provider details are available. |
| Issuer not verified (when a credential is received) | credentialSignerTrustedListCheck of the held credential: verified: false; result is not_found, not_trusted (with reason) or error | None of the organisation's trust sources trusts the issuer for the role. |
| Service provider not verified (when a credential is presented) | relyingPartyTrustedListCheck of the presentation: verified: false; result is not_found, not_trusted (with reason) or error | None of the organisation's trust sources trusts the verifier for the role. |
| No trust check (the Require switch is off) | verified: false, result: not_applicable, reason.code: not_required; presentedCertificates keeps the certificates of the signer | The organisation does not check this party: requiresTrustedCredentialSigner or requiresTrustedRelyingParty of the holder configuration is off. |
How to resolve it
If you are an integrator and want an issuer or verifier to be recognised rather than flagged, the entity needs to become discoverable through a trust mechanism the wallet validates against.
For development and piloting, the quickest path is to get listed on the iGrant.io recognised Trust List, operated as a test network. See Register as a Wallet-Relying Party. For production, the main options are:
- Be listed on an EU member state trusted list. Qualified and non-qualified trust service providers are published on national trusted lists aggregated through the European List of Trusted Lists (LoTL), as per ETSI TS 119 612. This is the primary path for EUDI scenarios.
- Be listed on an EU list of trusted entities. The ETSI TS 119 602 lists name the wallet providers, PID providers and PuB-EAA providers, as well as the providers of access and registration certificates for relying parties.
- Be added to the organisation's trust sources. An organisation can add the CA certificates (trust anchors) and the lists that it trusts, each used for one role, with the Trust Sources APIs.
The warning popup includes a "Register your service" button for operators. It leads to Register as a Wallet-Relying Party, where you generate your certificate and key id and submit your entry so users see a verified badge instead of the warning.
Is this the same as a missing Trust Anchor definition?
Not exactly, although the two are related. Trust anchor onboarding registers an entity into a trust framework, for example by adding it to a trusted list. The not-verified notice is driven specifically by trust list recognition at the time of issuance or presentation. An issuer that has not been onboarded to a framework the wallet recognises, and that is not present on a trusted list the wallet validates against, will surface this notice. For a full explanation of the difference, see Trust in the Wallet Ecosystem.
The exact wording can differ across wallet versions and platforms. Current versions show "Issuer not verified" (issuance) or "Service provider not verified" (presentation); earlier versions showed "Untrusted Service Provider". The underlying meaning, that the party was not matched against a recognised trust list, is the same.