skip to content

Which facts are safe to freeze into a short-lived access token at mint, and which must be looked up per request?

level: principalimportance: should knowfreq 46%

answer

  1. true at iat, asserted until exp
  2. cost of being wrong for one lifetime
  3. freeze the rule, not the list
  4. the lifetime is the staleness budget
  5. somebody has to sign the number

basics

~20 s

Freeze facts that change rarely and are cheap to be wrong about for one token lifetime; look up per request any fact whose being wrong is expensive or irreversible. The token lifetime is the staleness budget, and someone must sign off that number.

solid answer

~50 s

A fact written into a token at mint is true as of `iat` and asserted until `exp`, whatever happens in between. So the test is not "does this fact belong to the subject" but "what does it cost me if this is wrong for the whole lifetime, and who agreed to that cost?" A subscriber's tier changes monthly and being wrong about it for fifteen minutes is a billing correction, so freeze it. An embargo withdrawal is legally expensive and irreversible once copy has been pulled, so evaluate it at the pull. The consequence people dislike is that this makes the token lifetime an authorization decision, not a performance tuning knob: an entitlement withdrawn at 09:00 is still asserted by minted tokens until 09:15, and the honest design says that number out loud and puts a name against it.

code

json · 9 lines
json
{
  "sub": "masthead-4127",
  "iat": 1758240000,
  "exp": 1758240900,
  "titles": [
    "wire-uk", "wire-sport", "wire-photo", "wire-business",
    "wire-obits", "wire-weather"
  ]
}

go deeper

for a junior

Remember that a fact written into a token is fixed until the token expires: changing the database afterwards does not change what an already-issued token says. That is the trade you accept in return for not looking things up.

for a middle

Explain the freeze-versus-look-up test in terms of change rate and the cost of being wrong once, and show why a long list of permissions in a token is a bigger commitment than it looks, not just a bigger payload.

for a senior

Demonstrate that you treat the lifetime as a staleness budget with a stated number — an entitlement withdrawn at 09:00 is still asserted until 09:15 — and that you would measure the real interval rather than assert it.

for a principal

Own the negotiation: get the budget agreed and named by whoever owns the entitlement commercially or legally, and decide which single class of decision is worth moving onto the request path rather than shortening every lifetime across the estate.

