Why Your Credential Shows Active, Suspended, or Revoked
The three states, in plain terms
- Active: the credential is good. Whoever issued it has not withdrawn it, and it has not expired.
- Suspended, temporarily not good. The issuer has paused it, and could un-pause it. Think of a membership on hold rather than one cancelled.
- Revoked, permanently withdrawn. It does not come back.
Expiry is a separate thing and it is baked into the credential itself: a credential can be past its expiry date and still show as active, because "active" describes what the issuer has done, not what the calendar says. A verifier checks both.
How a verifier finds out, and why it is not a phone call
The obvious design would be for the verifier to ask the issuer "is this one still good?" That design is exactly what a holder-controlled credential is supposed to avoid, because it tells the issuer where and when you used it.
So the mechanism is inverted. The issuer publishes one long list covering many credentials, with a small slot for each. Your credential carries the address of that list and your index in it, nothing more. A verifier fetches the whole list and reads the slot at your index.
The issuer learns that somebody fetched the list. It does not learn that it was you, or who asked. That is the entire point of the design, and it is a genuine privacy property rather than a marketing one.
What Solidus actually ships
The issuing path can attach a status. When a credential is issued with a status parameter, the issued credential carries a status claim naming the list's address and the index inside it. That is wired end to end and covered by our SDK's own tests.
The list itself is served, signed, live. The endpoint returns a signed status-list token with
content-type: application/statuslist+jwt and a five-minute cache header, so a verifier can hold it
briefly rather than re-fetching per check.
And here is how we know, because reading a status code alone would have misled us: asking for a list id that does not exist returns "status list not found", the route ran and the database had no such row. Asking for a path that does not exist returns "Route GET:… not found". Two different 404s, and only the second one means "missing." We checked a known-good endpoint in the same pass as a control.
What this does not do, stated before you find out
Status is optional at issuance. A credential issued without a status parameter carries no status claim at all, and a credential with no status claim cannot be revoked, because there is no list and no index for anyone to look at. It is not "active"; it is silent on the question.
If revocability matters to you, that is a question to ask the issuer, not something to assume from the fact that we support it.
And you cannot browse a list without knowing its address. Elsewhere on this site we hand you a command and you get an answer. Here, a stranger with no credential and no list id has nothing to fetch, the mechanism is checkable in code and in behaviour, but it is not self-serve, and we would rather say that than point you at something that returns nothing and call it proof.
A verifier that ignores the status claim is not stopped by any of this. Publishing a revocation does not force anybody to read it. What the mechanism gives a verifier is the ability to check without announcing itself, not a guarantee that every verifier does.