Credential Verifier: Settings: Trust domains

Catalog id: protocol.verifier.settings.trust-domains
Scope: tenant and verifier instance

This setting selects trust domains for verifier decisions. It does not turn a verifier into an external trust-list fetcher. The platform refreshes configured ETSI sources, validates their signatures and freshness, and makes the resulting local snapshots available to the verifier.

In the console

The Trust domains section edits the verifier's own CREDENTIAL_ISSUER_TRUST attachment:

• Trust mode: Verified only writes FAIL_CLOSED. Trust all writes UNRESTRICTED and is offered only where the attachment supports it.
• Allowed trust domains: one checkbox per tenant trust domain, showing its display name and id. With Verified only and no domain selected, the section warns that every presentation is refused.
• Save changes and Reset appear when there are unsaved changes.

The same editor appears as Trust domains on a DCQL query, on a verifier-DCQL binding, and on a verification template, each writing its own attachment for VERIFIER_TRUST. The console has no section for ETSI trust sources; those are configured through the API described below.

Trust boundaries

Source	Role that can be authorized	Verifier behavior
TS 119 612 EU or custom LoTL snapshot	QEAA Provider only	Use only normalized QEAA entries whose snapshot is active and within signed NextUpdate.
TS 119 602 LoTE snapshot	PID Provider, Wallet Provider, PuB-EAA Provider, Access CA, or Registration Certificate Provider	Match the requested profile, country-qualified provider identity, issuance service type, status, and signed validity.
Revocation-only service	No issuer or provider role	Do not treat the service as trust.

The verifier does not use cross-profile or cross-territory fallback. A PuB-EAA provider cannot authorize a QEAA decision. A direct anchor cannot bypass the registry-qualified role check.

Selection policy

Trust-domain selection is an attachment on (consumerKind, consumerId, usage). For a verifier deciding issuer trust the usage is CREDENTIAL_ISSUER_TRUST, and the lookup walks the request template, verifier-DCQL binding, DCQL query, verifier and tenant in that order.

Resolution takes the first level that has an attachment for the usage. It does not merge levels. An attachment on the verifier replaces the tenant selection rather than extending it, so a verifier that should also see the tenant's domains has to list them.

The attachment's policy.mode is authoritative:

Mode	Meaning
FAIL_CLOSED	Only the domains listed on the attachment, in their given order, admit an issuer identity. An empty list under this mode trusts nothing and stops the cascade.
UNRESTRICTED	Do not require a named issuer trust domain, while signature, status, holder-binding and protocol checks remain active.
No attachment anywhere in the chain	Fail closed. There is no implicit default.

The verifier settings surface must not infer the mode from the number of selected domains. An empty domain list can be an explicit FAIL_CLOSED decision that deliberately trusts nothing, and that is a different state from no attachment at all.

When the winning attachment is not the tenant's own, its domain list is checked against the eligibility grant for (OID4VP_VERIFIER, CREDENTIAL_ISSUER_TRUST). A domain outside the grant is rejected as a configuration error rather than being dropped from the list.

Anchors participate only when they hold the CREDENTIAL_ISSUER admission class in the selected domain. Adding a certificate to a domain does not make it usable for issuer decisions.

Trust-source state

Platform-owned TS 119 612 sources expose these runtime states through their diagnostics:

DRAFT, VALIDATED, ACTIVE, DEGRADED, EXPIRED, and DISABLED.

DEGRADED means that a previous validated snapshot remains usable until its signed NextUpdate. EXPIRED means that the snapshot is no longer usable. The verifier does not fetch a replacement URL when a snapshot expires. An LoTE publication is likewise unusable after its signed nextUpdate, and an ambiguous active publication fails closed.

REST references

Read and write the verifier's own selection:

GET /api/trust-domain/v1/attachments/OID4VP_VERIFIER/{verifierId}/CREDENTIAL_ISSUER_TRUST
PUT /api/trust-domain/v1/attachments/OID4VP_VERIFIER/{verifierId}/CREDENTIAL_ISSUER_TRUST
GET /api/trust-domain/v1/eligibility/OID4VP_VERIFIER/CREDENTIAL_ISSUER_TRUST

To preview which level of the cascade would win, and with which domain revisions, post the consumer and usage to the internal resolution route. This is an east-west service route rather than part of the customer contract, but it is the fastest way to explain a failing presentation:

POST /api/trust-domain/v1/internal/resolve/attachment
POST /api/trust-domain/v1/internal/evaluate/credential-issuer

Trust-source administrators use the per-domain routes documented in Trust domains, including:

GET  /api/trust-domain/v1/domains/{domainId}/trust-sources
GET  /api/trust-domain/v1/domains/{domainId}/trust-sources/{sourceId}/snapshot
GET  /api/trust-domain/v1/domains/{domainId}/trust-sources/{sourceId}/diagnostics

Trust-source list responses use the Kotlin { "items": [...] } envelope. The EUDI TS2 LoTE provider list uses { "providers": [...] }. These envelopes are intentionally different because they are the actual service response types.

For source configuration, KMS signing, publication, and the complete TS 119 612 and TS 119 602 matrix, see ETSI Trust Lists and Trust domains.