---
title: "The Question Authorization Never Answered"
date: "2026-07-11T15:00:00-07:00"
lastmod: "2026-07-11T15:00:00-07:00"
description: "Authorization standardized human and workload identity, delegation, asynchronous resource sharing, and per-request decisions. Unattended work exposes what it still lacks: durable shared state for the approved undertaking."
summary: "Authorization looks the way it does because each generation solved the question its era made urgent. Purpose was not absent: people, tickets, workflows, purchase orders, and policy attributes supplied it locally. UMA decoupled protected-resource access from synchronous resource-owner interaction, and workload identity made software actors attributable without making their credentials task-specific. What never became a standard cross-boundary object was the approved undertaking itself, with authority derived from it and a lifecycle independent of any credential. Usage control identified ongoing authorization two decades ago; unattended work now makes shared task state an operational requirement. This is the history that makes the Mission a legible next step rather than an idea from nowhere."
slug: "the-question-authorization-never-answered"
tags:
  - "Authorization"
  - "IAM"
  - "OAuth"
  - "Delegated Authority"
  - "Mission-Bound Authorization"
---


{{< tldr >}}

- **The claim.** Authorization systems can encode purpose and platforms can keep task state. What the interoperable stack does not standardize is a durable approved-task object that survives credentials, sessions, actors, and authorization domains.
- **The history.** Authentication, sessions, RBAC, OAuth, UMA, workload identity, and fine-grained policy each solved a different scaling problem. None standardizes a cross-system undertaking as the continuing root of authority.
- **Why OAuth stopped.** OAuth standardized limited API authority. UMA added asynchronous, policy-governed resource sharing, but not a general lifecycle for the undertaking behind access across systems.
- **The prior art.** UMA removed the synchronously present resource owner; usage control made ongoing decisions and mutable state first-class; ABAC and XACML can evaluate purpose when another system supplies it.
- **The forcing function.** Unattended work moves the person off the execution path. Once work spans time, actors, and domains, private context no longer reaches every boundary included in the authorization claim.
- **The proposed answer.** A [Mission](/mission-handbook/) records the approved undertaking, derives authority from it, and supplies current state to the boundaries within a deployment's declared enforcement scope.

**Where this sits.** A companion to the
[architecture chapter](/series/designing-mission-bound-authorization/):
the history behind the missing shared object.

**Reading path.** About eleven minutes, start to finish.

{{< /tldr >}}

Ask why the authorization stack looks the way it does and the useful
answer is that no one designed it as a whole. It accumulated one
problem at a time. Each generation solved the question its era made
urgent, then relied on people, applications, and organizational process
to supply the rest.

That is not a criticism. It is how infrastructure evolves. It also
explains the gap that unattended work exposes: not the total absence of
purpose, but the absence of a standard, durable object that tells every
relevant boundary why authority exists and whether the approved work is
still active.

This is a model history, not a literal timeline. The generations
overlap; modern systems use all of them; and each can be extended beyond
the job described here. The point is to identify the scaling problem
that made each abstraction succeed, and the responsibility it did not
need to own.

# Every generation answered its era's question

**Passwords answered who may enter.** Shared systems needed to
distinguish users, and password authentication helped bind an
interaction to a principal. The credential did not describe an
undertaking. It did not need to: the user and the application supplied
the immediate context.

**Sessions answered continuity.** The web split one interaction across
many stateless requests, so sessions carried authenticated context from
one request to the next. A session says that these requests belong to
the same authenticated interaction. It does not prove that the person
is still attentive or explain what the interaction is trying to
accomplish.

