---
title: "The Question Authorization Never Answered"
date: "2026-07-22T08:40:00-07:00"
lastmod: "2026-07-22T08:40:00-07:00"
description: "Authorization standardized human and workload identity, delegation, asynchronous resource sharing, and per-request decisions, and every generation deferred the same question because a person or a process carried the answer. Unattended work removes the carrier and exposes what the stack 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, and deferred one question that someone else was always carrying: what approved work is this, and is it still on? Purpose was not absent. A second stack of tickets, purchase orders, workflows, and approval systems held it locally, and people carried it between systems. 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 removes the human carrier and 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, federation, OAuth, UMA, workload identity, and fine-grained policy each solved a different scaling problem, and each deferred the undertaking because someone else was carrying it: the person, the application, the ticket.
- **The two stacks.** The authorization stack answered "may this request proceed." The work stack, tickets, purchase orders, and approvals, held what was approved. They never merged, and human process was the join.
- **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 removes the carrier. Once work spans time, actors, and domains, no person is on the execution path to hold the why, and platform-private context never reaches the boundaries that must decide.
- **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.** ~12 minutes, start to finish.

{{< /tldr >}}

Stand at any enforcement boundary and ask the question in this
essay's title. A resource server holds a valid token. A policy engine
holds a permitted request. A session store holds an authenticated
continuation. Now ask what work this is, who approved it, and whether
it is still on. Every layer answers a question adjacent to that one,
and none of them answers it.

Ask why, and the useful answer is that no one designed the
authorization stack as a whole. It accumulated one problem at a time.
Each generation solved the question its era made urgent, and deferred
the question above, because someone else was always carrying the
answer: the person at the keyboard, the application's workflow table,
the ticket in the queue. That is not a criticism. It is how
infrastructure evolves, and this is a model history rather than a
literal timeline, since the generations overlap and modern systems
run all of them at once. The point is to name the scaling problem
that made each abstraction succeed, the carrier that let it defer the
undertaking, and the moment the deferral stopped working.

# 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 person at the terminal was the carrier, holding the purpose in their head and stopping when the work was done.

**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. It does not need to: the person is presumed present, and presence is the carrier.

**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. The undertaking had its own carrier: the
job itself, with a manager, a process, and a paper trail deciding what
the role-holder should actually be doing today.

**Federation answered trust across organizations.** Enterprises needed
one login to reach many providers, so SAML and later OpenID Connect
standardized the assertion: a signed, minutes-lived statement of who
authenticated, with what attributes, at what strength. A whole
generation of trust infrastructure, and the undertaking never appears
in it. It did not need to: the assertion opens a session on the far
side, and the person inside that session carries the why across the
boundary in their own head.

**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?
OAuth is also the one generation where the approval visibly happened:
a human saw a consent screen and said yes. Then the protocol kept the
authority and discarded the event. The scopes survive on the token,
[what was shown and agreed to](/notes/you-approve-what-you-were-shown/)
does not, and the person who consented becomes the carrier of what
they meant by it.

**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, and 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. And here the carrier begins to thin, because a workload has
no head to hold the purpose in.

**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. It evaluates what it is handed, and something else must carry the undertaking to the boundary.

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 |
| Federation | Who authenticated, across organizational boundaries? | The undertaking behind the session it opens |
| 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.

# The second stack

The why was never missing from the enterprise. It was in the other
stack.

Alongside the authorization stack, every organization runs a work
stack: purchase orders, change tickets, case records, workflow runs,
access requests and their approvals. That stack has always held
exactly what the authorization stack lacks: what was asked for, who
approved it, what it covers, and when it ends. A change ticket has a
scope and a window. A purchase order has an amount and a counterparty.
An access request has an approver and a justification.

The two stacks never merged. The work stack's records are not
enforceable objects: nothing at a resource server consults the ticket
before honoring the token that was provisioned because of it. The
authorization stack's artifacts are enforceable but carry no
undertaking: the token outlives the change window it was granted for.
The join between them was human process. Someone read the ticket,
provisioned the grant, and was supposed to remember to remove it, and
every access recertification campaign since is the cost of that join.

Seen from this history, the [Mission](/mission-handbook/) is not a new
kind of object so much as a merger the two stacks have owed each other
for decades: the work stack's record given the authorization stack's
enforceability, approval-backed state that boundaries consult rather
than paperwork that boundaries trust someone else to have checked.

# 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: the work stack held the purpose, the
person carried it between systems, and 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. What has no standard form 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, and for twenty years the workaround was
cheaper, because a human carrier costs nothing at the protocol layer.
Unattended, cross-system work breaks the workaround. It makes stale
task state a recurring runtime problem instead of an occasional
integration concern, and it removes the person who used to notice.

# The experiment that breaks the composition

Run the composition against one month-long undertaking. 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. Every layer
answered its own question correctly. What the composition is missing
is the one participant whose job was never written down: the person
who held the whole engagement in their head, noticed when
circumstances changed, and stopped. Unattended work moves that person
off the execution path while the work continues across hours, actors,
and domains. The carrier is gone, and no layer was ever asked to
replace them.

# 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):
Durability (the governing record is independent of credential lifetime), Attribution (actions remain attributable), Narrowing (derived authority only narrows), Termination (non-active state stops reliance within scope and freshness bounds), and Containment (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, and
authorization can decide whether a particular request is permitted.
The question in this essay's title was never unanswerable. It was
deferrable: someone was always there to carry the answer, so no
generation had to make it a standard. Every generation answered the
question its era made unavoidable. This one is ours, because it just
stopped being deferrable.