Signed Delegation Token¶
Delegation credential — instantiates Principal-Bound Authority Mediation
A cryptographically signed, self-contained artifact that carries the originating principal, the permitted scope, and freshness bounds with it, so any downstream deputy can verify the delegation offline before acting.
When a request must cross several services, the danger is that the originator's identity and intent fall off along the way, leaving each hop to act on trust alone. Signed Delegation Token stops that by putting the delegation into a portable artifact that travels with the request. The token is a signed bundle of claims — who the originating principal is, the exact scope they authorized, and the freshness window in which it is valid — and its signature makes it unforgeable and tamper-evident: a downstream deputy can verify it against the issuer's key and read the delegation directly, without calling back to ask. Its defining trait is that it is a self-contained, verifiable credential — the delegation is the data structure, carried and checked, not a live conversation between services.
Example¶
A ride-share platform's dispatch service, on completing a trip, must charge the rider through a separate payments service. The naïve design has dispatch call payments with its own broad service credential — a confused-deputy risk, since dispatch could then be induced to charge any rider any amount. Instead, when the rider confirms the trip, the account service issues a signed delegation token: it names the principal (rider u-40917), the scope (charge, this trip, up to the quoted fare), and a freshness bound (valid for ten minutes). Dispatch forwards that token to payments unchanged.
Payments does not trust dispatch's say-so. It verifies the token's signature against the account service's public key, confirms the token has not expired, and reads the scope: this charge must be for rider u-40917, this trip, within the fare ceiling. A dispatch bug — or a compromised dispatch node — that tried to charge a different rider or a larger amount would present a token whose scope does not match, and payments would refuse. The rider's authority travelled to the point of execution as evidence, rather than dissolving into dispatch's standing power.
How it works¶
- Bind the claims at issuance. The issuer stamps the originating principal, the permitted action and resource scope, and freshness bounds into one structure at the moment authority is delegated.
- Sign it. A cryptographic signature (or MAC) over the claims makes the token unforgeable and any tampering detectable, so its contents are trustworthy wherever it lands.
- Carry it with the request. Each hop forwards the token unchanged; the delegation moves with the work instead of being re-asserted by intermediaries.
- Verify before acting. The executing deputy checks the signature, confirms freshness, and evaluates the request against the token's scope — offline, without a callback — refusing anything the token does not cover.
Tuning parameters¶
- Lifetime — how long the token stays valid. Short lifetimes shrink the replay window if a token leaks but force more frequent re-issuance and tighter clock discipline.
- Scope granularity — a broad audience versus a token minted for one action on one resource. Narrow scope contains misuse but multiplies issuance and can leak intent into the token's structure.
- Signature scheme — symmetric MAC (fast, shared secret) versus asymmetric signature (verifiable by parties that cannot mint). Asymmetric suits multi-party fan-out at higher verification cost.
- Audience restriction — naming the intended recipient service so a token presented elsewhere is rejected. Tightens containment but requires knowing the path in advance.
- Revocation strategy — pure expiry versus a revocation check. Expiry-only is stateless and simple; revocation catches early compromise at the cost of a lookup that erodes the offline-verification benefit.
When it helps, and when it misleads¶
Its strength is that the delegation is portable and self-verifying: any number of hops can carry it, and the deputy that finally acts can confirm the originator, scope, and freshness on its own. Contained, short-lived, narrowly-scoped tokens turn "trust the calling service" into "verify the caller's authorization," and designs like macaroons show scopes can even be attenuated — narrowed but never widened — as the token is passed along.[1]
Its failure modes cluster around the token being a bearer artifact: whoever holds it can use it, so a leaked token is a usable one until it expires, and over-broad scope or over-long lifetime turns a convenience into a skeleton key — the archetype's token-scope-overbreadth failure in concrete form. Stateless verification also means a token stays valid after the underlying authority is revoked, up to its expiry, unless a revocation check is added back. The guarding discipline is to mint tokens as narrow and short-lived as the workflow tolerates, bind them to an audience, and transmit them only over confidential channels so possession stays with the intended holder.
How it implements the components¶
originating_principal_claim— the token's core payload names the principal whose authority is being delegated, carried verifiably to the point of execution.request_intent_scope— the signed scope fixes the exact action and resource the delegation permits, so a generic credential cannot be replayed into a different action.delegation_context_record— freshness bounds, audience, and issuance context ride in the token as the delegation evidence a deputy checks before acting.
It does not run the exchange that strips a deputy's own broad credential and re-derives authority across hops — that deputy_execution_authority narrowing and ambient_authority_exclusion belong to its nearest twin On-Behalf-Of Authorization Flow; this mechanism is the signed artifact, the twin the protocol that moves it.
Related¶
- Instantiates: Principal-Bound Authority Mediation — supplies the portable, verifiable credential that carries a principal's scoped authority across service hops.
- Sibling mechanisms: On-Behalf-Of Authorization Flow · Policy-Engine Subject Binding Check · Scoped Service-Account Impersonation · Object-Capability Reference · Delegation Audit Log · Confused-Deputy Abuse-Case Test · CSRF Token Challenge · Origin and Referer Gate
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Signed Delegation Token operates by maintains a signed scoped capability configuration with principal, action, resource, and freshness bounds. That concrete deployed or enacted form is Structure, Architecture & Configuration under the frozen taxonomy.
Nearest alternative: Rule, Policy & Commitment — Although Rule, Policy & Commitment can support this mechanism, the frozen evidence makes its operative form the act that maintains a signed scoped capability configuration with principal, action, resource, and freshness bounds; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Security Studies & Intelligence Analysis
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: A signed self-contained token carrying principal, scope, and freshness bounds is an authorization-security primitive. RFC 9068 specifies signed access-token claims and scope, while JWT supplies the portable cryptographic form.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: a cryptographically signed, self-contained artifact that carries the originating principal, the permitted scope, and freshness bounds with it, so any downstream deputy can verify….
- Law & Governance — Agency and delegated authority define what acts bind the principal.
- Organizational & Management Science — Role and approval structures determine legitimate downstream deputies.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus security_intelligence). Authoritative or primary research supports security_intelligence as the best historical origin: A signed self-contained token carrying principal, scope, and freshness bounds is an authorization-security primitive. RFC 9068 specifies signed access-token claims and scope, while JWT supplies the portable cryptographic form. The cited IETF RFC 9068, JWT Profile for OAuth 2.0 Access Tokens; IETF RFC 7519, JSON Web Token directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records lineage, while domain_reach=specialized records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
References¶
[1] Macaroons (Birgisson et al., Google, 2014) are bearer credentials that carry embedded caveats — scope restrictions — and can be attenuated by any holder appending further caveats, so authority can only ever be narrowed, never widened, as the token is passed on. They are a concrete demonstration of a signed delegation token whose scope travels and tightens with it. registry ↩