Skip to main content

LoTL trust verification

When your app receives a credential through the Truvity EUDIW Connector, you need to know whether the issuer is recognized by the EU trust framework—and what category of credential the issuer is authorized to produce. The connector resolves this automatically by verifying the credential's issuer certificate chain against the EU List of Trusted Lists (LoTL) hierarchy, determining whether the issuer holds a valid entry on the appropriate trust list for the credential category it claims to issue.

This page explains how LoTL trust verification works at the conceptual level—the credential categories, verification paths, trust failure reasons, and staleness signals. For configuration steps, see Configure trust anchor verification. For the callback payload field reference, see Callback events.

Credential categories​

The EU trust framework classifies credentials into four categories based on the legal status and governance model of the issuer. The connector determines the credential category from the issuer's trust list entry and reports it on the callback payload as the credentialCategory field. See Callback events for the field reference.

  • PID (Personal Identification Data)—Government-issued digital identity credentials. Issued by PID Providers authorized by their member state. Trust anchors published in the PID Provider LoTE.
  • QEAA (Qualified Electronic Attestation of Attributes)—Credentials from qualified trust service providers operating under eIDAS 2.0 Article 22. Trust anchors published in the member state's national Trusted List.
  • PuB-EAA (Published under a specific legal basis)—Credentials from providers operating under a legal basis other than the QTSP framework. The provider signs credentials using a qualified certificate issued by a QTSP. Trust anchors published in the member state's national Trusted List with a conformity assessment reference.
  • Non-qualified EAA—Credentials from providers operating under domain-specific Attestation Rulebooks. Trust anchors may appear on voluntary entries in national Trusted Lists; when absent, the connector falls back to statically configured trust anchors.

Verification paths​

Each credential category resolves trust through a different path in the LoTL hierarchy:

  • PID: Issuer certificate chain → PID Provider LoTE (JSON, ETSI TS 119 602) → LoTL
  • QEAA: Issuer certificate chain → National Trusted List (XML, ETSI TS 119 612) → LoTL
  • PuB-EAA: Issuer certificate chain (which includes a QTSP-issued qualified certificate) → National Trusted List (PuB-EAA Provider entry) → LoTL
  • Non-qualified EAA: Issuer certificate chain → Voluntary national Trusted List entry → LoTL; if no entry found, fallback to statically configured trust anchors

The EU Commission publishes the List of Trusted Lists (LoTL), which points to each Member State's national Trusted List and Lists of Trusted Entities. When the connector receives a credential with an X.509 certificate chain, it resolves the issuer's certificate against the appropriate list based on the credential category:

  • PIDs resolve against the PID Provider LoTE
  • QEAAs and PuB-EAAs resolve against the national Trusted List. For PuB-EAAs, the certificate chain includes a QTSP-issued qualified certificate as an intermediate—the connector verifies the full chain up to the PuB-EAA Provider's trust anchor published on the Trusted List (service type EAA/Pub-EAA), not against the QTSP's own entry.
  • Non-qualified EAAs attempt the national Trusted List first, then fall back to statically configured trust anchors

Trust resolution modes​

The connector supports two modes for resolving issuer trust. The mode is set at the connector instance level. The active mode is reported indirectly through the presence or absence of enriched trust fields on the callback payload.

  • LoTL-enabled mode (production path)—The connector fetches and verifies the EU LoTL hierarchy, builds a trust store, and resolves issuer trust dynamically. This is the production configuration for deployments that need to verify credentials from any EU-recognized issuer.
  • Static-only mode (fallback)—The connector resolves trust only against manually configured trust anchor certificates. This mode is for environments without LoTL infrastructure (early testing, isolated sandboxes, or pre-production deployments where the issuer set is known and fixed).

LoTL-enabled mode is the recommended production configuration. Static-only mode remains available as a fallback—see Configure trust anchor verification for setup.

Trust verification policy​

The connector can be configured to either report trust outcomes as informational fields or enforce them as a verification precondition. This is configured per credential category:

  • evaluate (default)—Trust outcomes are reported as fields on successful callback payloads. The flow completes regardless of the trust verdict. Your backend decides what to do with the result.
  • enforce—Trust failure for the configured category causes the flow to fail with a non-success callback status. The credential is never delivered to your backend.
  • disabled—Trust fields are omitted entirely from the callback for the configured category.

The default is evaluate for all credential categories—trust outcomes are informational, and your backend applies the appropriate legal weight to each verification result.

For configuration, see Configure trust anchor verification.

Trust failure reasons​

When the connector cannot resolve an issuer against the LoTL hierarchy, it reports a trust failure reason on the callback payload. This appears as the trustFailureReason field when isTrusted is false. See Callback events for the field reference. Four reasons are possible:

  • issuer_not_found—The issuer's certificate does not match any entry on any trust list in the LoTL hierarchy. The issuer may not be registered, may be using a certificate not yet published, or may be operating outside the EU trust framework.
  • issuer_withdrawn—The issuer was found on a trust list, but the entry's status is "withdrawn" or "revoked." The member state's supervisory body has terminated the issuer's authorization.
  • issuer_suspended—The issuer was found on a trust list, but the entry's status is "suspended." The member state's supervisory body has temporarily suspended the issuer's authorization pending review.
  • trust_list_unavailable—The trust list that should contain the issuer's entry could not be fetched and no valid cached copy is available within the staleness window. The connector cannot determine the issuer's trust status.

Staleness signals​

Trust list data has a limited freshness window. The connector periodically refreshes its trust data from the LoTL hierarchy. When a refresh fails, the connector may use cached trust data to avoid blocking verifications entirely. The staleness signal tells your backend whether the verification used fresh or stale trust data—this appears as the staleTrustData field on the callback payload. See Callback events for the field reference.

Two conditions are reported:

  • cachedFallback—The connector used cached trust data because a fresh fetch from the trust list source failed. The data was still within the configured staleness window.
  • pastNextUpdate—The cached trust data is past the publisher's declared next update timestamp. The data may be outdated.

Both flags help your backend make informed decisions. For example, you might accept a verification with cachedFallback but flag it for re-verification later, while pastNextUpdate might warrant additional scrutiny.

When trust data is fresh, the staleTrustData field is absent from the callback.

Applicability​

Trust verification applies only to credentials that include an X.509 certificate chain (x5c header). In HAIP-compliant ecosystems, SD-JWT VC credentials always include an x5c chain for issuer key resolution. Credentials without a certificate chain (for example, credentials using a DID-based issuer key) are not subject to trust anchor verification.

Further reading​