Prove the credential status profiles

Four credential format and status pairings are supported, and each is proven on its own: SD-JWT VC with JWT Token Status, ISO mdoc with CWT Token Status, W3C VCDM 1.1 JWT with Bitstring, and W3C VCDM 2.0 JWT with Bitstring. Evidence for one pairing never stands in for another; in particular a StatusList2021 example is not evidence for Bitstring.

Complete first: Issue credentials.

Steps and why they come in this order

Step	Why here
1. Review offer status, entries and verification reads	Every profile uses the same backend reads to follow an offer, a status entry and a verification. Learn them once before running a profile.
2. SD-JWT VC with JWT Token Status	Proves the SD-JWT VC pairing on its own: dc+sd-jwt with a vct, and an IETF JWT Token Status List.
3. ISO mdoc with CWT Token Status	Proves the mdoc pairing on its own: mso_mdoc with a docType, a CWT Token Status List, and DSC, IACA and VICAL trust kept separate.
4. W3C VCDM 1.1 JWT with Bitstring Status List	Proves the VCDM 1.1 pairing on its own: jwt_vc_json with the 1.1 context, and a Bitstring Status List credential.
5. W3C VCDM 2.0 JWT with Bitstring Status List	Proves the VCDM 2.0 pairing on its own: jwt_vc_json-ld with the 2.0 context, and a Bitstring Status List credential.

How to read these steps

Every profile follows the same boundary: issuer setup and design, status-list setup, offer creation, wallet token exchange, format-specific credential request, response-derived status identifiers, wallet storage and presentation, verifier checks, and a status transition. An offer is only the backend issuance entry point.

Postman profile lanes

Download EDK-Credential-Status-Profiles.postman_collection.json and run one profile folder at a time. The order within a folder is status-list creation and public fetch, offer creation and resolution, issuer and authorization-server discovery, token exchange, issuance, trusted pre-revoke verification, revocation, refreshed public fetch, and post-revoke rejection. The Manual items are explicit handoff checkpoints for wallet proof, trust or format-specific decoding; they are not claims of unattended interoperability.

Profile folder	Key requests
01 JWT Token Status List + SD-JWT VC	Create 01 JWT Token Status List + SD-JWT VC status list, Create 01 JWT Token Status List + SD-JWT VC offer, Issue 01 JWT Token Status List + SD-JWT VC, Revoke 01 JWT Token Status List + SD-JWT VC status entry, Refresh 01 JWT Token Status List + SD-JWT VC status list
02 CWT Token Status List + ISO mDoc	Create 02 CWT Token Status List + ISO mDoc status list, Create 02 CWT Token Status List + ISO mDoc offer, Issue 02 CWT Token Status List + ISO mDoc, Revoke 02 CWT Token Status List + ISO mDoc status entry, Refresh 02 CWT Token Status List + ISO mDoc status list
03 W3C VCDM 1.1 + Bitstring Status List	Create 03 W3C VCDM 1.1 + Bitstring Status List status list, Create VCDM 1.1 credential design, Create 03 W3C VCDM 1.1 + Bitstring Status List offer, Issue 03 W3C VCDM 1.1 + Bitstring Status List, Revoke 03 W3C VCDM 1.1 + Bitstring Status List status entry, Refresh 03 W3C VCDM 1.1 + Bitstring Status List status list
04 W3C VCDM 2.0 + Bitstring Status List	Create 04 W3C VCDM 2.0 + Bitstring Status List status list, Create VCDM 2.0 credential design, Create 04 W3C VCDM 2.0 + Bitstring Status List offer, Issue 04 W3C VCDM 2.0 + Bitstring Status List, Revoke 04 W3C VCDM 2.0 + Bitstring Status List status entry, Refresh 04 W3C VCDM 2.0 + Bitstring Status List status list

The separate 05 Azure KMS, BYOK, and BYOC (opt-in) folder contains Attach Azure KMS resource, Register BYOK key and Register BYOC provider-native certificate. Those are optional, environment-dependent mutations, not prerequisites for the profile lanes, and must only run against an explicitly approved target.

Deeper reference

Credential status profile walkthroughs is the overview of the four pairings, and Credentials, status, and trust is the decision matrix.

Next journey

Continue with Configure mdoc VICAL and CWT status.