Trust domains: Policy
Catalog id: resource.trustDomains.policy
This page covers two related records. Tenant attachments are the fallback trust selection for each
usage, and they are ordinary attachments written against the TENANT consumer kind. Eligibility
grants cap which domains other consumer kinds may select, and they are governance rather than
selection.
Audience: tenant administrator.
Console availability: the trust domains V2 console has no Policy area. Resources > Trust domains contains only Domains. Tenant attachments and eligibility grants are read and written through the Trust domain API, as shown below. Resource-level attachments are edited on the resource: the verifier Trust domains setting, the DCQL query and verifier-DCQL binding Trust domains sections, and the verification template Trust domains section. To see which resources attach a given domain, open the domain and use its Consumers and Diagnostics sections.
Guide: Trust domains.
A note on the captured payloads below: the sanitizer replaces every identifier with the same
placeholder, so two genuinely different domain ids appear identical on this page. The ordinal
values are what tell the entries apart.
Attachments
An attachment is keyed by consumer kind, consumer id and usage. Resolution walks from the most specific consumer upward, so a verifier's own attachment wins over the tenant's, and the tenant attachment is reached only when nothing more specific exists for that usage.
Read the tenant attachment for a usage
GET/api/trust-domain/v1/attachments/TENANT/00000000-0000-4000-8000-000000000000/CREDENTIAL_ISSUER_TRUST200 OK- Admin Console
- Request
- Response
- Try it
There is one tenant attachment per usage. The captured tenant has one for
CREDENTIAL_ISSUER_TRUST, selecting a single domain at ordinal 0.
The policy block is what the attachment actually enforces. type is IDENTITY_ADMISSION, and
mode decides how strict the identity check is. Under FAIL_CLOSED only the listed domains admit an
identity. Under UNRESTRICTED identity admission is not limited to named domains, while signature
checks, revocation status, holder binding, hostname verification and egress policy all still run.
UNRESTRICTED is always written explicitly and is never inferred from an empty domain list.
A usage with no tenant attachment at all admits nothing. That is the state a new tenant starts in, which is why writing the attachments for the usages your deployment enforces is the first job here.
Read a more specific attachment
GET/api/trust-domain/v1/attachments/OID4VP_VERIFIER/acme/CREDENTIAL_ISSUER_TRUST200 OK- Admin Console
- Request
- Response
- Try it
The same route with a different consumer kind and id reads the verifier's own attachment. When one exists it wins outright for that usage, and the tenant attachment is not consulted at all. That is the mechanism for giving one verifier a narrower or wider trust set than the tenant default.
Replace an attachment
PUT/api/trust-domain/v1/attachments/OID4VP_VERIFIER/acme/CREDENTIAL_ISSUER_TRUST200 OK- Admin Console
- Request
- Response
- Try it
PUT writes the whole aggregate. Send the attachment together with the complete ordered domain list,
not just the entry you are adding, and pass the current ETag in If-Match, or * on a first write.
ordinal sets the order domains are consulted in. The captured call adds a second domain at ordinal
1 behind the existing one at ordinal 0, and the version advances from 1 to 2.
Remove a domain from an attachment
PUT/api/trust-domain/v1/attachments/OID4VP_VERIFIER/acme/CREDENTIAL_ISSUER_TRUST200 OK- Admin Console
- Request
- Response
- Try it
Removing works the same way: send the list you want to end up with. Here the second domain is dropped by writing back a single-entry list, and the version advances again. There is no per-entry delete, which is deliberate, since it makes the resulting order explicit in every write.
Eligibility grants
A grant lists the domains one consumer kind may select for one usage. It is governance applied to the winning attachment, and it only applies when that attachment is not the tenant's own. The tenant's own attachment is the governing statement, so it is not capped by a grant.
- Admin Console
- Request
- Response
- Try it
The grant is keyed by consumer kind and usage. eligibleDomainIds is the permitted set for that
combination, and version is what the next conditional write needs.
A consumer kind with no grant for a usage has no domains available to it. Write the grant before delegating verifier configuration to a team, so their selections have something to land in.
- Admin Console
- Request
- Response
- Try it
Widening is a full write of eligibleDomainIds with the version you read. The captured call takes
the grant from one domain to two and the version from 1 to 2.
Do this when a verifier legitimately needs a domain it could not previously use, rather than moving the domain into the tenant attachment, which would change the default for everything.
- Admin Console
- Request
- Response
- Try it
Narrowing is the same call with a shorter list. The version advances to 3.
Narrowing a grant does not rewrite the attachments that already selected the removed domain, so tighten the grant and then check the consumers of that domain to see which attachments still name it.
Full schema: Trust domain API.