You set the issuance standard for a shared store — what must every mint record so one compromised identity stays survivable?

## Start from the question the incident will ask At 02:40, forty minutes into a takeover, somebody will ask: **what did this identity mint, and what of it is still live?** Every other decision in the response waits on that answer — how wide the reach is, which teams to wake, whether the tail closes on its own in an hour or a week. Designing issuance for a compromised identity means designing so that this question is a query that returns in seconds. That is a design-time property. Nothing you do at 02:40 can create a link that was not written at mint time. ## What each issuance record carries - **`parentIdentityId`** — the identity that requested it. This is the field the whole incident hangs on. - **`parentSessionId`** — the bounded session it was minted under, which narrows the set to one episode rather than to everything the identity has ever done. - **`issuedAt` and `expiresAt`** — the window, so the tail length is arithmetic rather than a guess. - **`target`** — the downstream system it works against, so the reach is listable and each owner can be told precisely what to withdraw. - **`owner`** — the team accountable for the consumer, so the escalation path is in the record rather than in somebody's memory. - **`revokedAt`** — null while live, which is what makes "still live" a filter instead of an inference. ## The orphan, and what it costs A credential minted with no stored parentage still works perfectly. It is simply unfindable from the parent's side. Cleanup then becomes a sweep of every downstream system for accounts created in a window — plausible against one database, unrealistic against forty target systems owned by a dozen teams, and it cannot separate the attacker's 4,000 from the fleet's legitimate mints in the same window unless something in the target's own record carries the requester. That is the practical difference between a two-hour incident and a two-week one, and it is decided by one stored field. ## The cleanup contract, stated in the standard 1. **Revoking a parent identity produces the list of its live children** — every record where `parentIdentityId` matches, `revokedAt` is null and `expiresAt` is in the future. 2. **Withdrawal is confirmed at the target**, not inferred from the store's own record. A store that has marked a credential revoked has updated its bookkeeping; the downstream system decides whether the credential still opens the door. 3. **Anything that cannot be withdrawn is escalated**, with its expiry attached, rather than quietly dropped from the list. A credential you cannot withdraw is a countdown you have to staff. ## The judgment call: automatic or reviewed | | Automatic cascade | Reviewed list | |---|---|---| | Time to contain | seconds | as long as the review takes | | Cost of a mistaken revoke | every consumer under that identity stops at once | bounded; a human sees the list first | | Fits | short-lived children a consumer can re-request immediately | long-lived children, or targets where the account carries state | | Failure to plan for | a cascade nobody rehearsed firing during a busy hour | a list nobody triaged while the tail ran | Most estates land on **automatic for generated short-lived children and a reviewed list for anything long-lived** — and then, crucially, rehearse the automatic path once, off-hours, before an incident needs it. An untested cascade is a claim, not a control. ## The three parts only work together - The **record** makes cleanup possible — without it you cannot list what to withdraw. - The **cap** makes cleanup small — the difference between withdrawing 10 credentials and 4,000. - The **alert** makes cleanup timely — it fires while the loop is running rather than at the next morning's review. A standard carrying only one of the three sounds complete and is not: perfect records of an unbounded, unnoticed incident still take days to work through. ## What to require of a team onboarding a workload - Declare the identity class's **legitimate live count and mint rate**, which become the caps. - Name the **owner** and the escalation contact, stored on the record rather than in a wiki. - State the **maximum life** the consumer needs, so the tail is a chosen number. - **Prove the cleanup once**, in a drill, before the first incident relies on it. ## The part that fails quietly Retention. If issuance records are pruned after 7 days but credentials may carry a 30-day maximum life, then any child minted 10 days ago is live with no parent row — an orphan created by a retention setting rather than by a missing field. Match the record's retention to the longest credential lifetime the standard permits, plus margin, and make sure the records survive the store's own backup and restore: a restore that brings back the credentials but not their parentage rebuilds the estate and loses the ability to clean it up.