Status List revocation explained
A credential can be correct on the day it is issued and wrong six months later. Someone leaves the company, a licence is withdrawn, a certificate is suspended. Status List is the agreed European way for an issuer to say publicly that a credential no longer counts, and for anyone receiving it to find that out in a fraction of a second.
The problem it solves
A signed credential proves who issued it, but a signature says nothing about whether the issuer still stands behind it. Without a way to withdraw one, an organisation is left issuing short-lived credentials and reissuing them constantly, or accepting that a revoked credential keeps working until it expires. Status List gives the issuer a switch it can flip at any time.
Issuer
Gives every credential it issues a place on a published list
The place is set once, at issuance, and stays the same for the life of the credential
How the check works
When someone presents a credential, the organisation receiving it downloads the issuer’s list and looks up the answer there. The list is signed by the issuer, so it cannot be tampered with in transit, and it stays usable for a set period, which means most checks need no network call at all.
Verifier
Sees in the credential it just received where the issuer publishes its status list
Status list
Downloads the list once, keeps it for a short while, and reads the answer for this credential from it
Why it stays private and cheap
The obvious way to check a credential would be to ask the issuer about it. That tells the issuer exactly who is dealing with whom, and it puts the issuer in the middle of every transaction.
Status List avoids both. The whole list is small enough to download in one go, even when it covers hundreds of thousands of credentials, so the verifier finds the answer locally. The issuer never learns which credential was checked, and it does not need an always-on service sized for everyone else’s traffic.
What this means for you
Issuer
You can withdraw a credential the moment it stops being true, without recalling anything or contacting the people who already accepted it.
Verifier
You get a current answer in milliseconds, offline in most cases, instead of maintaining a bilateral link with every issuer you accept.
Wallet holder
Nobody has to be told where you presented a credential. The check happens without the issuer being involved at all.
Technical deep dive
This page explains what the technology does and who it affects. Our developer documentation covers the implementation itself: the messages, the fields and the worked examples an integration team needs.
Read the technical documentationRelated terms
Frequently asked questions
Does the verifier fetch a separate list for every credential it checks?
No. One list covers every credential the issuer put in it, potentially hundreds of thousands. A verifier downloads that one list, reads the answer for each credential it checks from the copy it already has, and only fetches it again after the period the issuer set.
Can the issuer tell which credential a verifier looked up?
No, and that is the point of the design. The verifier downloads the whole list and finds the answer on its own machine, so the issuer only sees that someone asked for the list. It learns nothing about which credential was checked, by whom, or when.
What is the difference between suspended and revoked?
Revoked is permanent: the issuer no longer stands behind the credential and never will again. Suspended is temporary and reversible, for example while a dispute is investigated or a licence is under review, and the issuer can lift it later. An issuer that only needs valid or revoked can run a simpler list.
What does an issuer have to run to support this?
A published list that it keeps up to date, and a process that decides when a credential should be withdrawn. The technical part is small: the list is a single file served from a public address. The work is organisational, deciding who may revoke, on what evidence, and how quickly a change has to appear.
Sources
This page is informational and does not constitute legal advice. For authoritative guidance consult the IETF specification directly.