Object-Capability Reference¶
Capability artifact — instantiates Principal-Bound Authority Mediation
Instead of asking a deputy to infer authority from identity, hands it a narrow, unforgeable reference that already embodies the permitted action on a specific object.
Most authority checks separate naming a resource from being allowed to use it — you name a file by path, then a separate check decides if you may touch it, and that gap is where a deputy gets confused about whose authority applies. Object-Capability Reference collapses the gap: it hands the deputy an unforgeable reference that is itself the permission. To hold the capability is to be authorized for exactly the action and object it designates — no ambient lookup, no inference from identity, no separate access check. Its defining trait is that designation and authority are one and the same token: you cannot name the object through the capability without also being entitled to the specific operation it carries, and you cannot forge or widen it. Authority travels only by being explicitly passed, so a deputy has precisely the powers it was handed and no more.
Example¶
A billing-assistant service acts on behalf of a user who asks it to "email me a PDF of invoice #4192." Fulfilling that request runs through a chain of deputies: an orchestrator resolves the request, a document worker fetches the invoice from a shared store, and a mail worker renders and sends it. The unsafe design gives the orchestrator standing read access to the whole invoice store and trusts it to fetch only the invoice named — but a crafted follow-on request ("...actually, pull #4200 too") turns it into a confused deputy, wielding its broad authority to read another customer's invoice on a caller's behalf. The capability design instead has the authorizing layer mint an object-capability reference the moment the user's request is validated: an opaque, unforgeable handle that denotes exactly "read invoice #4192," and nothing else.
The orchestrator receives that one handle and can act only through it — there is no ambient store access to fall back on and no other invoice it can name. When it delegates the fetch, it passes that same capability onward to the document worker (or one attenuated to read-only), so the second deputy inherits precisely this task's reach and no more; the mail worker in turn is handed only the rendered bytes, never the store handle. At no point does any deputy in the chain hold authority beyond the single invoice the user actually asked for, so the confused-deputy move — inducing a deputy to act beyond the caller's intent — has nothing to grab: the reach of the whole delegation is bounded to what was explicitly passed down it.
How it works¶
- Fuse designation with authority. The reference names the object and confers the permitted operation on it in a single unforgeable token; there is no separately-namable resource behind it.
- Grant only by explicit passing. A subject gains a capability solely by being handed it (by the owner or another holder), never by asserting an identity or role that a lookup then honors.
- Make it unforgeable and unamplifiable. The capability cannot be guessed, counterfeited, or widened; a read handle cannot become a write handle.
- Confine the deputy to what it holds. The deputy acts using only the capabilities in its possession, so its reach is exactly the union of what it was given — nothing ambient underneath.
Tuning parameters¶
- Granularity — a capability per object-and-operation versus coarser bundles. Fine grain gives precise least authority but multiplies the references to manage and pass around.
- Delegability — whether a holder may pass a capability onward, and whether it can be attenuated (narrowed) when passed. Delegation enables flexible workflows but complicates tracking who ended up with what.
- Revocability — plain capabilities are hard to revoke; adding a revocation layer (an intermediary that can be cut) restores control at some indirection cost.
- Lifetime — persistent handles versus ephemeral, request-scoped ones. Ephemeral capabilities limit exposure; persistent ones ease long-lived access at higher standing risk.
- Amplification controls — whether combining capabilities can yield more authority than each alone. Forbidding amplification keeps reasoning about reach tractable.
When it helps, and when it misleads¶
Its strength is that it makes the confused-deputy problem structurally hard to have: a deputy that can only act through capabilities it was explicitly handed cannot be tricked into using authority it never received, because there is no ambient authority to induce it toward. It is the cleanest architectural answer the archetype offers — authority is bounded by possession, and least privilege becomes the default rather than a discipline.[n1]
Its costs are real and often why it isn't used. Retrofitting capabilities onto systems built around identities, paths, and ambient permissions is invasive; plain capabilities are awkward to revoke once passed, and reasoning about who holds what after delegation can get hard. The classic misuse is a leaky boundary that hands out a capability broader than the task needs — a read-and-write handle where read-only would do — quietly recreating an over-powered deputy inside the capability itself. The guarding discipline is to mint capabilities at the narrowest operation-and-object grain the task tolerates, add a revocation layer where access must be withdrawable, and forbid amplification so combined capabilities never exceed their parts.
How it implements the components¶
authority_carrying_capability— it is this component: an unforgeable reference that carries the permitted action and object, so holding it is being authorized.request_intent_scope— the capability fixes the exact operation on the exact object, so the action is scoped by the reference itself rather than inferred from a generic credential.ambient_authority_exclusion— there is no ambient authority to fall back on; a deputy can act only through capabilities explicitly handed to it, which structurally excludes standing power.
It carries no claim about who the originating principal is, nor freshness or audience context — originating_principal_claim and delegation_context_record are asserted by Signed Delegation Token; a capability confers authority by possession and designation, not by a statement of identity a recipient must then evaluate.
Related¶
- Instantiates: Principal-Bound Authority Mediation — supplies the strongest architectural form: authority bounded by possession of unforgeable references.
- Compare Capability Object: both fuse designation with authority in an unforgeable reference, but this page mediates a deputy's authority against confused-deputy confusion as that authority is delegated down a chain of actors, whereas Capability Object binds a unit's authority at definition time so it cannot inherit ambient power from the environment it later runs in.
- Sibling mechanisms: Signed Delegation Token · Scoped Service-Account Impersonation · Policy-Engine Subject Binding Check · On-Behalf-Of Authorization Flow · 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: The mechanism installs a capability-based authority structure in which an unforgeable object reference fuses designation and narrowly scoped permission.
Nearest alternative: Control, Automation & Runtime — Runtime checks honor the capability, but the defining form is the enduring authority and reference architecture.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Capability-based computer security developed unforgeable object references that simultaneously designate a resource and embody narrowly transferable authority.
Related originating lineages:
- Security Studies & Intelligence Analysis — Compartmentation and least-authority doctrine materially shape the threat and delegation rationale.
Review resolution: Both independent reviews agree on primary origin computer_science; reconciliation resolves alternate_origin_disagreement. Formative alternate lineages retained: security_intelligence. The broader reach of later applications is kept separate as domain_reach=specialized; origin_mode=single_lineage describes the historical relationship among lineages. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=false preserves the reviewers' boundary judgment.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The object-capability model (developed by Mark Miller and others) unifies designation and authority: a reference to an object is the permission to invoke it, authority spreads only by explicitly passing references, and there is no ambient authority to draw on. It is the canonical structural defense against the confused-deputy problem, which was first described precisely in capability terms. ↩