Revocation reaches the verifier later
Bound new-request rejection only after accounting for status publication, verifier caches, expiration, and existing sessions.
On this page
The question for today
What you’ll understand
- Distinguish stopping issuance from rejecting a stolen existing credential.
- Include delayed stale-status publication in a cache-staleness bound.
- Separate new-request validation from established and resumed sessions.
Disabling a workload at the issuer does not instantly change every verifier's state. A still-valid stolen token can pass an offline signature check, and cached authorization or status decisions can outlive a control-plane update. Revocation is a propagation and enforcement problem as well as an administrative action. Specify which credential and request path is being stopped, then trace every cached acceptance condition before claiming a deadline.
Different compromise scopes require different responses
A stolen bearer token with a fixed expiry differs from a compromised signing key that can mint fresh tokens. Stopping renewal limits future legitimate issuance but does not retract already issued artifacts. Removing an issuer key from one live key set may not remove cached copies at every verifier. A verifier that only checks signature and expiry cannot discover a subject-disable event unless another policy or status mechanism supplies that information. Define the actual validation path and its supported revocation behavior.
Online review can establish facts that offline validation cannot, such as whether an object-bound credential's referenced workload still exists. Kubernetes TokenReview and its documented service-account rules illustrate that difference; a third-party offline JWT verifier should not assume it automatically performs the same live checks. Availability choices also matter. If a status service is unreachable, a fail-open cache can extend acceptance beyond the intended window unless it has an enforced hard age bound and a deliberate failure policy.
Cache time includes in-flight publication
A cached allow can be filled after revocation from a status read that began earlier and paused. Bounding only network propagation while ignoring read, response, or cache-publication delay repeats the stale-fill race. Either bound through the last accepted stale publication, anchor age to trustworthy observation time with an appropriate hard deadline, or reject outdated publications using an authoritative version or generation. If old work can pause indefinitely and later create a fresh cache lifetime, no finite global revocation bound follows from TTL alone.
The fixed-token expiry part of a bound does not apply unchanged to a compromised signer that keeps issuing new valid-looking documents. That case requires removing or constraining the compromised authority at verifiers, plus handling cached keys and derived sessions. A per-request authorization deny can sometimes contain a subject earlier, but only along paths that actually enforce it. Measure rejection at the resource boundary rather than treating an issuer's successful disable response as evidence that all traffic has stopped.
Sessions need their own retirement rule
An established TLS channel may continue after the certificate used during authentication expires or is administratively disabled, unless the application or transport lifecycle enforces another check. TLS 1.3 resumption uses retained secret state and associated identity context; it is not automatically a fresh certificate presentation on every request. Rotating a leaf certificate or issuing a TLS KeyUpdate does not itself prove that every old authenticated session or resumption ticket is invalid. Define reauthorization, ticket invalidation, and connection draining separately.
The cache lab is a state-retention contrast only. Reset and set both C=4, s=4, predict twelve hits among sixteen requests and Step to add one hit. Its fully associative empty-start LRU address stream caps at 4096 requests and contains no TTL, credential, revocation, or status generation. A hit simply means an identifier remains resident under that toy policy. Explain why a production verifier must check freshness and revocation semantics in addition to finding an entry in memory.
Work it through
A bounded new-request path
A fixed stolen token has 300 seconds remaining validity with zero expiry leeway. Detection takes 20 seconds; a proven 15-second interval then covers the last accepted stale-status publication. Cached allows have a hard 60-second lifetime. EVERY new-request path requires BOTH time-validity AND absence of an effective deny and rejects if EITHER fails. Assume no cache-age reset, alternative acceptance path, or session bypass.
The deny path's worst-case bound is 20+15+60=95 seconds after the incident. The 15 seconds explicitly includes delayed reads, responses, and publication, not merely a broadcast delay.
The fixed token's expiry independently stops new acceptance after 300 seconds. Because both acceptance conditions are mandatory on every path, the earlier rejection condition gives min(300,95)=95 seconds.
This conclusion excludes a compromised signer minting new tokens, unbounded stale publication, fail-open extension, and established or resumed sessions that bypass the request checks. Each excluded path needs its own containment rule before claiming global revocation.
Revocation latency is conditional on the final verifier's actual acceptance paths, not just the issuer's update time.
The living notebook
Explore the model
Interactive lab · cache
Resident does not mean still acceptable
Reset, set C=4, s=4;predict 12 hits in 16 requests, then Step adds one hit. This capped 4096-request LRU toy has no TTL, credential validity, status checks, or revocation guards.
- Hits / requests
- 0 / 16
- Hit rate
- 0%
- Address-stream period
- 16 addresses
A fully associative LRU cache starts empty and requests address (i·s) mod 16. Hits move an address to the newest position; misses evict the oldest when full. Playback starts with 16 requests and adds two per second, capped at 4096 explicitly simulated requests. This toy stream is not a processor-cache benchmark. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA verifier cache hit must still satisfy the security lifecycle's freshness and invalidation rules.
Pause & reason
Check your understanding
Your turn
Try it yourself
For one fixed token, remaining validity is 180 seconds with five seconds leeway. Detection is ten seconds, last stale-status publication is bounded twenty seconds later, and hard allow-cache lifetime is forty seconds. Compute the stated new-request bound and name one path it excludes.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Compare the expiry route with the complete deny-publication-plus-cache route.
Compare with the solution
The expiry route is 185 seconds and the deny route is 10+20+40=70 seconds, giving a 70-second bound under the model. It excludes established or resumed sessions that do not perform these request checks, a signer minting new credentials, and unbounded old publications. A global recovery claim must separately constrain every such acceptance path.
Keep the idea
Take it with you
- Stopping issuance, fixed-token expiry, and revocation are different actions.
- Status-cache bounds must include delayed stale publication and failure policy.
- Existing channels and resumption state require explicit retirement semantics.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.