The Credential Lifecycle

Each issued credential carries its own lifetime, independent of the session that requested it. Twenty minutes of issuance at a few hundred calls a minute can leave thousands of working credentials that stay valid for their full lifetime afterwards.

A maximum life: a ceiling measured from first issue that no renewal passes. Once it is reached the store refuses to extend, and the only way forward is a different credential, freshly issued and adopted by the consumer.

Renewal moves one field: the expiry. The value, the downstream account behind it and every connection using it stay as they are. Re-issuance mints a different credential, so every holder must be handed the new value and the old one withdrawn.

The downstream system must let the store create a principal on demand, attach exactly that consumer's rights to it, and remove it again — and must accept an identity for the store privileged enough to do all three.

Deleting the store's record removes only the store's bookkeeping. The account, role or key that credential names still exists in the downstream system, which keeps accepting it until that system itself withdraws it.

A capacity limit is shared across the fleet, so one identity can consume a small slice of it and never trip anything. Bounding a single identity needs per-identity limits: how fast it may mint, and how many of its credentials may be live at once.

Because it can bring new principals into existence with any rights it is allowed to grant, for as long as it exists. A minted account is one narrow slice; the identity that mints is the power to produce slices at will.

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.

The sessions. Re-reading updates a variable; connections authenticated with the previous value are untouched and keep whatever standing they had, and a fresh value reaches nothing until the consumer re-establishes them. Re-resolve and reconnect are two separate acts, and the fix needs both.

It ties each query, and everything that query did, to one named consumer without correlating start times. It does not identify the person or host behind that consumer, does not prove the value was not copied, and covers only what the warehouse itself records.

The margin: remaining validity against expected remaining work, both published while the job runs. Emit the moment the held credential stops being valid at resolve time, emit remaining runtime at each checkpoint, and alert when the first is smaller than the second.

Re-establishment. Most acceptors check a credential when a connection is set up, not on every request, so an open connection survives the expiry; the refusal arrives when the pool replaces that connection — after a reap, a reset, a maximum-age cap, or growth under load.

Issuance volume per requesting identity, against that identity's own baseline. Failure-shaped alerting stays silent because every call succeeded, and no single request in the loop is anomalous — the count in a window is the only thing that moved.

Live credentials with no holder. Each restart leaves a downstream account that nobody renews and nobody returns, valid until its own deadline. Stop it by returning the lease on shutdown, keeping the window short, and having the store withdraw what it issued when a lease lapses.

An already-open connection survived. Most systems authenticate when a connection opens and do not re-check per statement, so work under that account continues until something closes it. Fetched copies and store-side sessions survive the same way.

Make the unit of work, not the job, the thing that must fit inside a window: checkpointed units shorter than the shortest window issued, with a re-resolve and reconnect between them, delivered in a shared client so teams inherit it — and name the consumers that client cannot reach.

Parentage above all: which identity and which session requested the mint, plus the target, the issue time and the expiry. Without that link stored at mint time, credentials from a compromised identity are orphans that still work and cannot be listed.

Shorter windows shrink what a leaked credential is worth and clear orphans faster, but make every consumer's renewal path load-bearing. Land on a few credential classes with a stated window and ceiling each, chosen so forced re-issuance happens often enough to be trusted.

A system qualifies when it can create, narrowly grant and remove principals programmatically, and when the minting identity it demands is bounded. Keep a shared credential where removal is impossible, where the only way in is an unrestricted administrator you cannot justify, or where one credential reaches almost nothing.

Exactly one owner: the process holding the credential, or the companion beside it that fetched it — never both. It fires partway through the window, early enough that several failed attempts and a store blip still fit before the expiry.

Two: how fast the warehouse can create a principal, and how many principals it will hold at once. The second is usually hit first, because live accounts are consumers multiplied by how many generations of them are alive simultaneously.

Three 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.