A Credential Designed to Die

Most credentials are built to survive for a while. We protect them, rotate them, give them expiration times, and keep a way to revoke them if something goes wrong.

That model is useful, but it was a poor fit for one part of our system.

We needed a credential for a single governed transition: one task, crossing one gate, under the state that existed at that moment. If the task ran later, or the state changed underneath it, we did not want the old credential to remain useful simply because its timer had not expired.

That is the problem JBD is meant to address.

What JBD is for

JBD—short for Jitter-Bug Depolarization—is our name for a state-bound, one-time crossing token. It is not meant to identify a machine or prove that the machine was admitted into the system. Other controls already handle those jobs.

JBD has a narrower purpose: represent the authority for one transition at the point where that transition is ready to happen.

That distinction sounds small, but it changes when the token should be issued and what the verifier must check.

If we issue it when a task is created, it describes the state at creation time. The task may sit in a queue, pass through review, or wait on another system before execution. By then, the facts used to approve it may have changed.

So the token belongs near the end of the process, not the beginning.

Mint it at the crossing

The sequence we are working toward looks like this:

1. Create and review the task.
2. Resolve its route and scope.
3. Run the required governance checks.
4. Confirm that the relevant identity and system state are still current.
5. Mint the crossing token.
6. Execute the transition.

The token is the last expression of a decision the system has already made. It is not a permission slip that a task carries around while waiting to run.

That also gives failures more useful meaning. A legitimate caller can still be refused at the final gate. That does not necessarily mean its identity is wrong. It may mean the state has moved, the required authority is incomplete, or the system cannot establish the conditions needed for a unique transition.

Lumping all of those outcomes under “authentication failed” made debugging harder. We now treat caller identity, machine admission, and crossing authority as separate questions.

Expiration is not enough

A short expiration time reduces a replay window, but it does not change what a token is. During that window, a copied token is still the same object and may still be accepted.

JBD is designed around a stronger requirement: the verifier should re-derive the conditions that made the token valid.

We divide those conditions into two broad channels. One describes identity—the actor, machine or assembly, and task involved in the transition. The other describes current governed state. The token should resolve only when those channels still match the transition for which it was issued.

If the relevant state changes, the old token should stop resolving even if its bytes are intact.

We sometimes call that “structural death.” The phrase is useful internally, but the plain-language version is better: the token referred to a relationship that no longer exists.

This is an architectural goal, not a magical property conferred by terminology. It depends on the issuer and verifier using the same inputs, on state changes being recorded correctly, and on tests demonstrating that old tokens cannot be reused after those changes. Those tests matter more than the name.

The operational cost

One-time, state-bound authority is not free.

The system has to gather current state at issuance and verification. Operators need to distinguish an identity failure from a stale-state refusal. Retries cannot simply replay the previous credential. Observability has to show why issuance stopped without exposing the authority material itself.

There is also a temptation to add a fallback when the stronger path refuses to mint. That may improve availability, but it can quietly turn a one-time control back into a standing credential. We would rather surface the refusal clearly than hide it behind a more permissive mechanism.

What we learned

The useful lesson was not that every credential should die immediately. Most should not.

The lesson was that credential lifetime should match the decision it represents.

A machine identity may need to persist. Admission into a governed system may need to persist until it is revoked. Authority for one transition should not automatically inherit either lifetime.

For JBD, successful reuse would mean we had put the token in the wrong part of the lifecycle—or failed to bind it to the state we claimed it represented.

That led to the next problem we had to untangle: one of our persistent security measures had ended up deciding whether a one-time token could be issued. The control itself was legitimate. It was simply sitting in the wrong seat.