Possession of the token is the authorization
In a capability-based model, a capability is an unforgeable reference that both designates a specific resource and carries the authority to perform a specific operation on it. Holding the capability is what authorizes the action — there's no separate lookup against an identity's role or a central policy table at the moment of use. The check happened when the capability was issued, not when it's exercised.
This inverts the usual order of operations. Identity-and-policy models ask 'who are you, and what does policy allow you to do' on every request. Capability models ask only 'do you hold a valid capability for this exact operation' — the identity behind the request becomes almost incidental to the check.
What this buys, and what it costs
The appeal is precision: a capability can be scoped to exactly one resource and exactly one operation, and it can be handed to another party without handing over any broader authority — the recipient gets only what the capability itself grants, nothing implied by who they are. This maps cleanly onto delegation, which identity-based models tend to handle awkwardly.
The cost is operational: revoking a capability that's already been distributed is harder than flipping a role assignment in a central table, because the authority lives in the token itself, potentially copied to places the issuer no longer has visibility into. Capability systems need a deliberate answer for revocation and expiry, or long-lived capabilities become exactly the kind of forgotten standing access that time-bound access is meant to prevent.