Skip to main content
Version: v0.25.0 (Latest)

Credential status profile walkthroughs

This page turns the format matrix into four implementation lanes. Each lane identifies the design binding, OID4VCI format, status-list proof, credential reference, hosted media type, and verification result that must agree.

Start with Credentials, status, and trust if the trust model, key provider, or credential format has not been selected. Use Developer Console when you are ready to execute the matching folder in the downloadable collection.

The invariant to preserve​

ProfileOID4VCI formatStatus create fieldsCredential status referencePublic response
SD-JWT VCdc+sd-jwttoken_status_list + jwtstatus.status_list.uri + idxapplication/statuslist+jwt
ISO mDocmso_mdoctoken_status_list + cwt + mdocProfile: status_listMSO status_list.uri + idxapplication/statuslist+cwt
VCDM 1.1 JWTjwt_vc_jsonbitstring_status_list + vc+jwtcredentialStatus.statusListCredential + statusListIndexapplication/vc+jwt
VCDM 2.0 JWTjwt_vc_json-ldbitstring_status_list + vc+jwtcredentialStatus.statusListCredential + statusListIndexapplication/vc+jwt

The list specification, signing envelope, credential format, and HTTP media type are separate fields that together form one profile. A verifier must reject a JWT where CWT is expected, an mdoc status object on a W3C credential, or a Token Status reference where StatusList2021 was configured.

Common preparation​

Before running any lane:

  1. Resolve the tenant API bases from the connected environment rather than hard-coding deployment hosts.
  2. Create the credential design and its stable OID4VCI credentialConfigurationId.
  3. Configure the exact KMS provider id and provider-native alias used for credential and status signing.
  4. Establish the verifier's trust-domain attachment and admissions.
  5. Create the status list before issuance, then retain the returned list id, public URI, and allocated entry index.
  6. Prove the public response and its media type without sending a management bearer token to the public endpoint.

1. SD-JWT VC with JWT Token Status List​

Use this lane when selective disclosure and JSON claim paths are required. The status list is an IETF Token Status List signed as a compact JWT.

Configure and inspect​

Create or inspect the design under Resources > Credential Designs. Confirm SD_JWT_VC, the vct, claim disclosure policy, and the OID4VCI configuration id.

SD-JWT credential-design format binding

Create the list under Resources > Status Lists > Lists. In its detail page, confirm Token Status List, JWT, one bit per status, and the intended public URI.

JWT Token Status List overview

Issue and evaluate​

Use Open Protocols > Credential Issuer > Test to resolve the design and status selection before running. Inspect the returned credential rather than relying on a green session badge.

Issuer testing surface for an SD-JWT credential

Decode the issuer-signed SD-JWT payload and locate status.status_list.uri and status.status_list.idx. The verifier fetches that URI with Accept: application/statuslist+jwt, validates the list JWT and issuer, decompresses the one-bit list, and evaluates the bit at idx. Disclosure validation, holder binding, issuer trust, and status evaluation remain independent checks.

2. ISO mDoc with CWT Token Status List​

Use this lane for mso_mdoc. The credential is CBOR-based, and the status publication is raw COSE/CWT bytes—not a JWT string inside JSON.

Configure and inspect​

Confirm the design's docType and namespaced element identifiers. In KMS, confirm that the signing key, DSC certificate, and x5chain describe the intended chain to an admitted IACA.

mdoc credential-design overviewKMS certificates used for mdoc signing

Issue and evaluate​

Use the issuer testing surface and then inspect the status-list Token tab. The hosted response must be application/statuslist+cwt with raw COSE_Sign1 bytes.

CWT status-list token inspection

Decode the credential as CBOR and inspect the issuer-signed MSO status projection. Its URI and index join the credential to the CWT list. A verifier must validate issuer authentication and DSC/IACA trust, device or holder authentication as required, the CWT signature and certificate, CWT freshness, and the indexed bit.

Do not base64-decode a JWT example and call it CWT. The protected COSE header, CWT integer claim labels, profile payload, and public content type are part of the contract. Read mDoc VICAL and CWT status for the separate VICAL trust lane.

3. W3C VCDM 1.1 in JWT with StatusList2021​

Use jwt_vc_json and the VCDM 1.1 context. Status is expressed by a StatusList2021 entry in credentialStatus, while the public list is a signed W3C credential.

In the credential-design workbench, confirm the VCDM 1.1 @context, the intended credential type, JSON claim paths, and the OID4VCI configuration id. In the status-list create screen, select the W3C bitstring/StatusList2021 option and JWT VC proof.

W3C credential-design source and contextCreate a W3C status list

4. W3C VCDM 2.0 in JWT with StatusList2021​

Use jwt_vc_json-ld and the VCDM 2.0 context. Although the status-entry mechanics match the VCDM 1.1 lane, the credential format, context, and semantics do not.

Confirm the design resolves with the VCDM 2.0 context and that issuer metadata advertises jwt_vc_json-ld. A configuration advertised only as jwt_vc_json is the wrong lane even if both use JWT serialization.

Resolved VCDM credential-design binding

Revoke, refresh, and prove rejection​

The status URI and credential signature remain stable when an entry changes. Only the signed status-list publication changes. Write the transition through the management API, wait according to the declared cache policy, fetch the public artifact again, and verify the same credential.

Use Resources > Status Lists > Lists, open the list, and inspect Entries. Confirm the exact index before changing it.

Status-list entries and transitions

For every profile, prove all of these boundaries:

  • the valid credential verifies before the transition;
  • the status URI and index in the credential exactly match the managed list entry;
  • the public response media type matches the selected proof format;
  • the status artifact's issuer or certificate is independently trusted;
  • the same credential is rejected after revocation and a genuine refresh;
  • unavailable, expired, malformed, wrong-type, and wrong-issuer lists fail closed; and
  • reactivation, if policy permits it, is observed only after a newly signed list is fetched.

Execute the customer-neutral request set​

Download EDK Credential Status Profiles. Its first four folders follow this page in order and contain issuance, status transition, and public fetch requests for each profile. The fifth folder contains optional Azure KMS, BYOK, and BYOC mutations; those requests are disabled by default.

The collection is executable material, not evidence by itself. Retain sanitized outputs from the environment under test and keep private credentials in an approved secret mechanism rather than collection variables.