ISO mdoc with CWT Token Status
Step 3 of 5 in Prove the credential status profiles.
Profile. An ISO/IEC 18013-5 mdoc design bound to mso_mdoc and a docType, and an IETF CWT Token
Status List published as application/statuslist+cwt. The status response is raw COSE/CBOR, not JSON.
Setup. Define namespace-qualified elements, choose mdoc signing material, and create the one-bit
CWT status profile. Establish the DSC chain to an IACA in the verifier's trust domain. If a signed
VICAL is part of the policy, admit its signer and its issuing-authority entries separately; a VICAL is
not a status list, and Azure key custody establishes neither trust decision. Bind the list's correlationId as
status.statusListId on the mdoc credential configuration.
Offer. Create the backend offer with the advertised mdoc configuration (Mdl in the example):
Checks. Check the response docType, namespaces, issuer-signed MSO, x5chain and status URI and
index, and keep binary COSE/CBOR bytes and their media type at every status boundary.
Status transition. After the index changes, the verifier fetches application/statuslist+cwt,
decodes COSE/CBOR, validates the CWT issuer, expiry, signature and one-bit value, and compares the
index from the mdoc. Missing binary data, JSON where COSE is required, an untrusted DSC, IACA or VICAL
chain, or a revoked bit fails the check.
Full walkthrough: section "ISO mdoc + CWT Token Status" of the profile walkthroughs. VICAL configuration is its own journey, Configure mdoc VICAL and CWT status.
Next
Continue with step 4, W3C VCDM 1.1 JWT with Bitstring Status List.