**RBAC answered administration.** Enterprises could not manage
permissions one user at a time, so roles associated permissions with
organizational responsibilities. NIST's early RBAC work described the
administrative advantage directly: users receive permissions through
roles and can change assignments without rewriting the underlying
access structure ([Ferraiolo, Cugini, and Kuhn, 1995](https://www.nist.gov/publications/role-based-access-control-rbac-features-and-motivations)).
A role is therefore usually sized to a responsibility or job function,
not one bounded undertaking.

**OAuth answered limited API authority.** Applications needed a way to
access protected resources without collecting every user's password.
[OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749.html) standardized how
a client obtains and presents authorization, with access tokens
representing particular scopes and durations. It also included
client-only authority through the client credentials grant. OAuth's
core question is not simply "who delegated?" It is broader: what
authorization may this client present to this resource server?

**UMA answered asynchronous resource sharing.** [User-Managed Access
(UMA) 2.0](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html)
extended OAuth so a requesting party's client could use a permission
ticket to seek a requesting party token (RPT) for protected-resource
access asynchronously from the resource owner's authorization. The
authorization server evaluates
resource-owner policy conditions and requesting-party claims, and can
manage access grants over time. UMA therefore removed the assumption
that the resource owner must be present when access is requested.

That makes UMA important prior art, not a near miss to dismiss. Its
governed object is a requested or granted set of permissions to
protected resources. Policy condition setting is deployment-defined,
and the specification does not make a multi-step undertaking the common
root for authority derivation, delegation where supported, execution
state, and evidence across all systems participating in the work. A
deployment can add those semantics around UMA; the added task lifecycle
is the Mission-shaped part.

**Workload identity answered which software is acting.** Cloud and
container platforms could not safely identify workloads with shared,
manually provisioned secrets. Workload identity systems bind a runtime
process to a verifiable software identity and issue credentials without
requiring the workload to manage a long-lived secret. [SPIFFE's Workload
API](https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/),
for example, supplies X.509 or JWT identity documents to an identified
workload, while SPIRE can select the identity from attested process and
platform attributes.

That is a major step for attribution and credential hygiene. It still
answers *which workload*, not *which approved undertaking*. One workload
identity may execute thousands of tasks, and one task may fan out across
many workload identities. The active IETF
[WIMSE working group](https://datatracker.ietf.org/wg/wimse/about/) is
addressing how workload identity technologies compose across multiple
systems; task approval and lifecycle remain a separate authorization
concern.

**Fine-grained authorization answered the request.** Scopes and roles
were too coarse for many estates, so ABAC, ReBAC, policy engines, and
externalized decision services made the request itself the decision
unit. [NIST's ABAC definition](https://csrc.nist.gov/pubs/sp/800/162/upd2/final)
allows policy to evaluate subject, object, operation, and environment
attributes. A policy decision point can answer whether this request is
permitted with great precision, but it can evaluate only the context it
receives. It does not inherently own the approval, lifecycle, or
cross-domain distribution of an undertaking.

Lay the abstractions out and the remaining responsibility becomes
visible:

| Generation | The question it answered | What another layer still supplies |
| --- | --- | --- |
| Credentials | Who may enter or act? | The work being attempted |
| Sessions | Which requests share authenticated context? | Whether the undertaking remains approved |
| RBAC | What may someone in this organizational role do? | The bounds of today's task |
| OAuth | What limited authority may this client present? | The lifecycle of the work behind grants and tokens |
| UMA | May this requesting party access this protected resource under the owner's policy? | The lifecycle of the undertaking behind that access |
| Workload identity | Which software workload is acting? | Which approved task this workload is performing |
| Fine-grained policy | Is this request permitted under current inputs? | Who produces and maintains approved-task state |

The claim is not that these layers cannot carry purpose. XACML's
privacy profile, for example, defines an explicit
[`action:purpose`](https://docs.oasis-open.org/xacml/3.0/xacml-3.0-privacy-v1-spec-cd-1-en.html)
attribute. ABAC can evaluate a purpose, ticket, or task identifier as an
environment attribute. The unresolved architectural question is who
creates that state, binds approval and authority to it, keeps it current,
and makes it available across every boundary included in the claim.

# Why OAuth stopped where it did

It is tempting to read OAuth's silence about a generic task lifecycle as
an oversight. It is better understood as a protocol boundary.

OAuth standardized authorization grants, token issuance, scopes,
durations, and resource-server access. It did not try to standardize the
semantics of every workflow an API might serve. Later work expanded the
model in important directions. UMA made authorization asynchronous with
respect to the resource owner and policy-driven across protected
resources. [Rich
Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html),
for example, can represent a specific payment amount, creditor, and set
of actions. But each API defines the meaning of those details, and RFC
9396 explicitly leaves their combination and comparison to the API and
authorization server. Rich authority is not automatically a durable,
shared task lifecycle.

That separation was productive. A purchase order, case record, change
ticket, workflow run, or deployment plan could hold purpose inside the
system that owned the work. In interactive flows, a person also carried
context between systems and stopped taking actions when circumstances
changed. OAuth did not need to become a workflow protocol to succeed.

The limitation appears when work crosses the walls that held its
context. A private task table can govern one platform well. It cannot
govern a resource server, sub-agent, credential broker, or partner
domain that never receives its state. The missing layer is therefore
not "purpose" in the abstract. It is interoperable, approval-backed task
state at the boundaries that rely on it.

# The theory arrived early

The idea of continuing authorization is not new. In 2004, Park and
Sandhu's [UCONABC usage-control
model](https://dl.acm.org/doi/10.1145/984334.984339) generalized access
control to include authorizations, obligations, conditions, ongoing
decisions, and mutable attributes. UCON recognized that authorization
need not be a one-time gate: relevant state can change during use, and a
decision may need to change with it.

That prior art matters for two reasons. First, ongoing evaluation and
mutable authorization state should not be presented as inventions of
agent security. Second, continuing decisions alone do not identify the
governed undertaking. A policy engine can repeatedly evaluate current
state only after some system defines the state, owns its transitions,
and makes it trustworthy to the enforcement point.

Mainstream authorization deployments had practical substitutes:
application workflow, tickets, sessions, short-lived credentials, and
human operators. Continuous checks also impose state-distribution,
availability, latency, and ownership costs. Unattended, cross-system
work changes that trade. It makes stale task state a recurring runtime
problem instead of an occasional integration concern.

# The experiment that breaks the composition

Consider an illustrative month-long task. Alice tells an agent to handle
the company's taxes. The agent evaluates filing software, engages a
bookkeeping sub-agent, requests documents from a payroll provider, files
an extension, waits for a state response, resumes three weeks later, and
appeals a rejected form.

Each component can be locally correct. Each provider issues a valid
grant. Every resumed session authenticates successfully. Each API
accepts only its own documented scopes or authorization details. The
bookkeeping sub-agent has an attested workload identity and rotated
credentials, and every policy decision is defensible from the inputs it
received.

Now ask about the undertaking as a whole. Which approvals authorize the
sub-agent to contact the accountant? Which grants belong to this tax
engagement rather than another one? Which authority should survive the
extension and which should discharge after filing? If Alice's business
is acquired and the engagement must stop, which active sessions,
tokens, queued steps, and derived grants are part of the stop?

An orchestration platform may know the answer in a private workflow
record. An IGA or PAM system may hold the approval. An audit system may
reconstruct much of it afterward. The problem is that no individual
credential, session, role, token, or policy decision necessarily carries
the whole relationship, and a remote enforcement point cannot consult
state it was never given.

Nothing in the underlying stack has malfunctioned. The composition is
missing an owner for shared undertaking state. The human used to bridge
many of those gaps through attention and judgment. Unattended work moves
that human off the execution path, while the work continues across
hours, actors, and domains.

# The missing shared answer

| Layer | The question it answers |
| --- | --- |
| Human identity | Which person is acting? |
| OAuth | What authority may this client present? |
| UMA | May this requesting party access this protected resource under the owner's policy? |
| Workload identity | Which software workload is acting? |
| Fine-grained policy | Is this action permitted under current inputs? |
| **Mission** | **What approved work governs the authority, and is it still active?** |

The [Mission](/mission-handbook/) is this handbook's proposed answer: a
durable, approved, integrity-anchored record of an undertaking and its
Authority Set. Credentials project authority from it. Consequential
actions are checked against its current state within a declared
enforcement scope. Delegation, where supported, cannot exceed the
approved Authority Set. A non-active Mission stops new derivation and
reliance within the deployment's published freshness bound; effects that
already completed still require cancellation, compensation, or review.

The [handbook](/mission-handbook/) develops that object and its
[five laws](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority):
the governing record is independent of credential lifetime; actions
remain attributable; derived authority only narrows; non-active state
stops reliance within scope and freshness bounds; and consequential
actions are checked against the approved Authority Set and current
state. Those are deployment obligations, not properties that follow
from adding a claim to a token.

This history also explains why the argument is broader than AI. CI
pipelines deploy after a merge, scheduled jobs move money at midnight,
and infrastructure controllers reconcile systems while teams sleep. Each
is unattended work whose purpose often lives in a repository, ticket,
or platform-local record while its credentials are sized for an
integration.

Agents intensify the problem because their plans change, their work fans
out, and untrusted content can steer their choices. They did not create
the missing shared state. They make its absence harder to tolerate.

Identity now covers people, clients, and attested workloads, while
authorization can decide whether a particular request is permitted.
Unattended work creates a reason to standardize the next answer: what
approved undertaking governs this authority, and does it still?