Your estate mints credentials in a dozen downstream systems — what must a completed withdrawal be able to prove?
answer
- define revoked before the incident
- three clauses, one per survivor
- withdraw, list, records
- state the lag per system
- shorter lifetimes where proof is impossible
basics
~20 sThree things: nothing remains established under the credential's name, nothing succeeded under it after a stated moment, and the identity that minted it can mint no more. Whatever cannot be shown is recorded as an assumption.
solid answer
~40 sTreat withdrawal as a claim somebody has to be able to check, and settle what it means before an incident rather than during one. Every generated credential needs a durable record of which identity requested it and which system honours it. Every downstream system owner has to supply three capabilities: an operation that withdraws, a way to list what is currently established under a name, and access records queryable after a given moment. A withdrawal is then complete when the established list is empty and the records are silent across an observation window you chose. The systems that cannot supply all three are the actual decision: either shorten what you issue there so waiting is tolerable, or accept a stated assumption and carry it into the incident record by name.
go deeper
Recall that a completed withdrawal is a claim about the accepting system, and that someone later will ask for evidence rather than for the ticket.
Explain the three clauses — no further authentication, nothing established, no successful use after a cutoff — and which capability each one needs downstream.
Show how you would run this across several systems at once: stated lags, an observation window, and named exceptions rather than a single aggregate status.
Take a position on whether unprovable systems are excluded outright or tiered with shorter lifetimes, and defend the cost that position pushes onto other teams.
## Withdrawal as a claim someone can check At estate scale the interesting question is not how to revoke one credential — it is what the word means when twelve teams each say they did it. Without an agreed definition, "revoked" compresses three very different situations into one word: a downstream account genuinely removed and verified; a store record deleted and nothing else; and a call that returned an error nobody read. A lead's job here is to fix the definition in advance, because the moment you need it is the moment nobody has time to negotiate it. A workable definition has three clauses, each of which maps to a survivor: 1. **No further authentication.** The account, role or key entry the credential names is gone or disabled in the system that honours it. 2. **Nothing established remains.** No connection or session is currently running under that name. 3. **No use after the cutoff.** The accepting system's own records show no successful request under that name after a stated moment, across a stated window. And one clause about the parent: **the identity that minted it can mint no more**, otherwise you are withdrawing from a population that is still growing. ## What each downstream owner has to supply The clauses turn into an interface that each system owner in the estate must be able to satisfy: 1. **Withdraw by name** — an operation with a definite outcome, not a request into a queue whose completion nobody observes. 2. **List what is established by name** — so clause two is checkable rather than assumed. 3. **Access records queryable after a moment, including successes** — so clause three is checkable. Records that hold only failures are useless here: a surviving credential succeeds. Each owner should also state a **lag**: the maximum time between the withdrawal call and it taking effect everywhere that system serves from. A system with replicas that converge in a minute and a system that converges when an operator notices are both acceptable if the number is known, and neither is acceptable if it is not. ## Systems that cannot answer | Capability | What withdrawal there can prove | The compensation | |---|---|---| | Withdraw, list, records | All three clauses | None needed; this is the standard | | Withdraw and records, no list | Nothing established is unknown | Terminate bluntly by cycling, or accept and state it | | Withdraw only | Only the first clause | Issue much shorter lifetimes so survivors self-limit | | No withdraw at all | Nothing | Do not mint there through the store; the credential is a manual object with a manual owner | The bottom two rows are where the real judgment sits. Shortening lifetimes converts an unprovable withdrawal into a bounded wait: if nothing issued there lives longer than fifteen minutes, an unconfirmed withdrawal is an exposure measured in minutes rather than an open question. That trade has a cost — more issuance traffic, more moving parts, consumers that must tolerate frequent change — and it is paid on every credential, not just on the day of an incident. Whether it is worth paying depends on what that system reaches. ## What the contract costs It is not free, and pretending otherwise gets it rejected: - Every system owner has to expose and maintain three capabilities, some of which they had no reason to build. - The record linking each credential to its requester is itself an inventory of who can reach what, which is sensitive and has to be protected and retained accordingly. - Confirmation takes wall-clock time. An observation window means the incident is not closed at the moment of the call, which is unpopular precisely when people want it closed. ## The decision a lead actually owns Two positions are coherent. One is to require the three capabilities everywhere and refuse to mint credentials through the store into a system that cannot provide them, which is clean, slow and forces work onto other teams. The other is to accept tiers, publish which systems are in which tier, and set credential lifetimes per tier so that unprovable withdrawals are bounded by construction. The incoherent position is the common one: a single word "revoked" applied across all twelve systems, meaning something different in each, discovered only when an external audit asks who could have used this name and when — and the answer has to be assembled from a dozen inconsistent sources, after the fact, under pressure.
- Why does the contract need each system's lag stated, rather than just a withdraw operation?Because a withdrawal that returns immediately and takes effect somewhere else minutes later has a window in which the credential still works, and a confirmation run inside that window reports a survivor that is not one. Knowing the number tells you how long to wait before checking, and turns a flaky result into an expected one.
- How short is short enough where withdrawal cannot be proven?Short enough that the unprovable window is an exposure you would accept without acting. If your incident response expects containment within an hour, credentials whose withdrawal you cannot confirm should not outlive an hour by much. State the number as a decision with a reason, not as a default someone inherited.
- What does the record linking credentials to requesters cost you to keep?It is a map of which identity can reach which system, so it needs the protection and the retention rules of any sensitive inventory, and it must outlive the credentials themselves to be useful after a departure. It also has to be maintained: a path that mints credentials without writing the link quietly puts them outside every future cascade.
saying these in an interview costs you the question
- Treats a returned withdrawal call as proof the credential is gone
- Accepts access records that log only failed authentications
- Lets revoked mean something different in each downstream system
- Omits the parent identity, so the population grows during the withdrawal
- Declares completion with no observation window or stated lag
- Assumes a system with no way to list established sessions is still provable