Publish status lists
A status list publishes compact status values for issued credentials. Each credential carries the list URI and its index, and a verifier fetches the signed list anonymously. Create the list as a standalone resource before any credential configuration refers to it.
Complete first: Connect Azure KMS with BYOK and BYOC.
Steps and why they come in this order
| Step | Why here |
|---|---|
| 1. Review existing status lists | A list near capacity needs a successor before issuance fails. See what exists, and how full it is, first. |
| 2. Create a list for each profile | Credential configurations bind a list by its correlationId, so the list must exist first. |
| 3. Check or change the signing key | A verifier resolves the list signer back to the issuer. Confirm the binding after creation and before credentials reference the list. |
| 4. Change entries and check the publication | Entries exist only after issuance allocates them. Status changes and public checks close the lifecycle. |
Matching the format to the credential
| Credential | Status format | Proof | Public media type |
|---|---|---|---|
| SD-JWT VC | IETF Token Status List | JWT | application/statuslist+jwt |
| ISO mdoc | IETF Token Status List | CWT | application/statuslist+cwt |
| W3C VCDM 1.1 or 2.0 | Bitstring Status List | VC-JWT | application/vc+jwt |
Management allocates and updates an index, public hosting publishes signed status data, and a verifier does the final check. List creation does not allocate an index for a credential that does not exist yet; the issued credential response supplies the URI and index.
Deeper reference
Status lists and revocation maps the 3. Tenant APIs > Status lists Postman folder and the console Entries and Token tabs.
Next journey
Continue with Configure credential configurations.