mdoc VICAL and CWT status-list integration
An mdoc verifier makes several independent decisions. It validates the issuer-signed mdoc and its DSC chain, decides whether the IACA or VICAL-derived authority is admitted, validates holder or device authentication, and evaluates the status entry carried by the MSO. A success in one step cannot replace another.
This page is the mdoc branch of Credentials, status, and trust. It deliberately separates VICAL trust from CWT status.
Separate the artifacts first
| Artifact | Decision | Encoding / transport | Failure must mean |
|---|---|---|---|
| DSC and IACA chain | Does the document signer chain to an admitted issuing authority? | X.509 certificate chain | Issuer authentication fails |
| VICAL | Which mdoc certificate authorities may be admitted from a signed list? | Signed CBOR/COSE artifact | Trust is unavailable or rejected, never silently empty-success |
| CWT Token Status List | Is the indexed mdoc status entry current? | Raw COSE_Sign1 as application/statuslist+cwt | Credential status fails closed |
| ETSI trusted-entity list | Which entities and roles are admitted by that separate trust source? | Signed JSON/JAdES publication | It cannot substitute for VICAL |
VICAL and CWT both use CBOR/COSE technologies, but their payloads, signers, APIs, caching, and security decisions are different.
1. Build the mdoc signing chain
The credential signing key must match the DSC public key. The DSC must chain to the intended IACA, and the credential must carry the intended x5chain. A provider-native KMS reference controls the private-key operation without moving private material into EDK.
- Admin Console
- Scalar KMS contract
Navigation: Resources > KMS > Keys and Certificates
Inspect the certificate detail and its linked key before selecting the alias in an issuer or status-list configuration.
Register an external key by provider-native reference. Register a provider-native certificate or stored public chain separately. Neither route accepts an external private key.
2. Establish the trust domain
Create a domain, add active anchors, assign admission classes, activate the domain, and attach it to the verifier or another intended consumer. A valid DSC outside the resolved domain remains untrusted.
- Admin Console
- Captured request, response & Scalar
Navigation: Resources > Trust domains > Domains
Verifier attachment: Open Protocols > Verifier > Settings > Trust domains
Use the Bindings tab to confirm which consumer resolves the domain. Narrower attachments replace broader selections rather than silently merging with them.
These captured management operations show domain lifecycle and attachment. Their inner API reference tab resolves to the Trust Domain Scalar contract.
- Overview
- Request
- Response
Create trust domain
Endpoint: POST /api/trust-domain/v1/domains
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
- Overview
- Request
- Response
Activate trust domain
Endpoint: PUT /api/trust-domain/v1/domains/trust-domain-partner-dids
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
- Overview
- Request
- Response
Replace the domain selection on an attachment
Endpoint: PUT /api/trust-domain/v1/attachments/OID4VP_VERIFIER/verifier-age-check/CREDENTIAL_ISSUER_TRUST
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
Use MDOC_VICAL_SIGNER for anchors permitted to verify the VICAL artifact and CREDENTIAL_ISSUER for authorities permitted to issue credentials. Do not grant one admission merely because the same organization performs both roles operationally.
3. Configure VICAL on the provider anchor
Configure the VICAL URL on the anchor representing its provider, and explicitly name the signer and issuer anchor ids it is allowed to use.
- Admin Console
- Request contract
- Response & evidence boundary
- Scalar/OpenAPI
Open the provider anchor in Resources > Trust domains, inspect its admissions, and use diagnostics to distinguish configuration, source health, and active trust material.
The screenshot documents the operator surface; it is not proof of a successful remote VICAL fetch or cryptographic consumption.
The request selects an HTTPS VICAL source, permitted signer anchors, permitted issuer anchors, optional certificate profiles, and whether the source is enabled. The service rejects cross-domain or inactive anchors and anchors without the required admission.
The management response proves that the validated configuration was persisted. GET can retrieve it and DELETE removes only the VICAL configuration—not the anchor or its admissions.
There is currently no sanitized runtime VICAL-consumption capture embedded here. Do not infer that a deployed verifier fetched, decoded, signature-verified, cached, and enforced the artifact from configuration success alone.
Runtime acceptance requires separate evidence for the remote response and content type, COSE signature and VICAL-signer admission, artifact freshness, IACA extraction, cache/refresh behavior, and a verification decision that actually uses the derived authorities.
4. Create the CWT Token Status List
The status-management request selects an IETF Token Status List, CWT proof, the mdoc one-bit profile, an X.509-oriented signing selection, and a stable public URI. The private key stays behind the chosen KMS provider.
- Admin Console
- Request contract
- Hosted response
- Scalar hosting API
Navigation: Resources > Status Lists > Lists
After creation, inspect Token and confirm application/statuslist+cwt. The public response is binary COSE_Sign1; it is not a JSON envelope containing base64 data.
Select the named mdoc CWT status list example. Confirm spec: token_status_list, proofFormat: cwt, mdocProfile: status_list, bitsPerStatus: 1, and the intended KMS resource and alias.
The management response is JSON metadata. The public response is raw bytes served as application/statuslist+cwt. Its protected COSE header, signing algorithm, certificate material, CWT claims, one-bit lst payload, expiry, and optional aggregation URI must all satisfy the mdoc status profile.
A JWT-shaped body, wrong protected type, untrusted certificate, expired CWT, malformed payload, or unavailable publication is a verification failure.
5. Issue mdoc with the allocated status entry
Create an MSO_MDOC design with the correct ISO docType and namespaced elements. Execute the OID4VCI offer and credential request using mso_mdoc. Decode the returned credential as CBOR and inspect the issuer-signed MSO; do not parse it as JWT.
- Admin Console
- Captured request, response & Scalar
Use Open Protocols > Credential Issuer > Credentials to confirm the mdoc configuration and Test to execute it.
- Overview
- Request
- Response
Create Mdl mdoc design
Endpoint: POST /api/credential-design/v1/designs/credentials
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
- Overview
- Request
- Response
Create Mdl offer
Endpoint: POST /api/oid4vci/v1/backend/credential/offers
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
- Overview
- Request
- Response
Request Mdl credential
Endpoint: POST /oid4vci/acme/oid4vci/credential
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
The MSO status URI and index are the join to the CWT list. Verify the index was allocated once and exists in that list; do not invent or reuse an index in a credential template.
6. Revoke and verify the same credential
Change the allocated entry through the authenticated management API, wait according to the list cache policy, then fetch the public CWT again. The mdoc and its signature do not change; the status decision does.
- Admin Console
- Captured transition
Open the status list and inspect Entries before changing the value. Record the exact index and resulting publication timestamp.
- Overview
- Request
- Response
Revoke a status entry
Endpoint: POST /api/statuslist/v1/statuslists/00000000-0000-4000-8000-000000000000/status
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
The verifier must reject the same mdoc after it resolves the refreshed list and observes INVALID. It must still report issuer-signature, device/holder, trust, and status outcomes separately enough to diagnose which boundary failed.
Fail-closed acceptance
For CWT status, prove rejection of unavailable, expired, malformed, wrong-media-type, wrong-protected-type, wrong-algorithm, and wrong-certificate publications. Prove the valid credential before revocation and rejection after a genuine refresh.
When the deployment claims runtime VICAL consumption, also prove:
- a VICAL signed by an anchor without
MDOC_VICAL_SIGNERis rejected; - an IACA not allowed by the configured issuer-anchor set is not admitted;
- expired, malformed, unavailable, and wrong-media-type VICAL material fails closed;
- refresh and cache behavior do not retain an expired or replaced artifact indefinitely; and
- valid ETSI trust material cannot satisfy a missing VICAL decision, nor vice versa.
The EDK Credential Status Profiles collection contains the customer-neutral mdoc design, CWT status, issuance, public fetch, and transition shapes. It does not turn a CWT request into VICAL evidence.