Summary

  • draft-ietf-oauth-status-list-21 assigns each Referenced Token a URI and index into a compressed Status List. A protected Status List Token can efficiently assert VALID, INVALID, SUSPENDED or an application-specific value for many tokens at once. Revision 21 is an approved Internet-Draft in the RFC Editor queue, not yet an RFC.
  • By default, the selected value describes state when the Status List Token was issued. iat, exp and ttl bound issuance, validity and caching; they do not themselves record the transition time, authorising actor, cause, provider publication time or relying-party decision.
  • Daniel Kade proposes a minimized status-decision receipt outside the protocol: token and list fingerprints, URI/index, issuer validation, four distinct clocks, decoded semantics, local freshness policy, decision and later supersession. It is editorial guidance, not an IETF requirement, and should not become a private presentation-history warehouse.

Imagine a review six months after a digital credential was refused. The verifier kept a line saying INVALID. It can still identify the credential, perhaps even the Status List URI and index. It cannot produce the protected list bytes it fetched. It does not know whether the entry changed before or after the holder's attempted use, whether its cache was within policy, or whether INVALID was the sole reason for refusal. A later list now says something else.

Nothing in that example proves the refusal was wrong. The problem is narrower: the surviving value cannot reconstruct the decision.

Token Status Lists are designed to compress status, not to preserve institutional memory. That is an important virtue. A relying party need not call an issuer about one identifiable credential every time it performs a check. It can obtain a list containing many entries, validate a protected object, find the index named in the Referenced Token and interpret a few bits. The mechanism gains scalability and a form of herd privacy by refusing to carry an event dossier for each token.

The governance error begins when this economy is read backwards. A compact current assertion is not a chronology merely because it can influence an important result. The record needed to defend that result lives across several actors and several clocks.

An approved draft still is not the issued RFC

The Datatracker record identifies revision 21, dated 21 June 2026, as a Standards Track Internet-Draft of the OAuth Working Group. Its history records IESG approval of revision 20 on 4 June, entry into the RFC Editor queue, revision 21 on 21 June and an RFC Production Center state of Awaiting First editor on 13 August. That is a mature and approved specification in production processing. It is not yet an RFC, and editorial processing can still change the final text.

The revision 21 text expires on 23 December 2026. The official 20→21 comparison supplies the precise version boundary. This article analyses revision 21 at the stated research cutoff; it does not infer deployment prevalence from the document's progress or treat the OAuth Working Group as the operator of any implementation.

The draft covers tokens secured with JOSE or COSE, naming JWT, SD-JWT, CWT and ISO mdoc among its uses. JWS and JWT provide the JSON-oriented signing and claims foundations. CWT and COSE perform related work for compact CBOR environments. The status mechanism is not a second copy of the credential. It is a separately protected statement about a Referenced Token whose semantics may change after issuance.

One index selects one assertion

The Referenced Token carries a status claim. Under this mechanism, its status_list member includes a non-negative idx and a uri identifying the Status List Token. The pair tells a holder or relying party where to retrieve status and which entry to inspect.

The Status Issuer chooses one, two, four or eight bits per Referenced Token. It assigns distinct indices, packs the values into bytes from least-significant bit to most-significant bit, and compresses the byte array using DEFLATE with the ZLIB format. DEFLATE defines the compressed data format and ZLIB its wrapper. The result sits inside a Status List Token represented as JWT or CWT and protected by a signature or MAC.

This architecture separates three roles. The Issuer creates the Referenced Token. The Status Issuer receives status information and creates the protected list. The Status Provider serves that object. One organisation may perform all three roles, but the protocol also permits their separation. A third party can host a signed list without acquiring authority to alter its protected contents.

That division matters to audit. The Status Issuer's signature or MAC can establish origin and integrity for the list bytes. The provider's HTTP response establishes a delivery observation. Neither establishes when the real-world or administrative event behind a status occurred. If the issuer and provider are different, those are visibly different control surfaces; if they are the same company, they are still different functions.

The status registry further limits what the bits mean. Revision 21 assigns 0x00 to VALID, 0x01 to INVALID and 0x02 to SUSPENDED, with designated application-specific ranges and room for future registration. More than one bit does not create simultaneous statuses: the full group of bits represents exactly one value. An application must use a registered value when its semantics are the same or compatible.

A status value is therefore an assertion under a defined vocabulary. It is not the token's whole validity decision. The draft explicitly says that Referenced Token processing comes first. An expired token remains expired even if its list entry reads VALID. Signature, required claims, audience or other format rules may also fail before the status list is consulted. After status evaluation, local application restrictions remain at the relying party's discretion.

Four clocks cannot be collapsed into one

The first clock is the status-source clock: when did the administrative or real-world state actually change? A credential might be revoked after an account closure, suspended after a risk event or restored after review. Revision 21 does not define that upstream workflow, and the compact entry does not carry its actor, cause or event time.

The second clock is list issuance. In a JWT Status List Token, iat is required and identifies when the protected list was issued. exp is recommended and marks when the issuer considers the list expired. Those claims bound the assertion. They do not retroactively reveal when the selected entry changed.

The third clock is delivery and retrieval. The Status Provider may serve the object directly or through infrastructure such as a CDN. The relying party observes a response at a particular time. That time can differ from issuance, and neither one necessarily equals the moment a change entered the issuer's source system.

