Skip to main content
Version: v0.25.0 (Latest)

Trust domains

A trust domain is a named set of cryptographic anchors (root CAs, intermediate CAs, DIDs, JWKs, federation entities) that your tenant uses to decide which issuers and authorities are acceptable for verification. Verifiers, DCQL queries, and templates then select which domains apply for a given OpenID4VP flow. Tenant policy sets the hard cap on what those lower scopes may choose, and the fallback when nothing more specific is configured.

Trust domains are not credential designs and not status lists. Designs describe what a credential contains. Status lists say whether a credential was revoked. Trust domains say who is allowed to have issued or attested it under your policy.

Whether any domain already exists depends on product onboarding and sample data. A new tenant often starts with no tenant defaults (fail closed): nothing is trusted until an operator opts in.

Audience: tenant admin (or platform operator in a tenant context).

Prerequisites: Onboard a tenant. Anchors often reference DIDs or certificates you manage under Keys and DID. Verification flows also need a verifier instance and usually Credential designs or DCQL queries.

Reference: Domains, Policy
API: Trust domain.

Guide variables useful for live Run: domainId, anchorId, tenantId.

How verification uses trust domains​

OID4VP resolution picks an ordered list of domains from several scopes (most specific wins):

  1. Verification template
  2. Verifier + DCQL query binding
  3. DCQL query alone
  4. Verifier alone
  5. Tenant defaults

Each selection is constrained by the tenant allowed list when that list is non-empty. Signature checks, status checks, and holder binding still run even in "trust all" mode: unrestricted only means issuer identity is not limited to named domains.

Domains inventory​

The Domains area lists trust domains by display name, lifecycle status (Draft, Active, Disabled), anchor count, validity window, and last update. Filter by status when you have many domains. Open a row for overview, anchors, bindings, and diagnostics.

Navigation: Resources > Trust domains > Domains
Deep link: #resource=trustDomains&rarea=domains

Empty means none were created yet. That is expected until you define anchors for your issuer ecosystem.

Trust domains list

Create a trust domain​

Create with a display name operators will recognize and an optional description. New domains start as Draft so you can attach anchors before anything trusts them in production.

Do not activate a domain that has no anchors unless you intend an empty set (which trusts nothing for that domain). Prefer draft until at least one active anchor for issuer validation is in place.

New trust domain opens a short dialog (name and description), then return to the list.

New trust domain dialog

Domain overview and lifecycle​

Overview holds display name, description, and optional validity window. Leave validity empty for a domain that is always considered in range. Save after edits.

Lifecycle actions on the header:

  • Activate moves Draft to Active so selections and resolution can use it.
  • Disable stops using an Active domain without deleting anchors.
  • Delete removes the domain and its anchors and bindings. Prefer disable for production mistakes you might reverse.

Get and activate over REST:

Open a domain (for example an active EU wallet domain). Overview is the default tab.

Trust domain Overview

Anchors​

An anchor is one trusted identity material inside the domain: typically an X.509 certificate chain member, a DID, a JWK, or a federation entity. Each anchor has a role (for example trust anchor vs trusted issuer) and purposes (commonly issuer validation). Without anchors, an active domain still does not accept any issuer.

Add anchors only after the identity exists in your registry (DID, certificate, and so on). Disable or delete an anchor when a CA is retired or a partner leaves, rather than leaving stale material active.

Anchors tab lists type, display value, role, purposes, and status. Use Add to open the add-anchor wizard.

Trust domain Anchors

Bindings​

A binding ties the domain to a target for a purpose (for example issuer validation of a credential definition or configuration id). Bindings answer "when validating this type of credential, consider this domain." They do not replace domain selection on verifiers; they refine when the domain participates.

Priority and enabled flags control order and temporary switch-off without deleting the binding.

Bindings tab for the domain. Filter by purpose when the list is large.

Trust domain Bindings

Diagnostics​

Diagnostics previews resolution without running a live presentation:

  • Anchor resolution shows which identifiers the domain would produce for a purpose (and optional target), including verified state when the product resolves material.
  • OID4VP resolution shows which domains would win for an optional verifier / query / template context, and explains policy diagnostics (empty selection, domain outside allowed list, inactive domain, and so on).

Use this before cutting over production verifiers so a misconfigured allowed list or draft domain does not fail presentations silently.

Trust domain Diagnostics

Tenant policy​

Policy is tenant-wide OpenID4VP trust configuration. It is not a list of anchors.

Allowed trust domains​

The allowed set is a hard cap. Every lower-level selection (verifier, DCQL query, binding, template) and the tenant defaults must stay inside that cap when the cap is non-empty. An empty allowed list means no tenant-level cap (unrestricted as a cap only; defaults still control fallback).

Tenant defaults​

Defaults apply when no more specific scope configures trust domains. Posture is explicit:

PostureMeaning
Fail closedNo defaults; nothing is trusted at this scope until a more specific scope selects domains. Correct for a brand-new tenant.
Trust allAny cryptographically valid issuer is accepted at this scope (issuerTrustMode: UNRESTRICTED). Signature, status, holder binding, and protocol checks still apply.
CustomOrdered list of domains (issuerTrustMode: TRUST_DOMAINS). Every entry must also appear in Allowed when Allowed is non-empty.

Save only when defaults do not violate the allowed list. Violations block a correct save so resolution does not drop domains silently.

Navigation: Resources > Trust domains > Policy
Deep link: #resource=trustDomains&rarea=policy

Trust domains Policy
  1. Create draft domains for each issuer ecosystem you care about.
  2. Add anchors (CAs, DIDs, federation entities).
  3. Activate domains that are ready for production selection.
  4. Set tenant Allowed and Defaults (fail closed until you choose otherwise).
  5. On verifiers, DCQL queries, and templates, select domains within the allowed cap.
  6. Use Diagnostics to confirm resolution before go-live.

After trust domains​

  1. Configure verifier and DCQL trust selections within policy
  2. Verify credentials
  3. Keep anchors current when CAs rotate or partners leave

Next​