Skip to content

Lease-Bound Capability Token

Capability artifact — instantiates Use-Time Precondition Binding

Grants permission as a self-expiring token whose short validity window bounds the check–use gap, so a stale grant simply stops working instead of needing to be revoked.

A Lease-Bound Capability Token packages a verified precondition into a bearer credential that carries its own expiry: the check happens once, at issue, and the grant it produces is valid only for a bounded window — the lease. Its defining move is to make authority self-expiring rather than revocable. Instead of re-asking at every use "is this grant still good?", you keep the grant so short-lived that a stale one is simply inert. The dangerous gap between check and use is not left open; it is capped at the lease length, which is chosen deliberately from the risk of the action. A token is a thing you hold and present, not a question you re-ask — and that is exactly why it binds without a round-trip.

Example

A guest checks into a hotel. At the front desk the clerk verifies the reservation and identity once, then programs a key card that opens the room's lock only through the checkout date. Nobody re-verifies the booking on each tap of the card, and — crucially — nobody has to hunt the guest down to deactivate the card at departure. At checkout the lease simply lapses, and the same piece of plastic opens nothing. Extend the stay, and the desk re-issues a fresh lease against the current booking. The window is sized to the stakes: a room card is good for days, but the card that escorts a guest to a safe-deposit box is good for minutes and only in that corridor. The card is never treated as proof that the reservation is currently valid — only that the guest is still inside the granted window.

How it works

  • Verify once, stamp an expiry. The precondition is checked at issue time and the result is bound into the token as a validity window — a time-to-live, a not-after timestamp, or a bounded number of uses.
  • Let the grant self-expire. No party has to actively withdraw it; when the window closes the token is dead weight. This trades a bounded staleness window for eliminating the revocation round-trip entirely.
  • Renew, don't patch. Continued access means re-checking the precondition and re-issuing a new lease; each renewal re-attaches the grant to current state.
  • Size the lease to the blast radius. Short leases where the state is volatile or the action is costly to get wrong; longer leases where the state is stable and re-issuing is expensive.

Tuning parameters

  • Lease length — shorter windows shrink the staleness gap but multiply renewals and load on the issuer; the central trade-off of the whole mechanism.
  • Renewal model — silent auto-renew versus a forced re-check on renewal; auto-renew is smooth but can quietly carry a grant past the moment its precondition changed.
  • Bind tightness — how narrowly the token is scoped — one resource, one action, one bearer, versus broad; tight scope caps the damage a leaked or over-long token can do.
  • Clock trust — whose clock decides expiry; skew between issuer and user clocks silently lengthens or truncates the real window.
  • Grace / overlap — whether an expiring lease overlaps its renewal; a grace band avoids cutting off a mid-operation user but reopens the very window it was meant to close.

When it helps, and when it misleads

Its strength is that it removes the need for a reliable, always-reachable revocation channel — the dominant reason distributed systems reach for leases at all[1] — and it fails safe by default: when in doubt, the grant lapses rather than lingering. It is the right tool when re-checking at every use is expensive but issuing fresh grants is cheap.

Its failure mode is that the lease length is a bet about how fast the world changes, and a window that felt comfortable can be far too long the moment a precondition flips right after issue — the fired employee whose day-long token stays live for hours. "Convenience" leases stretched for performance quietly recreate the exact durable-permission defect the archetype exists to kill, and the whole scheme leans on clocks, so skew or a frozen clock can keep a dead lease alive. The classic misuse is lengthening leases until they are effectively permanent and then treating the token as proof of current authority. The discipline is to pick the lease from the risk tier, not from convenience, and to pair any genuinely revocable condition with Revocation Status Check at Use rather than trusting expiry alone.

How it implements the components

  • validity_window_or_lease — the token's core: a bounded window stamped at issue, after which the grant is void without any further action.
  • checked_precondition_claim — the token is the checked claim made portable; issuing it is the act of recording "this was verified, here, now."
  • risk_tiered_gap_budget — the lease length is the check–use gap the issuer is willing to tolerate, set explicitly by the risk tier of the action.

It does not consume an invalidation_and_revocation_signal (that's Revocation Status Check at Use) or take an atomic_or_exclusive_use_boundary on the resource (that's Lock or Hold Until Use); a lease bounds the gap by time rather than watching or excluding the state inside it.

Notes

A lease answers only "is this still within the granted window?" — never "is the underlying condition still true?" The two coincide only when nothing can invalidate the condition faster than the lease expires. That gap is precisely why high-stakes grants keep leases short and add an explicit revocation check, rather than solving the problem by lengthening the lease.

References

[1] A lease grants time-bounded permission that lapses automatically, trading a small bounded staleness window for the elimination of an explicit revocation message. The mechanism was introduced for distributed cache consistency by Gray and Cheriton (1989) and is the standard reason systems prefer expiry to revocation when a revocation channel is unreliable. ↩