# Threat model
## Security objective
Authorize an operation only when a capability signed by an explicitly trusted issuer permits the
exact host-derived audience, action, resource, and delegation depth, and the capability is current,
not revoked, not emergency-denied, and not previously consumed.
## Attacker capabilities
The attacker may:
- submit arbitrary, malformed, oversized, or replayed request bytes;
- generate keys and self-signed capabilities;
- tamper with any capability claim;
- omit constrained host-like fields from the request;
- know valid issuer, agent, delegator, action, and resource identifiers;
- observe or steal a bearer capability unless transport and storage controls prevent it;
- trigger dependency failures or race concurrent requests.
## Controls
- Strict decoding rejects unknown fields and oversized envelopes.
- Trusted issuer keys never come from request material.
- Ed25519 covers all capability claims.
- Host-only `OperationContext` prevents the bearer from selecting the operation being checked.
- Exact audience/action/resource/depth binding fails closed for configured constraints.
- Lifetime limits bound credential exposure.
- Revocation and emergency deny provide mutable containment.
- Atomic nonce consumption admits at most one successful use per issuer/nonce.
- Backend errors become denials.
- Audit events distinguish verified claims from untrusted diagnostic fields.
## Assumptions
- Issuer private keys and resource-server verification configuration are protected.
- The issuer is authorized to assert `agent_id`, `delegator_id`, and capability scope.
- The host clock and `OperationContext` are trustworthy.
- The trust-state implementation provides the documented consistency and durability.
- The host executes only the operation it represented during evaluation.
## Explicit non-goals and residual risks
- Tokens are bearer credentials; there is no proof of possession or channel binding.
- `delegator_id` is an issuer assertion, not a user signature or evidence of current user presence.
- Delegation depth is a trusted host number, not a cryptographically verified multi-hop chain.
- The crate does not authenticate OIDC/SPIFFE identities or discover issuer keys.
- Compromise or malicious behavior by a configured issuer is outside the verifier's protection.
- Revocation races after the state check and before host execution are not transactionally closed.
- Authorization vocabularies and resource identifiers are application-defined; inconsistent mapping
can create authorization gaps outside the crate.
- Availability is intentionally reduced when required security dependencies fail.