# Pattern: Delegated Authorization

Status: reviewed
Readiness target: RL3 production
Primary owners: flex-auth, NetKingdom

## Problem

Identity providers and application code should not become the scattered
home for every tenant, resource, and object-level authorization rule.

## Context

Use this pattern for protected systems that need consistent decisions
for tenant-scoped resources, privileged operations, object storage,
agent access, and application APIs.

## Forces

- Applications need local enforcement, but policy needs central shape.
- Tenant, resource, action, assurance, and context must travel together.
- Some decisions can be delegated to PDP runtimes such as Topaz.
- Deny reasons and obligations need to be auditable.

## Solution

Use flex-auth as the canonical authorization boundary. Callers submit a
standard decision request; flex-auth evaluates directly or delegates to
Topaz; applications enforce the returned allow/deny, obligations, and
audit metadata at the boundary.

## Implementation Sketch

1. Register protected systems and resource/action vocabulary.
2. Define the decision envelope and CARING descriptors.
3. Add policy packages with tenant/platform separation.
4. Delegate to Topaz where ReBAC or policy runtime support is useful.
5. Return stable allow/deny, reason, obligation, and audit fields.
6. Require applications to enforce decisions before resource access.

## Failure Modes

| Failure | Mitigation |
| --- | --- |
| App ignores deny obligations | add conformance tests at enforcement points |
| Policies mix platform and tenant authority | separate policy packages and review paths |
| Decision context omits tenant | fail closed |
| PDP outage becomes implicit allow | fail closed except documented emergency flows |

## Related Capabilities

- Authorization and access control.
- Tenant isolation.
- Application and API security.
- Observability, detection, and audit.

## Maturity

Reviewed. This is a core NetKingdom boundary and should become
canonical once flex-auth conformance fixtures are stable.

## Verification

- Decision envelopes include actor, tenant, resource, action, context,
  obligations, reason, and audit id.
- Enforcement points deny when flex-auth denies or is unavailable.
- Topaz delegation is visible in decision records.
- Tenant and platform policy packages are separated.

## Research Basis

Seeded by the policy decision point/enforcement point pattern, tenant
scoped authorization, API authorization, and CARING modeling notes.

## References

- NetKingdom platform identity/security architecture.
- Initial exploration: Authorization and access control.