skip to content

On a contractor's last day you revoke their operator identity — what happens to the downstream credentials it generated over six months?

level: seniorimportance: must knowfreq 52%

answer

  1. two requests, one word
  2. parent stops asking, children keep working
  3. a cascade needs recorded parentage
  4. enumerate from the issuance records
  5. orphans come from reconciliation, not cascade

basics

~20 s

Nothing automatic, unless the store recorded which identity requested each credential and acts on that link. Where it did not, every generated credential stays live and independent until its own expiry or a manual withdrawal.

solid answer

~40 s

Two different requests hide behind the word revoke. Revoking one credential stops one downstream account. Revoking an identity stops that identity asking for more, and reaches what it already minted only if the store kept the parentage and acts on it. Designs genuinely differ: some record every issued credential against its requester and cascade the withdrawal; others treat each issued credential as an independent object that outlives the requester entirely. So establish which you have, stop the identity issuing anything further, then enumerate from the issuance records what it generated and in which systems, and withdraw each one there. Anything with no recorded parent is an orphan you find by reconciling inventories, not by cascade.

code

pseudocode · 17 lines
pseudocode
revokeEverythingMintedBy(identityId):
    identityStore.suspendIssuance(identityId)        # first: the list cannot grow mid-walk

    minted   = issuanceRecords.find(requestedBy = identityId, state = "active")
    unfinished = []

    for each cred in minted:
        system = downstream[cred.systemId]
        if system.withdraw(cred.accountName):
            issuanceRecords.mark(cred.id, state = "withdrawn", at = now)
        else:
            unfinished.append(cred)                  # not withdrawn; never assume it is

    if unfinished is empty:
        identityStore.remove(identityId)             # parent removed only when children are gone

    return unfinished                                # each item needs an owner and a reason

go deeper

for a junior

Recall that removing an identity stops it asking for new credentials; whatever it already obtained is a separate population with its own life.

for a middle

Explain the dependence on recorded parentage, and why a store that issues free-standing credentials leaves every one of them live after the requester is gone.

for a senior

Demonstrate the order: suspend issuance, enumerate, withdraw at each accepting system, collect failures by name, and only then remove the identity itself.

for a principal

Argue for what the estate must record at issuance time so that a departure is an enumerable list rather than a reconciliation across a dozen downstream systems.

## Two requests hiding behind one word "Revoke it" means two different jobs on this material, and the first thing to do is work out which one you were asked for. - **Revoke one credential.** A single value has leaked or a single consumer is being retired. The work is bounded: withdraw one downstream object, confirm it, done. - **Revoke everything an identity generated.** A person is leaving, or an identity is believed compromised. The work is a *population* — six months of requests, each of which created a real object somewhere, most of which nobody has thought about since. The second is not the first repeated. It has a discovery step the first does not have, and the discovery step is where it fails. ## Parentage is a design decision, not a property of stores Whether the store can even answer "what did this identity mint?" depends on a choice its designers made: - Some stores record the requesting identity against every credential they issue and treat those credentials as **children**: withdrawing the parent walks the list and withdraws each one. - Some stores issue a credential as a free-standing object. The requester's name may appear in an access record somewhere, but nothing links the credential to it operationally, and removing the identity affects only future requests. - Some sit in between: the link exists for credentials minted through one path and not for those minted through another, which is the worst case, because the list looks complete. Say which you have before you promise anything. A cascade you assume and do not have is the mechanism by which a departure becomes a live account six months later. ## Walking the cascade 1. **Stop the identity issuing.** Suspend or disable it first, so the population you are about to enumerate cannot grow while you work through it. Doing this last leaves a race you cannot win. 2. **Enumerate.** Pull every credential recorded against that identity that is not already marked withdrawn, with the downstream system each one belongs to. 3. **Withdraw each one at its own accepting system.** Not in the store — in the system that honours it. Different systems, different operations, different people who own them. 4. **Collect the failures.** A downstream system that is unreachable, an operation that errors, a name that does not exist any more for an unclear reason: each of these is an item that is *not* withdrawn and needs a person's name against it. 5. **Remove the identity itself last**, once the list is clear, and record what the run covered. | | Store records parentage | Store does not | |---|---|---| | Removing the identity | Stops new issuance and drives the walk | Stops new issuance only | | The generated credentials | Withdrawn as the walk reaches each one | Live until their own expiry or a manual withdrawal | | Finding what exists | Read the issuance records | Reconcile each downstream system's account list | | What you can state afterwards | A covered list plus named exceptions | An estimate, until the reconciliation finishes | ## Orphans: what the cascade cannot reach A cascade covers exactly what was recorded. Everything else is an orphan, and orphans are real: a credential minted through a path that did not record the requester; an account the contractor created directly in the downstream system rather than through the store; a credential recorded against a shared identity that several people used, so the parent link is true and useless. None of these appear in a cascade and all of them keep working. Finding them is a different exercise from revoking: list what actually exists in each downstream system, subtract what the store believes it issued, and treat every remainder as unowned until somebody claims it. That reconciliation is slow and it is the only thing that catches the population the cascade could not see. ## What you can honestly say at the end The departure ticket wants "revoked". What you can defend is narrower and more useful: the identity can mint nothing further as of a stated time; *n* credentials recorded against it were withdrawn at their accepting systems and confirmed; *m* were not, each named, each with an owner and a reason; and the reconciliation that would find anything unrecorded is either done or scheduled. Stating the gap is the difference between a withdrawal and a belief about one.

  • Why suspend the identity's ability to issue before enumerating, rather than after the walk?
    Because the population you enumerate is a snapshot. If the identity can still mint while you work through the list, a credential created after your query is never in it, and the walk ends clean while a fresh account sits outside it. Suspending first freezes the list you are about to promise you covered.
  • A shared identity was used by four people and a departure cascade would withdraw everything it minted — what do you do?
    Nothing silently. The cascade is technically correct and operationally an outage: three people's live consumers depend on credentials minted under that name. Establish which credentials belong to which consumer, replace the ones that must survive, then cascade. The lesson afterwards is that a shared requester makes attribution and withdrawal mutually exclusive.
  • What distinguishes an orphaned credential from one the cascade simply failed to withdraw?
    A failed withdrawal is known: it is in the list, it has a name and a reason, and somebody owns finishing it. An orphan is not in the list at all, because the link between it and a requester was never recorded. The first is tracked work; the second is found only by comparing the downstream system's own inventory against what the store believes it issued.

saying these in an interview costs you the question

  • Assumes disabling an identity kills everything it ever generated
  • Says every store cascades revocation to the credentials it issued
  • Treats the issuance records as complete without reconciling downstream
  • Withdraws the children while the identity can still mint new ones
  • Counts the parent identity's removal as the end of the work
  • Reports a walk with failures in it as fully revoked