Credential Status

Credential status is the general concept of a credential carrying, inside itself, a pointer to somewhere a verifier can check whether it's still valid, as opposed to the credential's signature alone, which only ever proves what was true at the moment it was signed. A signature never expires or gets revoked on its own; something else has to carry that information, and credential status is the property that says where to look.

It's deliberately a thin, generic extension point, not a mechanism. The actual checking logic, how the "is this revoked" question gets answered cheaply and privately, belongs to a separate spec (see Status List) or a separate design entirely (see Revocation for a non-status-list alternative). Credential status just says: here's a URI, here's my index within whatever that URI names, go check it if you care.

In the W3C JSON-LD world this is the credentialStatus property:

"credentialStatus": {
  "id": "https://example.org/status/3#94567",
  "type": "BitstringStatusListEntry",
  "statusListIndex": "94567",
  "statusListCredential": "https://example.org/status/3"
}

The JOSE/JWT world (the family SD-JWT VC belongs to) carries the same idea as a status claim inside the signed token itself, rather than a separate property name:

"status": { "status_list": { "uri": "https://example.org/status/3", "idx": 94567 } }

Same job, different container, matched to whichever way the credential itself is secured.

Where it comes from

The JSON-LD-side credentialStatus property comes from the W3C Verifiable Credentials Data Model, the same working group, with Manu Sporny and Dave Longley among its long-standing editors, that authored the rest of the data model. The JWT-side status claim comes from the IETF's SD-JWT and Token Status List drafts, edited by Daniel Fett, Kristina Yasuda, and Brian Campbell among others, the same editorial group behind SD-JWT VC itself. Neither property was designed by Solidus; both simply name where the real mechanism lives.

Solidus status

Wired, on testnet. issueSdJwtVc in @solidus-network/sdk accepts an optional status: { uri, idx } parameter; when supplied, the issued SD-JWT carries exactly the status.status_list.{uri, idx} claim shown above, and the SDK's own test suite exercises both sides, issuing with a status reference, and a verifier rejecting a credential once createStatusListJwt marks that index revoked.

What isn't there yet is narrower than this entry once claimed. ⚠ Corrected 2026-07-31: the status-list endpoint IS live, served at /status-lists/:id on the capture API, signing and returning a status-list JWT. The 2026-07-17 check tried the prefix without its :id segment and read the resulting route-miss as "no endpoint", the response bodies distinguish the two cases ("status list not found" means the route ran; "Route GET:… not found" means it does not exist). What a stranger still cannot do is fetch an actual list, because no published list id is discoverable and there is no public index of them.

Proof you can run yourself: npm i @solidus-network/sdk, issue a credential with a status parameter, and decode the resulting JWT payload directly: the claim shape is exactly as described above, and nothing about inspecting it requires a live network endpoint.