The fourth clock is the relying party's decision. It may evaluate the credential immediately, after a queue delay, or as part of a later batch. Its local policy determines whether the fetched list is fresh enough and what consequence follows the decoded value.

ttl connects some of these clocks but does not unify them. It is a recommended protected claim expressing how long a consumer may cache a Status List Token before it should fetch a fresh copy. Revision 21 describes two defensible strategies. A relying party can fetch again after its own retrieval time plus ttl, distributing provider load. For a critical use case, it can check for an update at iat + ttl, allowing a small distribution offset. If exp and ttl conflict with HTTP cache headers, the protected token claims take priority.

Ultimately the relying party chooses its checking interval within ecosystem guidance and local bounds. A short interval can improve freshness but impose unreasonable request volume; the security considerations warn clients to bound exp and ttl so an issuer cannot accidentally or maliciously drive excessive requests at a provider URL. Freshness is consequently a shared operational decision, not a magic property of a bit.

Historical lookup is optional, not an event ledger

By default, revision 21 provides the latest status information and describes the state at list issuance. It also defines optional historical resolution: add time=<timestamp> to the Status List request. A supporting server may return a list whose protected validity interval covers that time or an error. If static hosting ignores the query and returns the current object, the client must reject it unless the requested time falls inside the returned token's iat/exp window.

Historical lookup improves one question: what protected list did the service assert for a specified time? It still does not necessarily disclose the exact transition event, reason or authority. Several successive snapshots can bound a change between two issue times, but a bound is not an event timestamp. A service that knows the upstream transition may keep that separately; the wire format does not manufacture it.

The privacy cost is not incidental. The draft recommends that implementers avoid historical requests unless there are strong reasons and the implications are understood. A verifier that repeatedly stores and checks the same URI/index can build a status profile. An outsider that downloads current and historic lists may estimate issuance volumes or revocation rates. Turning optional snapshot retrieval into a universal permanent log could defeat the data-minimizing purpose that made the mechanism attractive.

Compression protects privacy only within a boundary

Grouping many Referenced Tokens in one list makes an issuer less able to infer which exact token motivated a request. Revision 21 calls this herd privacy. A larger herd improves the anonymity set while increasing transfer cost. That is a real design tradeoff, not an absolute anonymity claim.

The HTTP request can still reveal the relying party's address. A unique URI, one list per token, an unusually small list or a distinctive list size can shrink the herd. The URI/index tuple itself is traceable data, and colluding relying parties can compare it across presentations. RFC 9901 supplies the SD-JWT context in which unlinkable disclosure is especially important; Oblivious HTTP is one relay technique the draft cites for reducing requester observability.

The draft offers mitigations rather than a universal arrangement: third-party hosting, non-sequential or random indices, decoy entries, multiple lists, one-time-use batches and fresh entries on re-issuance. It also warns that non-routine statuses can leak information. SUSPENDED, for example, communicates something more specific than a binary valid/invalid outcome. An ecosystem must decide whether that additional meaning justifies the profiling surface.

This privacy boundary constrains audit design. A good receipt must prove the decision without assembling a covert longitudinal dossier of every credential presentation. It should use fingerprints, bounded retention and access control. It should record a historical query only when one occurred, not enable historical collection merely because the field exists.

Decoding is a decision step, not clerical plumbing

A one-bit entry looks too small to misread. The draft's security section says otherwise. Bit order runs from least-significant to most-significant within each byte while bytes advance in their normal order. An implementation that decompresses the wrong data, calculates the wrong byte or bit position, or accepts an out-of-range index can reach an incorrect status. Revision 21 provides test vectors and recommends their use.

The validation sequence is deliberately layered. First validate the Referenced Token. Then resolve the URI and validate the Status List Token, including its protected type and claims. Bind its subject to the URI. Apply iat, exp, ttl and local freshness rules. Decompress. Read the indexed value. Interpret the registered semantics. Only then apply application policy.

If the index is out of bounds, no status statement can be made and the Referenced Token must be rejected. If the status-list checks fail, the draft says no status statement can be made and the token should be rejected. “No statement” is not another spelling of INVALID; it is a failure to obtain the defined evidence. An audit record should preserve that distinction.

Preserve the decision, not a surveillance copy

For a consequential use, the smallest defensible status-decision receipt has two fingerprints and four clocks. It fingerprints the Referenced Token without retaining the whole credential, and fingerprints the exact Status List Token that was evaluated. It records the URI and index, Status Issuer, observed Provider, key-resolution and signature-or-MAC result, and decoding implementation or test-vector conformance relevant to the result.

It then keeps status-source transition time if actually known; otherwise unknown. It retains list iat and exp, the ttl policy, provider fetch time, cache age at use and decision time. It records whether the request was current or historical, the requested timestamp, the decoded numeric value and registered meaning, the relying party's own freshness bound, the application rule and the action taken.

Finally, it gives the decision an ending. A later list may supersede the observation. An appeal may reverse the action. The token may expire independently. The receipt should connect that correction or closure without rewriting what the system actually saw at the time.

This is not a proposal to add fields to Token Status List. It is Daniel Kade's off-protocol control for organisations that need to explain durable consequences. Hashes, minimized references and short retention can be preferable to raw credentials, IP addresses or a permanent request history. The Policy Mirror supplies the discipline of comparing declared rules with observable decisions; Running-Code Primacy keeps the implemented path in view; Reality, Not Advocacy requires the uncertainty to survive the narrative. None of those essays is technical evidence about a particular deployment.

Sources