A status list is a compact public bitstring encoding the validity of many credentials at once. Each credential carries an index into it, so a verifier can check revocation without asking the issuer about that specific holder.
Naive revocation checking leaks. Asking an issuer whether credential 12345 is still valid tells them somebody is verifying that person right now. A status list avoids this by publishing the status of a large batch together, so the verifier downloads it and does the lookup locally.
The list is compressed and cacheable, which keeps the privacy property affordable at scale. Verifiers refresh on an interval rather than per verification.
The underlying IETF draft defines a suspended state alongside valid and revoked, but the ARF does not use it. In this ecosystem a status list carries valid or invalid, and suspension applies to a provider’s registration rather than to one credential.
The ARF does mandate a mechanism, from a short menu. An SD-JWT VC credential either lives less than 24 hours or uses an Attestation Status List. An ISO/IEC 18013-5 credential has a third option, an Attestation Revocation List, which publishes the identifiers of revoked credentials instead of a bitstring. A verifier that checks revocation at all has to support both list types.
Defined in
ARF v3.0.0 section 6.6.3.7 and Annex 2 Topic 7 (VCR_01, VCR_01b, VCR_11a, VCR_13, VCR_18); IETF draft-ietf-oauth-status-list (Internet-Draft)
Revocation checking is a recommendation rather than a hard requirement, and the ARF only lets you skip it after writing down a risk analysis. Skip it and you accept credentials that were withdrawn: a cancelled licence, a revoked mandate, a credential on a phone somebody lost last week. It is the check people forget most often and the one that costs most when missing, because everything else in the chain still looks valid.
Authbound handles the protocols, formats, trust lists and revocation checks behind these terms. See what people build with them.
