Attach domains to the verifier and queries

Step 3 of 4 in Bind trust and queries.

Loading example...

PUT replaces the whole aggregate: the policy and the complete ordered domain list, each with an ordinal. Use the current strong ETag in If-Match. On the first write, send If-Match: "1" and attachment.version: 1; the endpoint requires a positive numeric version.

The body is the aggregate itself: attachment (with attachmentId, consumerKind, consumerId and usage matching the path, policy with type: IDENTITY_ADMISSION and mode, and version equal to If-Match) and domains, each entry carrying attachmentId, domainId and ordinal. Typical targets:

• OID4VP_VERIFIER/{verifierId}/CREDENTIAL_ISSUER_TRUST for the verifier default.
• OID4VP_DCQL_QUERY/{queryId}/CREDENTIAL_ISSUER_TRUST when one query needs a narrower or wider set.
• OID4VP_VERIFIER_DCQL_BINDING/{bindingId}/CREDENTIAL_ISSUER_TRUST when a specific verifier and query pairing needs its own set.

{verifierId} is the instance id from List your verifiers, {queryId} the DCQL queryId, and {bindingId} the id returned when the query was bound to the verifier.

policy.mode is FAIL_CLOSED (only listed domains admit, in order) or UNRESTRICTED (no named domain required; signature, status and holder binding still run). UNRESTRICTED is valid for issuer, wallet-provider and verifier identity only, and needs an empty domains array.

Loading example...

Removing one domain means writing the list you want to end up with; delete removes the whole attachment and lets the consumer fall through to the next level.

Next

Continue with step 4, Create verification templates.