Skip to content

Revocable Authority Token

Security artifact — instantiates Definition-Time Context Binding

A scoped, expiring credential bound to a delegated action so it runs with exactly the authority its issuer intended — withdrawable at any time, never inheriting the host's ambient privileges.

A revocable authority token is a bearer artifact that carries a specific, bounded slice of permission — this action, on these resources, until this expiry — bound to a delegated behavior at the moment it is issued. When the behavior later runs, on a worker or service that itself may hold far broader privileges, it acts with the token's scoped authority rather than the host's ambient account. Its defining move over a plain capability is the revocation lifecycle: the grant can be narrowed, refreshed, or withdrawn after it was captured, so authority that was correct at definition time does not outlive the consent, contract, or role that justified it. The token references the underlying secret indirectly, so the delegated bundle carries a withdrawable claim, not a raw credential.

Example

A nightly export job runs on a shared worker fleet whose service account can touch every bucket. Rather than let the job inherit that, the scheduler mints a token scoped to read one dataset, write one export bucket, expiring in six hours, and hands it to the job. The job carries the token, not the fleet's keys.

Weeks later the third-party analytics vendor the export feeds is off-boarded. An operator revokes the token; the next run fails closed with no access, even though the worker account is unchanged and nothing about the job's code was touched. Scoping bounded what the delayed action could ever do; revocation let the delegation be undone the moment its justification ended — the two properties a standing credential on the worker could not have offered.

How it works

  • Mint at delegation time with an explicit scope. The issuer states the exact capabilities (verbs, resources, audience) and an expiry and binds them to the action — least privilege by construction, not by the host's defaults.
  • Reference the secret, don't embed it. The token is a validatable, traceable claim, typically pointing at or derived from a credential held elsewhere, so a serialized bundle never carries the raw key.
  • Keep a revocation handle. Because the grant is registered, it can be shortened, rotated, or killed independently of the behavior holding it — the property that separates this from a permanent capability.
  • Fail closed. On expiry or revocation, resolution denies rather than falling back to the host's ambient authority.

Tuning parameters

  • Scope breadth — how narrow the granted capability is. Tighter scope limits blast radius but may need more tokens; broad scope is convenient and dangerous.
  • Lifetime / expiry — short-lived tokens self-heal (a leak simply expires) but need refresh machinery; long-lived tokens are simpler and riskier.
  • Revocation model — immediate central check versus cached/eventual. Immediacy costs a lookup on every use; caching trades freshness for speed and leaves a window where a killed token still works.
  • Refresh policy — whether and how a near-expiry token is renewed, and under whose continued consent.
  • Binding strength — bearer (whoever holds it may use it) versus sender-constrained (bound to a key or audience, so a stolen token is useless).

When it helps, and when it misleads

Its strength is letting work be delegated across time and machines without handing over standing power — the archetype's "authority travels with a delayed action without inheriting the full privileges of its host." Revocability means a delegation can be undone when consent or need ends, and expiry bounds the damage of a leak.

The classic misuse is issuing a broad, long-lived token and calling it scoped — authority smuggling, where the "capability" is really ambient power with a friendly label. Others: embedding a real secret in a serialized bundle (secret serialization), or a revocation so eventually-consistent that a killed token still works for a window. The named hazard this mechanism exists to defeat is the confused deputy — a privileged host manipulated into using its own authority on a caller's behalf; a scoped token means the deputy can wield only what was delegated.[1] The discipline is least privilege, short lifetimes with real refresh, revocation checked at use, and never serializing the underlying secret — reference it.

How it implements the components

  • authority_and_capability_boundary — the token is the explicit boundary: the exact permissions the behavior may exercise, and no more.
  • rebinding_refresh_and_revocation_policy — issuance, refresh, and revocation are first-class operations on the grant; revocability is the mechanism's signature.
  • secure_secret_reference — the token references the underlying credential indirectly, so a captured or serialized bundle carries a withdrawable claim rather than a raw secret.

It governs authority, not meaning or transport: it does not capture the behavior's code or free variables (Lexical Closure), serialize and move the work (Serialized Job Envelope), or attest the integrity of the surrounding context (Signed Context Manifest). A non-revocable, possession-based grant is a Capability Object.

Notes

A token is only as revocable as the checks that honor it. If resolution ever falls back to the host's ambient authority when the token is missing, expired, or unverifiable, the entire guarantee is void — the fail-closed posture, not the token itself, is what makes the scope real.

References

[1] The confused deputy (a classic capability-security problem, named by Norm Hardy) is a program holding broad authority that is tricked into exercising it for a less-privileged caller. Binding a narrowly scoped, revocable capability to the delegated action — rather than letting it run on the deputy's ambient rights — is the standard structural defense. ↩