The syndication hub mints a short-lived entitlement token; several hundred subscriber newsrooms present it when they pull an article. Every fact the hub writes into that token at mint is a photograph: true at the instant given by `iat`, and asserted as true until `exp`, regardless of what the hub's own database says thirty seconds later. Which facts are safe to photograph is the one decision here that no specification touches. The registered claims are specified, the algorithm is specified, the document format is specified — this is not. ## What freezing actually asserts Freezing a fact means the hub is promising that, for the whole token lifetime, acting on this fact is acceptable **even if it has since changed**. That is a stronger statement than it looks, and it is why "put everything in the token so the verifier never has to look anything up" is a performance argument answering a governance question. The corresponding cost of *not* freezing is real too: a per-request lookup re-introduces exactly the dependency the token was supposed to remove, and it does so on the hot path of every pull. ## The test to apply per fact For each candidate fact, ask three things in order: 1. **How often does it change?** Facts that change on a monthly contract cycle are different from facts a compliance desk can change in a phone call. 2. **What does acting on it wrongly cost, once?** A reversible billing discrepancy is not an embargo breach. 3. **Is the damage recoverable?** Copy that has been pulled, reformatted and printed cannot be un-pulled. | Fact | Changes | Cost of being wrong for one lifetime | Verdict | | --- | --- | --- | --- | | Subscriber identity | Effectively never | None | Freeze | | Contract tier and region | Monthly | A billing correction | Freeze | | Rate class or quota band | Monthly | Slight over-service | Freeze | | Embargo clearance on a title | Any moment, by a lawyer | An injunction | Look up at the pull | | Account suspended for non-payment | Any moment | Hours of free service | Look up, or accept a stated lag | | Per-title licence list | Weekly, and it is large | Access to unlicensed copy | Freeze the rule, look up the list | ## The budget is the lifetime, and it belongs to someone Once you accept that frozen facts go stale, the token lifetime stops being a performance number and becomes the **staleness budget**: the maximum time the system may act on a withdrawn entitlement. An entitlement withdrawn at 09:00 with a fifteen-minute lifetime is still asserted by already-minted tokens until 09:15. There is no way to un-assert those tokens by editing a database row, because nothing in the pull path consults that row — that is the whole point of the design. Three consequences worth stating plainly: - **Shortening the lifetime bounds the staleness, it never removes it.** A one-minute token still carries a minute of wrongness, and it multiplies issuance traffic by fifteen. - **The number needs a named owner.** "Fifteen minutes" should be a figure the business owner of the entitlement has agreed to, recorded next to the reason, not a default somebody copied. - **You should be able to prove it holds.** Measure the interval between an entitlement change and the last pull that still succeeded on it. If nobody measures it, the budget is an aspiration. ## Claim bloat is a design smell before it is a size problem The temptation with a large entitlement set is to freeze the enumeration: every licensed title, every permitted action. That token now grows with the customer, it is carried on every single pull, and — worse than its size — every entry in it is a separate assertion you are promising to stand behind for the full lifetime. The discipline is to **freeze the rule, not the list**: a tier, a region, a class. The rule is small, it changes rarely, and the expansion from rule to concrete permission happens where the permission is used and where the current data is at hand. ## What you cannot fix, and what you do instead You cannot make a minted token forget something. So when a fact genuinely must take effect immediately — a legal withdrawal, a suspected compromise of a subscriber — you have three honest moves, and you should be able to name all three: move that specific check to the pull path so no token asserts it at all; shorten the lifetime for that subject only, paying the issuance cost where it is justified rather than everywhere; or have the enforcement point consult a small, fast withdrawal list for that one class of decision, accepting that you have added a dependency and should say which one and what happens when it is unavailable. What is not honest is to write "we can revoke it" and leave the lag unstated.

  • A subscriber's embargo clearance is withdrawn and the legal team wants it effective now. What do you actually do?
    You cannot un-assert tokens already minted, so the embargo check has to stop being a frozen fact. Move that one decision to the pull path, where it reads current data, and leave the rest of the entitlement frozen. The alternative — shortening every token's lifetime — pays issuance cost across the whole feed to fix one class of decision.
  • Who signs off the staleness budget, and what does signing it off mean in practice?
    The business owner of the entitlement, not the engineering team. In practice it means a recorded number with a reason next to it, a named owner, and a measurement that shows the real interval between an entitlement change and the last successful pull on it. Without the measurement the budget is an assertion nobody can falsify.
  • Why not just make tokens last one minute and stop worrying about staleness?
    It bounds the wrongness at one minute rather than removing it, and it multiplies issuance traffic and the load on whatever mints, which is usually the least replaceable component you own. It also concentrates risk: the shorter the lifetime, the harder an issuer outage hits, because everything re-mints constantly.
  • The entitlement list is large and someone proposes putting it in the token to avoid a lookup. What is your answer?
    Freeze the rule that generates the list — a tier, a region, a class — and expand it where it is used. The enumeration grows with the customer, is carried on every request, and turns every entry into a separate promise held for the full lifetime, which is a much larger commitment than the lookup it was meant to avoid.

A frozen claim is a printed press pass with a date on it. The gate reads the pass, not the accreditation office, so a pass withdrawn this morning still opens the door until its date passes. You either print shorter passes, or you make the gate phone the office for the one or two things that genuinely cannot wait.

saying these in an interview costs you the question

  • Put everything in the token so nothing is ever looked up.
  • A short token lifetime means claims cannot go stale.
  • We can revoke the token, so a frozen claim never goes wrong.
  • If a frozen claim looks stale the consumer should decide for itself.
  • Claim bloat is only a payload-size problem.
  • The token lifetime is a performance setting, not an authorization one.