Network Working Group K. McGuinness
Internet-Draft Independent
Intended status: Informational 22 August 2026
Expires: 23 February 2027
An Architecture for Mission-Bound Authorization
draft-mcguinness-mission-architecture-latest
Abstract
A Mission is a durable, approval-backed governance object for
authorization: the approved task, with a lifecycle, that authority is
derived for, bound to, and gated on. It is not a new way to express
authority. Read as one system, the Mission model defines a
delegated-authority layer: authentication says who is acting, and
entitlement governance says what a principal may hold; this layer
governs the approved task itself. It exists because the authority an
Approver consents to is a capability envelope, not a task script, and
the gap between that envelope and what a run actually does is where
agent risk lives; the family's mechanisms exist to narrow that gap.
This document is the structural view: the object and its invariants,
a Mission's life end to end, the roles and substrate, the verb spine
the profiles form, the deployment patterns, the assurance levels a
deployment claims, and the requirements the family answers. It is
Informational: it defines no protocol, object, or requirement, and
every mechanism it names is defined by the profile it points to.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://mcguinness.github.io/mission-bound-authorization/draft-
mcguinness-mission-architecture.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-
mcguinness-mission-architecture/.
Source for this draft and an issue tracker can be found at
https://github.com/mcguinness/mission-bound-authorization.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Map of This Document
2. Status: An Informational Architecture
3. Conventions and Terminology
4. The Mission
4.1. The Capability Envelope
4.2. A Mission's Life
5. Non-Goals
6. The Mission Verbs
6.1. Propose
6.2. Approve and Record
6.3. Govern
6.4. Enforce Each Action
6.5. Run and Wind Down
6.6. Delegate
6.7. Project
6.8. Continue
6.9. Prove
6.10. Analyze
7. The Reference Architecture
7.1. The Five Packages
8. Mission Invariants
8.1. The Ontology Contract
9. Mission Roles and Components
9.1. The Actor Chain
9.2. Three Objects, Three Lifecycles
9.3. Swarm Execution: Multiplication, Not Delegation
10. The Mission Substrate
10.1. The Primitives, at a Glance
10.2. Token Classes
10.3. The Mission-Bound Credential
10.4. Approval Fidelity
10.5. The Validity Model
10.6. The Binding Checklist
10.7. Error Surfaces
11. The Authority Derivation Boundary
12. Mission Deployment Patterns
12.1. Binding Security Architectures
12.2. Entry Ramps by Estate
12.3. Comparison to a Conventional Stack
12.4. A Worked Composition
13. Mission Assurance Levels
13.1. Composed Kill-Switch Reality
13.2. Assurance Claims
13.3. Mission Binding Properties
14. The Mission Deployment Profile
15. Prevention, Detection, and Residue
15.1. The Containment Matrix
16. Mission Requirements
16.1. Context and Intent
16.2. Consent and Approval
16.3. Lifecycle
16.4. Delegated, Projected, and Enforced Execution
17. Mission Document Map
18. Security Considerations
19. Privacy Considerations
20. IANA Considerations
21. Informative References
Acknowledgments
Author's Address
1. Introduction
A Mission is a durable governance object created by an explicit
approval event: the approved task, with a lifecycle. In the
authority-bearing bindings, authority for the task is derived for the
Mission, bound to it, and gated on its state. In AAuth, the Mission
Context instead governs resource decisions at the PS without becoming
their authority language. The Mission is not a new way to express
authority: Rich Authorization Requests [RFC9396] and kindred
mechanisms express authority, and the Mission is the approved task
that authority serves.
The object fills a gap current practice pays for daily: an estate
that cannot size authority to a task compensates with read-only
scoping, a human executing every write, or permanently fenced pilots,
and the Mission is the representation those controls substitute for.
The model is deliberately decomposed: the OAuth binding (the
"issuance profile" to its OAuth companions,
[I-D.draft-mcguinness-oauth-mission]) defines the object and its
OAuth 2.0 [RFC6749] realization, a standalone binding hosts the same
object without changing an existing Authorization Server
([I-D.draft-mcguinness-mission-authority-server]), an AAuth binding
maps the shared approval, reference, lifecycle-gate, and log
capabilities onto that protocol's native Mission Context without
importing the OAuth Authority Set
([I-D.draft-mcguinness-mission-aauth]), and optional companions layer
approval, lifecycle, enforcement, runtime, delegation, and proof
capabilities on top. The decomposition keeps each interface small
but spreads the structure across many documents and several bindings;
this document is the single structural view.
The bindings are peers of one another. OAuth is the family's first-
authored binding, and OAuth 2.0 is the substrate with the most
deployed infrastructure; that is a deployment fact, not a maturity
ranking, and no production Mission deployment is known today on any
binding. Adopting Missions on OAuth requires the changes the OAuth
binding defines. Peer standing implies neither identical
capabilities nor identical adoption cost: AAuth, natively contextual,
adds no new wire members, and each binding's Mission Substrate
Statement declares what it supplies.
Read as one system, the family defines a *delegated-authority layer*
with OAuth 2.0, the standalone Mission Authority Server, and (as an
experimental sketch) UMA 2.0 as authority-bearing bindings. AAuth
composes at the shared Mission Context layer: approval, stable
reference, lifecycle gating where the PS is on path, and governance
history (Section 4).
It defines no protocol, no object, and no requirement. It is a map,
not the territory: every mechanism named points at the profile that
normatively defines it, and where this document and a profile appear
to differ, the profile governs.
1.1. Map of This Document
Part order follows a reader's needs: the model first (the Mission and
its life, Section 4; what the family does not do, Section 5), then
the verb spine that organizes every mechanism (Section 6), the
reference shapes deployments take (Section 7), the semantic ground
rules (Section 8), the components and identity model (Section 9), the
binding-neutral substrate summary (Section 10) with the derivation
boundary behind it (Section 11), and the deployment layer: patterns
and entry ramps (Section 12), assurance levels and binding properties
(Section 13), the Deployment Profile (Section 14), and the
prevention-detection and containment matrices (Section 15). The
requirements the family answers are Section 16; Section 17 locates
every document; DRAFTS.md in the repository is the full catalog.
2. Status: An Informational Architecture
This document is Informational. It establishes no conformance class
and defines no new mechanism, claim, or wire format.
Its boundary with the Mission Security Model
([I-D.draft-mcguinness-mission-security-model]) is deliberate: this
document describes components, interfaces, and data flows; the
security model describes the trusted base and how each component's
compromise degrades the guarantees. Each profile's own Security
Considerations remain normative over both.
3. Conventions and Terminology
Where this document uses words like "must" or "should," they carry
their ordinary English meaning and describe what a referenced profile
establishes, not a requirement this document places. Mission-model
terms are used as the OAuth binding defines them
([I-D.draft-mcguinness-oauth-mission]), the family's first-authored
realization; the substrate contract
([I-D.draft-mcguinness-mission-substrate]) carries the binding-
neutral kernel forms. Policy Enforcement Point (PEP), Policy
Decision Point (PDP), and consequential action are the runtime
profile's ([I-D.draft-mcguinness-mission-runtime]); Mission Authority
Server (MAS) is defined by
[I-D.draft-mcguinness-mission-authority-server]; the AAuth binding is
defined by [I-D.draft-mcguinness-mission-aauth].
4. The Mission
OAuth 2.0 issues access tokens for individual resource requests; it
has no durable, approved artifact for the larger task a client
pursues on a user's behalf.
That matters for AI agents: given a mission (book the trip, reconcile
the ledger), an agent takes many actions across many resources over a
long time, spawning sub-agents and surviving restarts, and
independently issued tokens cannot express the approved task, its
boundary, or its end (the OAuth binding's Introduction).
The family separates the task from the authority, and the
authorization flow separates four objects: the Intent (proposed work,
inert until approved), the Mission (the approved, governed work), the
Authority derived for it, and each Action that uses it, with
lifecycle cutting through the last three. The Mission is the
approved task, with a lifecycle. In the OAuth model, the Authority
Set is the concrete authority (resources, actions, constraints)
derived for it. A Mission is not another authorization_details type:
it is the durable, approval-backed object an Authority Set is derived
for and gated by (the OAuth binding's Why a New Object section).
A client proposes a Mission Intent, and MAY propose concrete
authority alongside it; the Mission Issuer derives an Authority Set;
an approval event commits them and creates the Mission.
In the OAuth binding, the commitment is the integrity anchors:
intent_hash over the approved Mission Intent, authority_hash over the
consented Authority Set, and, where the client submitted an authority
proposal, proposal_hash over the submitted authorization_details
array, each computed over a domain-separated, issuer-bound envelope
with fixed canonicalization, so an auditor can reproduce each digest
from the record alone (the OAuth binding's Mission Approval,
Integrity Anchors, and Canonicalization Rules sections). The record
is immutable except for its state (the Mission Record section).
The Mission lifecycle states are active, revoked, and expired, and
only active permits issuance or continued reliance. A non-active
state stops new derivation at once; authority already issued ends at
the earliest of delivered revocation, a runtime or state-aware re-
check, or the credential's own expiry (Section 10.5).
Companions add states (suspended, completed, superseded, cascaded),
and one rule keeps that safe without a registry: a consumer treats
every state other than the exact value active, including one it does
not recognize, as non-active, so an unrecognized state fails safe
(the OAuth binding's Mission Lifecycle and Gating section).
AAuth realizes the separation differently. Its exact-byte s256
commits the private approved mission blob, and {approver, s256} is
the stable reference. The PS applies contextual governance using
that blob and the ordered mission log; scopes, resource tokens,
Resource and Access Server policy, and optionally R3 carry
deterministic resource authorization. AAuth does not add the OAuth
Authority Set or its two anchors, and its native lifecycle remains
exactly active or terminated.
The Mission model is the beginning of a distinct layer.
Authentication and token issuance answer who is acting and what a
single credential carries; governance of standing entitlements
answers what a principal should hold over time. Neither governs the
approved task a delegate performs on a principal's behalf: its
bounded authority, its lifecycle, the per-action check, and the
evidence that binds back to it.
That is the delegated-authority layer this family defines, composing
with the layers below rather than replacing them, and the Mission
Authority Server ([I-D.draft-mcguinness-mission-authority-server]) is
its binding-independent control plane across an estate, whichever
party issues a given token. The control-plane vocabulary is exact,
not loose:
* the issuer side holds desired state (the record, its authority,
its lifecycle and state version), reconciles it (gating, the
ceiling review, evidence reconciliation), and distributes bounded
authority (policy views, status, the management surface);
* tokens and the PEP/PDP boundary are the layer's data plane; and
* Status and Signals are the channel between the two.
The plane the layer governs is authority, never operations: how an
agent runs stays with the harness and the orchestrator.
4.1. The Capability Envelope
One tension organizes the whole family. A Mission commits its
authority and intent once, at approval, but an agent's work is open-
ended: the actions a task will take are not known when it is
approved. "Reconcile Q3 invoices" must authorize reading any invoice
and posting any adjustment under the cap, because the specific ones
cannot be enumerated in advance.
So the Authority Set an Approver consents to is a *capability
envelope, not a task specification*, and the gap between that
envelope and what a given run actually does is where agent risk
lives.
The family's mechanisms are levers that narrow that gap:
* constraint-bounding and the subset rule shrink the envelope at
issuance;
* runtime enforcement checks each action against it at the point of
use;
* action-bound approval re-consents the highest-consequence actions
with their concrete parameters;
* progressive authorization trades many increment approvals for one
bounded ceiling;
* metering caps cumulative consumption; and
* completion retires authority as the task finishes.
No single lever closes the gap; a deployment composes the ones its
risk warrants (Section 13), and the verbs of Section 6 organize the
levers by the question each answers.
What approval commits is broader than the structured Authority Set
alone: it also commits the rendered intent context (goal,
constraints, and, where it differs, the requested ceiling), the
effective expires_at, and the rendered controls bounds
([I-D.draft-mcguinness-oauth-mission]). Concrete request values,
current consumption, and action sequencing are decision-time facts,
evaluated later by runtime policy, metering, or action-bound
(transaction) approval; core does not require them to be re-rendered
to the original Approver, though action-bound approval may re-render
exactly that. The lifecycle control gates new derivation from the
envelope; a credential already materialized under it keeps running to
its own bound. The two halves compose but do not substitute: an
envelope real at approval time can still admit, at decision time, an
effect the Approver never saw rendered in that form.
The levers share one strategy: they convert semantic risk into
structural signals. A policy decision point is never asked to judge
whether content is harmful; provenance (the harness taint context),
composition (the quarantine pattern), egress enumeration and volume
bounds, separation of duty, and re-consent turn that question into
facts a decision can gate on. A content evaluator a deployment adds
composes as Resource policy at the decision point and only ever
narrows.
The stance beneath the levers is *survivable incorrectness*: the
agent is probabilistic, so the family never bets on the model being
right and builds so that wrong is survivable, on two arms.
The action arm is this envelope and its levers, wire-backed, with in-
flight work unwinding through recorded reversibility classes
([I-D.draft-mcguinness-mission-orchestration]). The input arm is
*least exposure*: everything the agent sees can steer it and
everything it holds can leak, so a Mission budgets disclosure as well
as authority, and mediated custody generalizes from credentials to
context.
The arms differ in maturity, and the difference is stated rather than
blurred: the exposure arm's enforceable edges are the harness taint
rule, egress mediation, and catalog filtering
([I-D.draft-mcguinness-mission-harness],
[I-D.draft-mcguinness-mission-runtime],
[I-D.draft-mcguinness-mission-authzen]), while its interior,
retrieval, memory, and context assembly scoped to the Mission, has no
interoperable form yet and is deployment discipline, declared in the
Deployment Profile (Section 14) rather than claimed.
The envelope meets its hardest case in the open world. The OAuth
model starts with authority client-proposed and enumerated at
approval; an agent that discovers resources at encounter time breaks
that premise, and some authorization mechanisms invert it: the
resource declares its own operations and consequences. Who owns
meaning, and how it reaches derivation, consent, and enforcement, is
stated once as the ontology contract (Section 8.1).
Where the OAuth discovery profile consumes a self-declaration, the
declaration's digest is committed with the binding evidence: an
additional commitment beside the Mission's integrity anchors,
recording what the resource claimed to be at the moment authority
bound to it. The rest of the encounter, its routing through
drawdown, catalog binding, projection, or fresh approval, and its
identity pinning and floors, is the discovery companion's contract
([I-D.draft-mcguinness-mission-discovery]). AAuth can use R3 for
resource-owned deterministic semantics without placing that
declaration or such an additional commitment in the private mission
blob.
4.2. A Mission's Life
The structure is easiest to see by following one Mission end to end
under the OAuth binding: an operator gives an agent the task
"reconcile Q3 invoices."
1. *Propose.* The client shapes the request into a structured
Mission Intent, untrusted by construction, and submits it in a
Pushed Authorization Request [RFC9126], optionally proposing
concrete authority on the standard authorization_details
parameter alongside it ([I-D.draft-mcguinness-mission-shaping];
the OAuth binding).
2. *Approve and record.* The Authorization Server derives an
Authority Set (read invoices, post adjustments under a cap),
discloses it, and the Approver approves. The approval event
commits intent_hash, authority_hash, and, where a proposal was
submitted, proposal_hash, and creates the Mission, active with an
expiry; Consent Evidence commits what was shown
([I-D.draft-mcguinness-oauth-mission-consent-evidence]).
3. *Issue.* Tokens are derived under the subset rule, carry the
mission claim, and derivation and refresh are refused once the
Mission leaves active (the OAuth binding).
4. *Enforce.* Before each consequential action (posting an
adjustment), the PEP obtains a PDP permit bound to the action's
concrete parameters and to current Mission state
([I-D.draft-mcguinness-mission-runtime],
[I-D.draft-mcguinness-mission-authzen]).
5. *Delegate.* A sub-agent that verifies ledger entries receives a
child Mission with strictly narrower authority and lineage
([I-D.draft-mcguinness-oauth-mission-child-delegation]).
6. *Govern.* Consumers observe state through Status and Signals;
growth requires an approved successor
([I-D.draft-mcguinness-oauth-mission-expansion]), and entries
retire as their work completes
([I-D.draft-mcguinness-oauth-mission-status]).
7. *Stop.* Revocation or expiry turns every gate at once: issuance
refuses, the PDP denies, the harness pauses bound sessions and
queues, and the orchestrator unwinds in-flight work
([I-D.draft-mcguinness-mission-harness],
[I-D.draft-mcguinness-mission-orchestration]).
8. *Prove.* The record, anchors, evidence, and receipts let an
auditor reconstruct what was approved, shown, decided, and done,
and a Mandate carries the committed facts to parties outside the
deployment ([I-D.draft-mcguinness-mission-mandate],
[I-D.draft-mcguinness-mission-audit]).
The approval-to-permit path in sequence:
Approver Agent AS PEP/PDP RS
| | | | |
| | 1 Mission | | |
| | Intent (PAR) | | |
| |---------------->| | |
| 2 disclose and approve | | |
|<--------------------------->| | |
| | Mission active:| | |
| | intent_hash, | | |
| | authority_hash | | |
| | 3 Mission-bound | | |
| | token | | |
| |<----------------| | |
| | 4 action, token, parameters | |
| |------------------------------>| |
| | | 5 state and | |
| | | authority | |
| | |<----------->| |
| | | | 6 permit, |
| | | | evidence |
| | 7 permitted action executes |----------->|
Under the standalone binding the same life runs with ordinary tokens
and the Mission Join in place of step 3's claim carriage
(Section 12). Under the AAuth binding, the Person Server instead
governs the native Mission Context through propose, clarify, approve,
and the mission log; it does not emulate the AS's Authority Set,
integrity anchors, PDP permits, Child Missions, or portable evidence
(Section 4).
5. Non-Goals
The model's boundary is deliberate. The family does not define:
* *A new authority format, or a new grant protocol.* Rich
Authorization Requests [RFC9396] and kindred mechanisms already
fill the authority-expression role; the family leaves that to them
(Section 4). The same restraint holds against GNAP and the
capability-system lineage (macaroons, Biscuit, UCAN, object-
capability narrowing): this family composes with deployed grant
protocols and attenuation primitives rather than introducing a
competing one of its own; the OAuth binding states the comparison
([I-D.draft-mcguinness-oauth-mission]).
* *A policy language.* The PDP evaluates the Mission's Authority
Set, constraints, and state; how a deployment authors policy
beyond them is local ([I-D.draft-mcguinness-mission-runtime]).
* *Entitlement governance.* What standing access a principal should
hold over time belongs to existing governance layers; the
delegated-authority layer composes with them (Section 4).
* *Agent identity and deployment governance.* Who the agent is, its
concrete instance, and its approved behavioral version belong to
the deployment's agent IAM and change governance; the family
authenticates against and consumes those facts without defining
them (Section 9.2).
* *An agent framework.* The harness constrains the execution
environment's relationship to Mission state; it does not say how
an agent plans, reasons, or calls tools
([I-D.draft-mcguinness-mission-harness]).
* *Semantic derivation.* Whether a derived Authority Set is the
right reading of the task is committed and auditable, not
standardized (Section 11).
* *Agent trustworthiness.* The family bounds what a compromised or
injected agent can do; it does not make the agent trustworthy
([I-D.draft-mcguinness-mission-security-model]).
6. The Mission Verbs
The family organizes along a verb spine: each verb answers one
question, sits on one trust boundary, and is owned by named
documents; the levers of Section 4.1 sort onto this spine by the
question each answers.
propose OAuth Intent Shaping or AAuth native proposal
(client or agent side, untrusted)
|
approve Mission control point: the OAuth AS, Mission
and record Authority Server, or AAuth Person Server
contextual-governance binding
(+ Consent Evidence, Deferred Approval)
|
the Mission: durable approved context and
lifecycle; authority anchors where defined
|
govern Status (pull), Signals (push),
Expansion (widen), Completion (retire)
|
enforce Runtime contract -> AuthZEN binding:
each action a PDP permit before every consequential action
|
run and Harness (continuity is not authority),
wind down Orchestration (unwind in-flight work)
delegate Child Delegation, Offline Attenuation
project Cross-Domain Projection (a Mission honored
in another trust domain)
continue Mission Continuation (authorization continuity
over ICA, async delegation, and cross-domain
transports)
prove Consent Evidence, Mandate, Audit
analyze Security Model (the trusted base)
6.1. Propose
The question: how does a user's request become a candidate approved
task? In OAuth, the boundary is the client side and Intent Shaping
produces an untrusted Mission Intent
([I-D.draft-mcguinness-mission-shaping]), entering through Pushed
Authorization Requests [RFC9126] or the MAS submission endpoint. In
AAuth, the agent sends the native description and requested tools to
the Person Server's mission endpoint. The AAuth binding defines no
Mission Intent or dependency on the shaping profile.
6.2. Approve and Record
The question: how does a proposed task become an approved, committed
Mission? The boundary is the binding's control point; the approval
event is where trust is created. Owners: the five bindings
([I-D.draft-mcguinness-oauth-mission],
[I-D.draft-mcguinness-mission-authority-server],
[I-D.draft-mcguinness-mission-aauth],
[I-D.draft-mcguinness-mission-uma],
[I-D.draft-mcguinness-mission-gnap]), Consent Evidence
([I-D.draft-mcguinness-oauth-mission-consent-evidence]) committing
the disclosure shown to the Approver, and Deferred Approval
([I-D.draft-mcguinness-oauth-mission-approval]), the OAuth binding's
asynchronous path, with an experimental companion adding an in-review
narrowing negotiation; the standalone and AAuth bindings are natively
asynchronous. AAuth's baseline approval commits its exact mission
blob, not the family Consent Evidence object. Where the experimental
progressive authorization companion is used, the initial approval
also consents an authority ceiling for later staged widening
([I-D.draft-mcguinness-oauth-mission-progressive]).
Who holds the deciding side is a spectrum, not a species: the
approval event requires an accountable principal deciding against
committed inputs before any authority exists, and the proposer is
never the approver. A deterministic, versioned policy can approve at
machine speed within a ceiling a human consented to (the OAuth
binding's policy_drawdown and template authorization bases,
Section 8): policy approves the instance because a human approved the
policy or the template, with policy_version keeping that chain re-
checkable, while a model's generated judgment is never the sole
authority for granting or widening: a generated approver reading
attacker-influenced proposals is itself an injection surface. The
high-consequence classes stay on a fresh human decision, per the
progressive profile's prohibited set
([I-D.draft-mcguinness-oauth-mission-progressive]).
6.3. Govern
The question: how do consumers observe Mission state, and how does
authority grow or retire mid-task? The boundary: between the issuer
and every consumer relying on state. Owners: Status, the signed pull
surface with a lifecycle endpoint and per-entry completion discharge
([I-D.draft-mcguinness-oauth-mission-status]); Signals, the push
complement ([I-D.draft-mcguinness-oauth-mission-signals]); Expansion,
widening only via an approved successor
([I-D.draft-mcguinness-oauth-mission-expansion]); Containment, event-
triggered monotonic narrowing of a live Mission's effective authority
([I-D.draft-mcguinness-oauth-mission-containment]); Management, fleet
enumeration and bulk lifecycle for operators
([I-D.draft-mcguinness-oauth-mission-management]); and Discovery,
experimental, binding encountered resources within a pre-consented
ceiling ([I-D.draft-mcguinness-mission-discovery]). The AAuth
binding carries this verb natively: its management companion for
status, termination, and delegation-tree queries
([I-D.draft-mcguinness-mission-aauth-management]); the approved
lifetime bound is AAuth's own expires_at, profiled by the expiry
document ([I-D.draft-mcguinness-aauth-mission-expiry]).
6.4. Enforce Each Action
The question: is this specific action, with these parameters,
permitted under this Mission now? The boundary: the last
controllable point between agent and resource. Owners: the runtime
profile, the decision contract with parameter binding, custody, and
fail-closed behavior ([I-D.draft-mcguinness-mission-runtime]); its
AuthZEN binding, the concrete decision API
([I-D.draft-mcguinness-mission-authzen]); the runtime evidence
companion, the Decision Evidence, Execution Evidence, and Refusal
Record objects ([I-D.draft-mcguinness-mission-runtime-evidence]).
Its decision composes conjunctively with the structural plane above:
Effective Authority Set membership, every applicable cumulative-
consumption or stateful operational gate, and a required action-bound
approval are each independently necessary, and none grants, widens,
or restores another ([I-D.draft-mcguinness-mission-runtime],
Section "The Runtime Decision").
6.5. Run and Wind Down
The question: how does governed work start, persist, pause, and
unwind when Mission state changes? The boundary: the operator's
execution environment around the agent. Owners: the harness, binding
session continuity to Mission state
([I-D.draft-mcguinness-mission-harness]); Orchestration, unwinding
in-flight work through reversibility classes and recorded unwind
plans ([I-D.draft-mcguinness-mission-orchestration]).
6.6. Delegate
The question: how does authority reach a sub-agent without widening?
The boundary: between principals acting under one approval. Owners:
Child Delegation, child Missions with lineage, strict-subset
authority, and cascade revocation
([I-D.draft-mcguinness-oauth-mission-child-delegation]); Offline
Attenuation, narrower Mission-bound tokens minted off the issuer's
hot path ([I-D.draft-mcguinness-oauth-mission-attenuation]). Offline
attenuation requires the runtime enforcement layer: its kill switch
is the runtime state re-check. Both build on the actor chain of the
OAuth binding's Delegation Within a Mission section. The chooser:
the OAuth binding's token-exchange delegation for an execution hop
living and dying with the parent's lifecycle; a Child Mission when
the delegate needs its own lifecycle, approval, or audit identity;
attenuation, experimental, only where offline minting is the
constraint. AAuth delegates natively: a parent-mediated sub-agent
under parent_agent, distinct from the call chain of a service hop,
with no Authority Set machinery imported
([I-D.draft-mcguinness-mission-aauth]).
6.7. Project
The question: how is one Mission honored in another trust domain?
The boundary: a trust boundary the origin does not control, where the
verifier holds no session with the issuer. Owner: Cross-Domain
Projection, a single-hop grant that carries the Mission's identifier,
issuer, and authority hash into a partner domain unchanged, where a
Resource AS mints a local token bounded by the projected authority
([I-D.draft-mcguinness-oauth-mission-cross-domain]). Projection
preserves authority across the boundary rather than narrowing it to a
sub-actor, which is why it is a distinct verb from Delegate;
downstream revocation latency is the local token lifetime.
6.8. Continue
The question: how does a Mission's authorization continue, under the
same approval and constraints, when the acting identity must be re-
established at each hop or after the original credential is gone?
The boundary: the seam between authorization continuity, which the
Mission owns, and identity continuity, which a transport carries.
Owner: Mission Continuation
([I-D.draft-mcguinness-oauth-mission-continuation]), the
authorization-continuity profile, which keeps three easily conflated
things apart. Identity continuity, who is acting and how that
identity legitimately continues, rides a transport rather than this
profile: Identity Continuation
([I-D.draft-mcguinness-oauth-id-continuation-assertion]) for a short-
lived, sender-constrained hop within a domain; async delegation
([I-D.draft-zhu-oauth-async-delegation]) for a long-running,
disconnected task; and the cross-domain grant
([I-D.draft-mcguinness-oauth-mission-cross-domain]) across a trust
boundary. Authorization continuity, what work remains authorized
under which constraints on whose approval, is the Mission's: every
continued grant derives a subset of the Mission's Authority Set, is
state-gated at issuance, is bounded by the Mission's expiry, and ends
when the Mission goes terminal. Execution-time evidence records,
against the Mission, what was done at each continued hop. The load-
bearing invariant is that a continuation handle grants nothing: it
names an accepted hop, and every continued grant re-passes the
Mission's active gate, so continuity is never authority, the rule the
harness already applies to session continuity
([I-D.draft-mcguinness-mission-harness]). Continue is therefore
distinct from Delegate, which narrows authority to a sub-actor, and
it uses the Project verb's cross-domain grant as one transport rather
than replacing it.
6.9. Prove
The question: what can a party outside the deployment verify about
what was approved and done? The boundary: across trust domains and
time; the verifier holds no session with the issuer. Owners: Consent
Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); the
Mandate, a signed, portable statement that authorizes nothing
([I-D.draft-mcguinness-mission-mandate]); the Mission Receipt,
portable evidence of an action taken under a Mission
([I-D.draft-mcguinness-mission-runtime]); Audit Transparency, the
append-only evidence log ([I-D.draft-mcguinness-mission-audit]).
6.10. Analyze
The question: which components must be trusted, and what does each
one's compromise cost? The boundary: the whole system. Owner: the
Mission Security Model
([I-D.draft-mcguinness-mission-security-model]).
7. The Reference Architecture
The family is a menu, but a reader should meet it as a meal. Four
stacks, each containing the previous, are the shapes deployments
actually take, and the second is the reference:
*Protocol core*: the OAuth issuance binding alone, the realization
these stacks are expressed in (chosen for OAuth 2.0's deployed
infrastructure): the standardizable primitive (approved, anchored,
state-gated Missions), Mission-substrate conformance (Section 16),
no per-action control (Baseline Issuance, Section 13). The stacks
are this OAuth realization throughout; a peer binding realizes the
levels per its own document, and peer standing does not imply
identical rungs or capabilities.
*Reference security architecture*: core plus runtime enforcement,
its AuthZEN binding, and a freshness source (the Runtime-Enforced
level, Section 13). This is the architecture this document means
when it says a Mission is enforced, and the one an evaluation
should picture by default. It presumes an authority-bearing
binding; under AAuth the analogous per-action control is the
Person Server's contextual gate on PS-mediated paths
([I-D.draft-mcguinness-mission-aauth]).
*Recommended agent architecture*: the reference architecture plus
Consent Evidence and the harness (the Governed Agent level): what
a deployment running autonomous AI agents should build.
*High-assurance architecture*: the recommended architecture plus
mediated custody, no unmediated path, action-bound approval,
active freshness, and agent-isolated approval rendering (the High-
Assurance Agent level).
7.1. The Five Packages
Independent of how the drafts are cut for standardization, the system
decomposes into five architecture packages; the document map
(Section 17) names every draft, and each belongs to one package:
1. *Mission Control*: the object, approval (including deferred and
revision), lifecycle, status and signals, expansion, completion,
management.
2. *Authority Distribution*: the four issuer bindings, the issuance
grant, cross-domain projection, child delegation, offline
attenuation.
3. *Runtime Enforcement*: the runtime contract, the AuthZEN binding,
parameter binding, custody, metering.
4. *Agent Execution Governance*: the harness, orchestration,
shaping, discovery.
5. *Evidence and Accountability*: consent evidence, the Mandate,
audit transparency, and the decision and execution evidence the
runtime package produces.
A product architect deploys packages; a standards reviewer reads
drafts; the two views name the same system.
8. Mission Invariants
The following seven invariants define the family's portable-authority
model and are stated normatively by their home documents. They apply
to the OAuth binding and to companions and bindings that explicitly
adopt the corresponding Authority Set capabilities. A change that
would break one in those bindings is a change to that model, not to a
profile.
The AAuth binding adopts the context-level invariants: durable
approval, stable attribution, exact-byte integrity, an active-state
gate at the PS, and termination. It does not adopt the OAuth
Authority Set, the OAuth integrity anchors, or universal subset
derivation. AAuth resource authority is decided afresh in the
vocabulary and policy of each Resource or Access Server, with
contextual PS governance when the PS is on path.
*Authority serves an approved task*: No Mission-bound authority
exists except by derivation for a Mission, and a Mission is
created only when rooted in an approved authorization basis that
commits intent_hash and authority_hash (the OAuth binding).
Fields an agent can influence shape authority only through the
pre-approval derivation the Approver consents to; once the Mission
is approved they are inert and never derive, widen, or gate
authority.
*Only active permits*: Issuance, refresh, and reliance require the
exact state active; every other state, including an unrecognized
one, fails safe (the OAuth binding's Mission Lifecycle and Gating
section). In AAuth, only PS operations and the PS-asserted and
federated authorization paths are structurally gated; identity-
based and resource-managed decisions do not pass through the PS.
On the gated paths the gate covers requests whose resource token
carries the validated Mission Reference; a stripped reference
yields a missionless request, bounded by the binding's downgrade
rules ([I-D.draft-mcguinness-mission-aauth]).
*Authority only narrows*: Derived tokens, delegated child Missions,
attenuated tokens, and cross-domain projections carry subsets;
widening exists only as an approved successor: a fresh approval
([I-D.draft-mcguinness-oauth-mission-expansion]), or policy
drawdown within a ceiling a human pre-consented
([I-D.draft-mcguinness-oauth-mission-progressive]).
*Revocation is possession-independent*: A Mission ends by a state
change at its issuer, not by finding and destroying credentials;
outstanding credentials meet the issuance gate, the runtime re-
check, or their own expiry, whichever comes first (Section 10.5).
*Attribution is carried, never inferred*: Each role in the actor
chain travels in its own construct, and the evidence layer records
them together; no role is derived from another (Section 9.1).
This invariant scopes the actor chain. The credential-to-Mission
association is itself a carried fact only where a binding carries
the mission claim; under the standalone binding the PDP's join
establishes it by inference, bounded by that binding's join
assurance (Section 12).
*Enforcement fails closed; inert surfaces fail safe*: A PDP that
cannot establish state or authority within the published staleness
bound denies, and a consumer that cannot refresh state treats its
cache as unreliable rather than as permission
([I-D.draft-mcguinness-mission-runtime]).
*Anchors commit; they do not prove semantics*: The integrity anchors
prove what was approved and committed, not that the derivation was
the right reading of the task (Section 11). AAuth's corresponding
integrity property is the s256 commitment over exact mission-blob
bytes, not the OAuth integrity anchors.
Read against "approved" in the first invariant, the OAuth binding
fully defines one authorization basis, direct, a human's own
approval. It provides the extension point, an authorization-basis
type string, that companion profiles use to define others: template,
a dispatch drawing on a ceiling the human consented to once, and
policy_drawdown, a child instance a policy adjudicates within a bound
the parent's human already consented to. This is never an eighth
invariant: every value of the basis, defined by the OAuth binding or
by a companion, fixes the same accountable human as
consent_principal; they differ only in what activated this instance
and what root that activation traces to (the OAuth binding).
Read as shared capabilities rather than universal wire semantics, the
bindings carry durability, attribution, and termination. Narrowing
and containment require a structured-authority capability and are not
baseline AAuth Mission Context properties.
Read on the artifact plane, the same invariants forbid authority from
riding a work product an agent produces: no authority is acquired by
information propagation alone, and a work product crossing into a
Mission is input that the receiving Mission re-evaluates under its
own Authority Set. This is a reading of the invariants above, not an
eighth invariant; carrying that boundary through non-transitive
Mission-to-Mission handoff is the Mission Work Products companion's
role ([I-D.draft-mcguinness-oauth-mission-work-products]). The OAuth
binding states that rule in its "Authority Does Not Propagate With
Information" section ([I-D.draft-mcguinness-oauth-mission]); that
section, not this summary, is the normative text this passage tracks.
Read under composition, the invariants bound one Mission's own
Authority Set; they do not by themselves bound the aggregate surface
a delegation tree, a cross-domain hop, or a chain of child
generations reaches together. Delegation depth resets at each cross-
domain hop and at each child generation, and a child's own derivation
cap is independent of its parent's, so the authorized surface a body
of work can reach can exceed what any single approval appears to
bound. This is again a reading of the invariants above, not an
eighth invariant; disclosing the composed bound at the consent
surface is the cross-domain and child-delegation profiles' role
([I-D.draft-mcguinness-oauth-mission-cross-domain],
[I-D.draft-mcguinness-oauth-mission-child-delegation]), and bounding
aggregate consumption is the metering profile's
([I-D.draft-mcguinness-mission-metering]). The OAuth binding states
the same composition property in its "Composition and the Effective
Ceiling" section ([I-D.draft-mcguinness-oauth-mission]); that
section, not this summary, is the normative text this passage tracks.
8.1. The Ontology Contract
The derivation boundary (Section 11, later in this document) settles
who commits authority; this section settles who owns what an
operation means. The ownership statement is one sentence: the
resource owns the ontology, its operations, its constraint semantics,
and their consequences, while derivation, consent rendering, and
enforcement consume that meaning without owning it, and no layer
invents meaning it does not own. The consuming contract is equally
short: meaning binds at approval, is enforced at the point of use,
and any translation between the resource's vocabulary and another
party's is trusted, verified, or separately approved, never a place
where authority widens (Section 10.4). One boundary is shared by
agreement: the resource owns its operation semantics and
consequences, while the family owns the registered cross-resource
constraint vocabulary, which a resource explicitly advertises and
adopts before it binds ([I-D.draft-mcguinness-oauth-mission]).
Resource-owned meaning reaches the three consuming layers through
five mechanisms, each normative in its own home and composing as one
contract:
Common Constraints: The registered constraint vocabulary every
conforming party evaluates identically, with the
mission_constraints_supported protected-resource metadata member
advertising which constraints a resource enforces. Home: the
issuance profile ([I-D.draft-mcguinness-oauth-mission]).
Capability-source binding: Catalog-sourced capability definitions
(an MCP tool, an OpenAPI operation) content-digested at derivation
and refused on drift at decision time, so the meaning authority
bound to is the meaning enforced. Home: the capability-binding
companion ([I-D.draft-mcguinness-mission-capability-binding]).
Operation Profiles: The per-operation statement of normalization and
binding rules, carrying resource-declared operation semantics such
as idempotency, reversibility, and lease requirements into
parameter binding. Home: the runtime profile
([I-D.draft-mcguinness-mission-runtime]).
The encounter contract: What is submitted, adjudicated, and recorded
when an agent meets a resource the approval could not enumerate,
so meaning that arrives late still binds before use. Home: the
discovery companion ([I-D.draft-mcguinness-mission-discovery]).
Resource-Declared Semantics: The full inversion: the resource
publishes its operations, their human meaning, and their
consequences. Under the OAuth discovery composition, the
declaration can be content-addressed by r3_s256 as an additional
commitment beside the Mission's integrity anchors; the declared
operations become candidate vocabulary that derivation narrows
against. AAuth can instead use R3 as a resource-owned
deterministic authorization vocabulary while the private mission
blob remains contextual PS governance. R3 content addressing is
not a baseline AAuth mission anchor. Home: the discovery and R3
compositions, informative.
Behind the five mechanisms sits one direction axis, and the direction
is chosen per encounter, not fixed by binding. The family inherits
OAuth's client-proposed default: the client names the authority it
wants and the resource's meaning arrives through metadata, catalogs,
and profiles (Section 4.1). Resource-Declared Semantics is the
inversion, where the resource speaks first. Where a structured-
authority binding commits that meaning at approval, it is enforced at
use and translation never widens. Under the OAuth binding the
resource-declared direction runs entirely through seams the family
already has: the encounter contract routes the declaration
([I-D.draft-mcguinness-mission-discovery]), narrowing-mode derivation
consumes the declared operations as candidate vocabulary
([I-D.draft-mcguinness-oauth-mission]), consent composes the
resource-authored material, and the declaration's digest rides the
derived authority (the progressive companion's
resource_declaration_digest,
[I-D.draft-mcguinness-oauth-mission-progressive]). In AAuth, R3 can
describe deterministic resource authorization independently of
mission approval; the PS considers the resource request and mission
context without turning the R3 declaration into a Mission Authority
Set. Proposed RAR-type metadata
([I-D.draft-zehavi-oauth-rar-metadata]), a resource publishing the
authorization_details types and fields it understands, is the OAuth-
native descriptive surface the direction builds on.
Both directions close the same loop: the meaning source's digest
becomes part of the derived authority. A catalog-sourced capability
pins its source_digest; a resource declaration pins r3_s256; in each
case the Authority Set carries the version of the meaning it was
derived under, and the point of use compares against the meaning in
force. Meaning is not consulted at approval and assumed at
enforcement; it is committed at approval and re-verified at use.
The contract's failure mode is already normative in each home: a
consumer that cannot resolve an operation's meaning, a constraint it
cannot evaluate, a drifted capability definition, an unrecognized
declaration, refuses rather than guesses. Meaning, like state, fails
closed.
The contract has a dual, and the two statements carry equal force.
The resource owns what an action means; the Mission owns why it is
happening and where the undertaking stands, and that context exists
nowhere else in the stack. A resource evaluates each request at
perfect local resolution and zero task resolution: it can price every
consequence its ontology names and cannot see the undertaking the
request belongs to. This is the context asymmetry, and a risk
decision composes both sides of it: semantics without purpose prices
every delete the same, and purpose without semantics cannot read the
call.
"Delete database" in isolation is indistinguishable from catastrophe.
"Delete database" inside an approved migration whose copy steps
already completed is a priced, checkable step. The only place that
judgment is possible is where Decision and Execution Evidence join on
the Mission's identity, because that join is the undertaking's
recorded history and no resource-local view contains it. The runtime
profile names the mechanism: sequence-aware evaluation over the
undertaking's history is an optional decision input, guarded so that
history informs a decision and never widens one
([I-D.draft-mcguinness-mission-runtime]).
9. Mission Roles and Components
For each component: what it does, what it holds, and which document
specifies it. What its compromise costs is the security model's
subject ([I-D.draft-mcguinness-mission-security-model]).
Agent (client): Proposes the Mission Intent and executes the task;
in the OAuth binding it holds derived Mission-bound tokens;
outside the trusted base and assumed compromisable
([I-D.draft-mcguinness-oauth-mission]).
A deployment may authenticate concrete agent instances under the
client-instance-assertion profile and its AI-agent profile
([I-D.draft-mcguinness-oauth-client-instance-assertion],
[I-D.draft-mcguinness-oauth-ai-agent-instance]), which sharpens
delegation chains, joins, and evidence attribution to instance
granularity without touching the Mission model. Attestation-based
client authentication and SPIFFE
([I-D.draft-ietf-oauth-attestation-based-client-auth],
[I-D.draft-ietf-oauth-spiffe-client-auth]) can supply client-
instance authentication and workload credentials beneath these
profiles; they do not define the Mission actor, delegation,
intent, lifecycle, or evidence semantics defined here.
Subject: The user or system on whose behalf the Mission is approved,
an (iss, sub) pair recorded immutably at approval (the OAuth
binding). AAuth keeps the person's relationship and context at
the PS and does not add this OAuth Subject tuple to the mission
blob.
Approver: The single accountable principal who approves the Mission;
equal to the Subject for self-approval (the OAuth binding's Single
Accountable Approver section). In AAuth, the wire approver value
names the PS, not a portable person identifier; the person reviews
and approves through that PS.
Mission Issuer: Validates the Mission Intent, runs the approval
event, records the Mission, and owns its state. The authority-
bearing bindings host it:
* OAuth Authorization Server: every derived token carries the
mission claim, and issuance and refresh are gated on Mission
state ([I-D.draft-mcguinness-oauth-mission]).
* Mission Authority Server: the same record, anchors, and
lifecycle without issuing tokens; the PDP joins ordinary
credentials to the Mission at the point of use
([I-D.draft-mcguinness-mission-authority-server]).
* UMA 2.0 Authorization Server (experimental sketch): the pushed
Mission Intent rides UMA claims pushing, the resource owner's
decision fills UMA's authorization assessment, and RPT issuance
is gated on state ([I-D.draft-mcguinness-mission-uma]).
The OAuth and standalone authority-bearing bindings also serve
audience-scoped policy views, the authority-distribution artifact
the runtime and MAS profiles define
([I-D.draft-mcguinness-mission-runtime],
[I-D.draft-mcguinness-mission-authority-server]). The AAuth
binding does not define such a view from the mission blob;
deterministic resource authorization remains in scopes, resource
tokens, Resource and Access Server policy, and optionally R3.
AAuth Person Server: The controlling authority for the native
Mission Context rather than an OAuth-style Mission Issuer. The
mission blob is committed by AAuth's s256, and the PS gates PS-
asserted issuance and federated brokering. It does not gate
direct identity-based or resource-managed decisions
([I-D.draft-mcguinness-mission-aauth]).
Resource Server: The protected resource. In the OAuth binding it
enforces statelessly from the token and can check the mission
claim (the OAuth binding's Resource Server Enforcement section);
in the standalone binding the token carries no Mission signal, and
Mission properties reach it only through the enforcement path.
PEP and PDP: The PEP sits at the last controllable boundary before
an action and obtains a permit for each consequential action;
under mediated custody it, not the agent, holds the sender-
constraint key.
The PDP evaluates the action against the Mission's authority,
constraints, actor chain, and current state, and fails closed
([I-D.draft-mcguinness-mission-runtime],
[I-D.draft-mcguinness-mission-authzen]); in the standalone binding
it also verifies the subject and client join (the MAS's Mission
Join section).
Agent harness: Hosts the agent; binds sessions, task graphs, queues,
cached tool connections, and sub-agent handles to Mission state;
establishes the environment with no unmediated path to mediated
actions ([I-D.draft-mcguinness-mission-harness]).
Orchestrator: Assigns each workflow step a reversibility class,
records an unwind plan before dispatch, and compensates in-flight
work when a Mission stops
([I-D.draft-mcguinness-mission-orchestration]).
Transparency Service: An append-only SCITT log [RFC9943] that
registers Mission evidence as Signed Statements and issues
receipts verifiable offline
([I-D.draft-mcguinness-mission-audit]).
Verifiers: Parties outside the deployment that check Mission facts
without a token exchange: Mandate verifiers confirm what was
approved ([I-D.draft-mcguinness-mission-mandate]); evidence
consumers check consent, decision, and execution evidence against
the anchors and receipts
([I-D.draft-mcguinness-oauth-mission-consent-evidence],
[I-D.draft-mcguinness-mission-authzen]).
The bindings converge on shared Mission Context capabilities, while
authority carriage and enforcement remain binding-dependent:
Subject Approver
\ |
\ approval event
\ |
+-------------------------------------------------------------+
| Mission Control Point |
| +------------+ +------------+ +------------+ +------------+ |
| | OAuth AS: | | Standalone | | AAuth PS: | | UMA 2.0 AS | |
| | Mission- | | MAS: no | | Mission | | (sketch): | |
| | bound | | tokens; | | Context; | | pushed | |
| | tokens | | the PDP | | PS paths | | Intent; | |
| | gated on | | joins to | | gated | | RPTs gated | |
| | state | | Mission | | | | on state | |
| +------------+ +------------+ +------------+ +------------+ |
+-------|--------------|--------------|--------------|--------+
v v v v
durable approved context and lifecycle;
Authority Set and anchors where the binding defines them
|
| binding-specific state, context,
| and authority surfaces
v
Agent ------> PEP ----------> PDP
(harness, | <- permit -
orchestrator) v
Resource Server
Grouped as planes rather than parts, the same components form the
delegated-authority layer of Section 4, with the evidence surface
crossing all of them:
control Mission control point (OAuth AS | MAS | AAuth PS):
approved context, lifecycle and gating;
anchors and authority distribution where defined
| ^
| state, authority | evidence
v |
enforcement PEP and PDP: a permit per consequential
action, parameter binding, custody
| ^
| mediated actions | outcomes
v |
execution harness, agent, orchestrator: sessions,
sub-agents, queues, unwinding
evidence Consent Evidence, decision and execution
(crossing) evidence, Mission Receipts, the Mandate,
audit transparency
9.1. The Actor Chain
One material action splits across these roles, and the family keeps
each distinct and attributable rather than collapsing them into one
"agent" identity. The identifiers below are shown in the OAuth
binding's instantiation; each binding carries the same distinctions
in its own vocabulary, AAuth natively with its agent identifier, the
Person at the PS, parent_agent for a parent-mediated sub-agent, and
the call chain for a service hop
([I-D.draft-mcguinness-mission-aauth]):
Principal: the Subject, the token sub (the OAuth binding).
Accountable approver: the Approver, committed at the approval event
(the OAuth binding).
Intent generator: the shaper, with Shaping Evidence recording what
it emitted ([I-D.draft-mcguinness-mission-shaping]).
Authorizer: the Mission Issuer at issuance (the OAuth binding); the
PDP per action ([I-D.draft-mcguinness-mission-runtime]).
Approved agent: the OAuth client, client_id on every derived token
(the OAuth binding).
Executing delegate: the outermost act actor (the OAuth binding's
Delegation section).
Credential holder: the mediating PEP under mediated custody
([I-D.draft-mcguinness-mission-runtime]).
Capability executor: the executor of the capability source binding
([I-D.draft-mcguinness-mission-capability-binding]).
Downstream identity: the audience-scoped token and the cross-domain
local subject ([I-D.draft-mcguinness-oauth-mission-cross-domain]).
Attribution survives because no role is inferred from another: each
is carried by its own construct, and the evidence layer records them
together, in runtime evidence and the Mission Receipt
([I-D.draft-mcguinness-mission-runtime]), Consent Evidence, and the
audit feed.
The chain is actor lineage, not authority lineage. An act chain
records who acted through whom; it does not carry what task was
approved, how authority narrowed at each derivation, whether the task
remains active, or which parameter constraints bind. Those travel in
the Mission's own constructs: the anchors, the Authority Set, the
lifecycle state, and Child Mission lineage
([I-D.draft-mcguinness-oauth-mission-child-delegation]). Reading an
actor chain as authorization provenance is the gap the Mission's
lineage exists to close.
9.2. Three Objects, Three Lifecycles
Separately from the authorization flow's four objects (Section 4), a
deployment that runs agents under both an agent identity system and
this family governs three independently lifecycle-bearing objects.
Each has its own owner, lifecycle, and revocation, and the model
stays clean only while none absorbs another's job:
Agent identity (who is acting): The logical agent and, where the
instance profiles are deployed, the concrete instance (Section 9).
Owned by the deployment's agent IAM, a registry or directory
outside this family, and consumed as the client_id, the instance
assertion, and verified instance claims.
Agent Deployment (what is running): The approved behavioral version
of the agent: its code, model, system prompt, tool allowlist, data
scope, and runtime configuration. Owned by the deployment's
change governance; a change to any of these is a new Agent
Deployment, and which changes require re-approving standing
Missions is policy that governance records.
A Mission may be pinned to a named Agent Deployment where the
deployment defines that control. This object is distinct from the
Mission Deployment Profile (Section 14), which is the estate's
published claims manifest, not a property of an agent.
Mission (why the authority exists): This family's object: the
approved task, its lifecycle, and, where the binding derives one,
its Authority Set.
An agent registry is a complementary dependency, not part of the
Mission system; an A2A AgentCard directory ([A2A]) is one example
source. Discovery contents are not authority for workload identity,
authorization, or effective capabilities: a deployment applies local
admission policy and independently verifies the relevant credential,
resource metadata, and capability evidence. Where one exists, the
Mission Issuer and the PDP consume a small, stable slice of it:
* the agent identifier and its owner,
* current status and revocation state,
* the approved Agent Deployment,
* eligibility bounds (what the registry permits the agent to be
approved for, a derivation input, never a grant), and
* risk tier.
Registry state is a state source like any other: the consuming
decision point treats it under the runtime profile's freshness
discipline, with a declared staleness bound, failing closed when it
cannot be established ([I-D.draft-mcguinness-mission-runtime]).
Authorization composes conjunctively across the three lifecycles: a
decision may depend on agent state, Mission state, and credential
validity, and each gates independently. A valid credential never
overrides a revoked agent or a non-active Mission, and a live agent
under an active Mission still fails on an expired credential.
The assurance levels add binding strength in the same order a
deployment adds it: authority is issued to an authenticated client;
instance assertion pins the concrete instance; sender-constraint keys
pin possession; attested runtimes pin the execution environment; and
an Agent Deployment pin holds the behavioral version (Section 13).
The division of labor with agent IAM is one sentence: agent identity
preserves who is acting, and the Mission preserves why their
authority exists. The registry and workload identity authenticate an
approved agent instance; the Mission and its derived Authority Set
say what sanctioned work that instance carries; per-hop credentials
narrow; the runtime layer enforces each action and parameter; and the
evidence layer joins what was approved, decided, and done.
9.3. Swarm Execution: Multiplication, Not Delegation
One composition of the three objects recurs often enough to name. A
Mission pinned to an Agent Deployment through the OAuth binding's
controls.agent_deployment ([I-D.draft-mcguinness-oauth-mission]),
executed concurrently by N attested instances of that Deployment, is
multiplication, not delegation: no act hop, no Child Mission, no
attenuation chain, because authority never moves between principals.
Late binding is attestation: an instance joins the work by
authenticating as the pinned Deployment under the instance profiles
([I-D.draft-mcguinness-oauth-client-instance-assertion],
[I-D.draft-mcguinness-oauth-ai-agent-instance]), not by receiving a
credential from a peer. The invariant is class-grain authorization,
instance-grain attribution: the class, the Agent Deployment projected
as client_id, is an authorization subject, never an attribution
subject, and attribution stays per-instance through the instance
substrate, which forbids a sender-constraint key shared across a
client's instances. The OAuth binding's controls.max_derivations is
the explicit fan-out ceiling, and consumption bounds attach at
Mission grain, so a swarm shares one budget
([I-D.draft-mcguinness-mission-metering]).
The decision ladder:
* The same principal exercising the same authority concurrently is
the swarm: more attested instances of the pinned Deployment
deriving under one Mission, no new construct.
* A different principal acting inline is a delegated token with an
act hop (the OAuth binding's Delegation Within a Mission section).
* A durable sub-agent needing its own lifecycle, approval, or audit
identity is a Child Mission
([I-D.draft-mcguinness-oauth-mission-child-delegation]).
* Offline narrowing is attenuation
([I-D.draft-mcguinness-oauth-mission-attenuation]).
10. The Mission Substrate
The binding-neutral contract is Mission Substrate Requirements
([I-D.draft-mcguinness-mission-substrate]): a contextual-governance
kernel every binding provides (native reference and controller, actor
binding, approved context, approval event, governance gate, bounded
reliance, context propagation, and an ordered governance record) and
eight optional capabilities each binding claims through its Mission
Substrate Statement (Lifecycle-Gated Authorization, State-Observable,
Structured Authority, Monotonic Derivation, Credential-Bound,
Authorized Context Correlation, Independently Verifiable, and
Portable Evidence).
The bindings declare what they provide, each in its Mission Substrate
Statement. The companion profiles named without "oauth" are defined
against the binding-neutral contract and declare what they consume,
each in a Mission Substrate section of its own; the runtime profile
is the exemplar of that consumption declaration
([I-D.draft-mcguinness-mission-runtime]), and the remaining consumers
align progressively. Where a companion consumes a concrete
representation, it is today the OAuth binding's, the realization the
family was first authored against; vocabulary ownership migrates to
the substrate contract by touch
([I-D.draft-mcguinness-mission-substrate]).
The remainder of this section documents that instantiation: eight
primitives, each with its normative home and its consumers. Every
sentence mirrors a rule the named profile states normatively. None
of these OAuth-binding representations or stronger semantics is
required verbatim by the binding-neutral kernel, although several
instantiate mandatory kernel functions: the identifier and issuer
realize the Mission Reference and Controller, the lifecycle realizes
the governance gate, token validity participates in bounded reliance,
and the audit horizon participates in the governance record.
10.1. The Primitives, at a Glance
+==============+==================+==================+==============+
|Primitive |The OAuth | Normative home |Consumed by |
| |realization | | |
+==============+==================+==================+==============+
|Mission |An opaque, non- | The OAuth |Every |
|Identifier and|reused identifier | binding: Mission |companion: |
|Issuer |with at least 128 | Record, Mission |decisions, |
| |bits of entropy | Identifier |evidence, |
| |and no semantic | Format |harness |
| |content, plus the | |bindings, the |
| |issuer URL; | |state |
| |together they | |surfaces, the |
| |name exactly one | |audit |
| |Mission. The | |statement |
| |kernel requires | |subject, the |
| |stability, non- | |Mandate |
| |reassignment, and | | |
| |unguessability, | | |
| |not this syntax | | |
+--------------+------------------+------------------+--------------+
|Lifecycle |The states of | The OAuth |Runtime per- |
|state space |Section 4, open | binding (state |class re-check|
| |to companion- | space, only- |(fail closed |
| |defined states, | active); the |on staleness),|
| |with the only- | status and |harness pause,|
| |active rule, | runtime profiles |suppress, and |
| |fail-safe | (freshness); |terminate, the|
| |unrecognized | Status and |orchestrator's|
| |states, and a | Signals |unwind |
| |freshness source | (observation) |trigger, the |
| |with a stated | |Mandate (state|
| |staleness bound | |as of minting)|
+--------------+------------------+------------------+--------------+
|Authority Set |Authorization- | The OAuth |Runtime and |
|representation|details entries | binding: Mission |the AuthZEN |
| |([RFC9396]), each | Authority, |binding, the |
| |naming resource, | Subset Rule, |MAS, Expansion|
| |actions, and | Common |and |
| |constraints, | Constraints |Completion, |
| |under the subset | |Child |
| |rule (derived or | |Delegation and|
| |delegated | |Offline |
| |authority is | |Attenuation, |
| |never broader) | |Consent |
| |and the Common | |Evidence, the |
| |Constraints | |Mandate |
| |vocabulary | | |
| |(registered names | | |
| |with fixed subset | | |
| |and intersection | | |
| |rules) | | |
+--------------+------------------+------------------+--------------+
|Integrity- |A committed | The OAuth |Consent |
|anchor |object hashed | binding: |Evidence, |
|envelope |over a typ- | Integrity |Shaping, the |
| |domain-separated, | Anchors, |runtime layer |
| |issuer-bound | Canonicalization |and AuthZEN |
| |envelope with | Rules, |binding |
| |fixed | Extensibility |(mission- |
| |canonicalization | |policy-view), |
| |and an algorithm- | |Orchestration,|
| |prefixed encoding | |the Mandate, |
| |a verifier | |Audit |
| |recognizes or | |Transparency |
| |rejects (unknown | | |
| |prefixes refuse; | | |
| |no downgrade); | | |
| |the typ space is | | |
| |the extension | | |
| |point | | |
+--------------+------------------+------------------+--------------+
|Issuer key |Signing keys | The OAuth |Verifiers of |
|material |resolvable from | binding: Signing |Mission-bound |
| |issuer; across a | and Key Rotation |credentials, |
| |rotation each key | |Consent |
| |identifier stays | |Evidence, the |
| |resolvable while | |Mandate, the |
| |artifacts signed | |signed state |
| |under it remain | |surfaces, |
| |within the audit | |Audit |
| |horizon | |Transparency |
+--------------+------------------+------------------+--------------+
|Audit horizon |The deployment- | The OAuth |Consent and |
| |declared | binding: Mission |runtime |
| |retention window: | Record |evidence and |
| |at least the | |Audit |
| |Mission's | |Transparency |
| |lifetime plus a | |(retention), |
| |declared post- | |the MAS |
| |terminal period | |(record |
| | | |retention), |
| | | |the security |
| | | |model's |
| | | |retention |
| | | |analysis |
+--------------+------------------+------------------+--------------+
Table 1: Substrate primitives in their OAuth realization
The anchors in the envelope row are *commitment anchors*, not
enforcement proofs (Section 11): a narrowed-token Resource Server
enforces the authority it receives rather than reconstructing
authority from a hash of a full set it does not hold
([I-D.draft-mcguinness-mission-security-model]).
10.2. Token Classes
"Mission-bound" is a specific claim. This document names three token
shapes descriptively, so a weak one is not read as the strong one;
the names below are this document's own, and the properties the
strong class requires are the OAuth binding's:
* a *Mission-referenced token* carries a Mission identifier only;
* a *Mission-derived token* carries authority derived from an active
Mission; and
* a *Mission-bound token* is Mission-derived and additionally
active-state gated, subset-constrained, and refresh-gated: in the
contract's vocabulary, a credential covered by the binding's
Lifecycle-Gated Authorization, Monotonic Derivation, and
Credential-Bound claims, which the OAuth binding's conformance
rule requires of the OAuth binding.
Only the third earns the term: a mission claim alone is a reference,
not Mission-bound authorization. The family reserves "Mission-bound"
for that class, and a binding earns it through the capability claims
of its Mission Substrate Statement, not by protocol lineage.
10.3. The Mission-Bound Credential
A credential carrying the mission claim (id, issuer, authority_hash)
and Mission-derived authorization details, issued only while the
Mission is active. Home: the OAuth binding's Mission-Bound Access
Tokens and The Mission Claim sections.
This is the binding-dependent primitive, and it is exactly where the
bindings split. The OAuth binding provides it. The standalone
binding does not: the MAS's Mission Substrate section states that a
MAS provides neither this credential nor issuance gating
([I-D.draft-mcguinness-mission-authority-server]). An AAuth auth
token can carry the native {approver, s256} mission reference, but it
does not carry the OAuth authority_hash or Mission-derived
authorization details and therefore is Mission-referenced, not a
Mission-bound credential in the strong sense defined above
([I-D.draft-mcguinness-mission-aauth]).
For profiles that compose with it, the seam is the runtime profile's
Mission binding establishment step
([I-D.draft-mcguinness-mission-runtime]): the credential carries the
Mission reference where the binding provides one, and a binding
without it supplies an externally established reference, verified
under a join the binding defines, which the MAS profiles as its
Mission Join.
Offline Attenuation attenuates this credential and the token-carriage
aspects of delegation ride it, so both require it; the companions
that need a credential-to-Mission association (the runtime layer and
the harness) route through the binding establishment step, which is
what makes the standalone binding possible.
The issuance-grant companion
([I-D.draft-mcguinness-oauth-mission-issuance-grant]) composes the
two: the standalone Mission Issuer mints a Mission Issuance Grant
that a consuming Authorization Server redeems for Mission-bound
tokens, providing this primitive compositely.
10.4. Approval Fidelity
For the portable-authority bindings, the approval event authenticates
the Approver, establishes the Subject, derives and renders the
Authority Set for consent, computes the anchors over the consented
set, the approved Intent, and, where one was submitted, the authority
proposal, and creates the record in active atomically with the
decision.
AAuth approval has different fidelity: the native propose, clarify,
and approve interaction authenticates the parties, returns the
approved mission blob and exact-byte s256 commitment, and creates an
active Mission Context. It does not render or commit an OAuth
Authority Set.
Home: the OAuth binding's Mission Approval section. Consumed by
Consent Evidence, which binds to this event, and by every downstream
guarantee that assumes the anchors, the gating, and the record.
10.5. The Validity Model
Five validity horizons govern reliance, each with its own setter,
checker, and consequence; implementations most often err by
conflating them:
Token exp: set by the credential issuer and checked by every
consumer of the token. In the OAuth binding it is capped by the
Mission's expires_at. Past it the credential is dead and
obtaining a new credential re-enters whatever issuance gate the
binding and access mode provide.
Mission state, and expires_at where defined: set by the controlling
authority and checked at the binding's declared control points.
In OAuth, the issuance gate, PDP, and state consumers enforce it.
In AAuth, the PS enforces active or terminated at PS endpoints and
on PS-asserted and federated paths; direct identity-based and
resource-managed decisions have no PS state gate.
fresh_until: set by the status responder; checked by status
consumers. Past it a cached state report may not be relied on and
is re-fetched.
Permit window: set by the PDP; checked by the executing PEP. Past
it the permit is void and a new decision is required.
Action-approval freshness: set by the approval surface; checked by
the PDP. Past it an action-bound approval no longer authorizes
the action it named.
The horizons compose by minimum: reliance at any moment requires
every applicable horizon to be open, and no horizon substitutes for
another.
The horizons also give the deployment its freshness dial, and the
TTL-only end of that dial is a first-class posture, not a fallback.
A deployment that relies on lifetimes alone verifies with local
cryptography and a clock: no state source, no freshness discipline,
no availability coupling, and a worst-case exposure equal to the
lifetime by construction. Where every fresh credential crosses a
Mission-state decision point, this realizes the *lifecycle-gated*
capability with reliance bounded by credential lifetime alone
([I-D.draft-mcguinness-mission-substrate]). It is not a property of
every access mode: AAuth's PS-asserted and federated paths have that
gate, while its direct modes do not. That posture is the right
choice at action grain, where an artifact lives seconds to minutes
and no revocation can land inside its window, and for short missions;
the family's own short-lived artifacts (the permit, the cross-domain
grant, the Join Assertion) already sit at this end. What a lifetime
cannot do is suspend, complete, or kill now, which is the task-grain
residue the Mission's state carries and which the *state-observable*
capability reaches: an authenticated freshness source with a stated
staleness bound, a named substrate capability a binding MAY provide
beyond the kernel's bounded-reliance floor
([I-D.draft-mcguinness-mission-substrate]), and the one runtime
enforcement requires ([I-D.draft-mcguinness-mission-runtime]). The
two ends are one mechanism seen from opposite sides: a lifetime
relocates the freshness check from the verification path to the
issuance path, so every re-issuance is the policy re-check, which is
the family's gates-new-derivation-only rule in its other reading. A
deployment states where it sits on the dial through its bounded-
revocation claim (Section 13.2): a TTL-only posture claims the
lifetime as its bound only for paths whose re-issuance is gated, with
no state-observable overlay. The runtime profile prices each
position, source by source, in its state and freshness section
([I-D.draft-mcguinness-mission-runtime]).
10.6. The Binding Checklist
For a new binding this checklist is now normatively stated by Mission
Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]);
this section remains the informative summary, and the existing
bindings remain authoritative for themselves.
Another mission-based protocol supplies a Mission Context when it
maps the following native capabilities explicitly:
* a stable reference and controlling authority;
* binding to the acting actor;
* immutable approved context, or a verifiable commitment to it;
* an explicit approval event;
* an active-state gate at declared control points;
* a stated reliance bound on every governed decision and artifact;
* context propagation or decision correlation; and
* an ordered governance or audit record.
Structured authority, monotonic derivation, credential carriage,
state observability, independent verification, and portable evidence
are optional facets. A binding composes only the profiles whose
required facets it provides. AAuth supplies the Mission Context
capabilities in its own idiom but not a portable Authority Set or
universal subset rule.
The per-profile Mission Substrate sections remain the authoritative
per-consumer statements of this interface.
10.7. Error Surfaces
The OAuth and MAS profiles use three error surfaces, each owned once.
OAuth endpoints return OAuth error codes, owned by the OAuth binding
([I-D.draft-mcguinness-oauth-mission]). Lifecycle surfaces,
including management, return the status profile's JSON error body
(error, error_description, nonce)
([I-D.draft-mcguinness-oauth-mission-status],
[I-D.draft-mcguinness-oauth-mission-management]). MAS-native
surfaces return the MAS error object, which adds error_reason and
omits the nonce ([I-D.draft-mcguinness-mission-authority-server]).
AuthZEN denial reasons are not a fourth surface: they ride the
decision response ([I-D.draft-mcguinness-mission-authzen]). Where
the same symbol exists as both an OAuth error code and a wire-body
symbol (invalid_request), the envelope it arrives in disambiguates.
The AAuth binding retains AAuth's own error surface. Its native
management companion returns application/problem+json, preserves the
base AAuth mission_terminated error on ordinary PS operations, and
makes an absent reference indistinguishable from one the caller is
not authorized to observe
([I-D.draft-mcguinness-mission-aauth-management]).
Registration posture is likewise deliberate per artifact class:
OAuth-facing parameters and media types register with IANA, evidence
media types defer registration until cross-domain interoperability
demands it, and each profile states which posture it takes.
11. The Authority Derivation Boundary
Deriving the Authority Set from the Mission Intent is the semantic
heart of the model and the one step the family deliberately does not
standardize. The consequence is a trust boundary worth stating
plainly: interoperability begins at the committed result, not at the
Intent. A Mission Intent has no portable semantics; two conforming
Authorization Servers can derive different Authority Sets from the
same Intent, and audit can establish what was derived (against
intent_hash and policy_version), never whether it was the right
reading of the task. A deployment whose partners must reason about
its derivations can publish a derivation policy identifier and test
fixtures that pin Intent-to-Authority-Set outcomes, making the local
policy reviewable even though it does not travel. Narrowing mode
([I-D.draft-mcguinness-oauth-mission]) is the checkable path: where
the client supplies candidate authority, derivation is a subset of it
and reproducible, which is the closest the family comes to portable
derivation.
The ceiling the derivation narrows against is itself a composition,
not a single object. The derived Authority Set sits inside every
bound on the task: the issuer's derivation policy, the ceiling of the
Mission's established authority source (a delegating person's own
authority, a workload's provisioned authority, or governed
organizational policy: approval activates authority the source
already holds and grants nothing beyond it, and the Approver needs
authority to activate the source, not personal possession of its
permissions), and, at enforcement time, the resource owner's and
deployment's live policy at the decision point. The derivation step
intersects the first two and commits the result; the runtime contract
re-checks the rest on every action, which is why a permit is never
implied by the Authority Set alone. A deployment adding further
sources (a tenant boundary, an environment-specific floor) adds them
as derivation-policy inputs or as decision-point policy, never as
agent-negotiated widening.
The derivation modes rank by how portable their result is:
+==========================+=================================+
| Derivation mode | Portability status |
+==========================+=================================+
| Client proposes concrete | Interoperable default |
| authority; AS narrows | |
+--------------------------+---------------------------------+
| AS derives from | Profile-specific |
| structured Intent fields | |
+--------------------------+---------------------------------+
| AS derives from free | Local, non-portable unless |
| text | profiled |
+--------------------------+---------------------------------+
| LLM-assisted derivation | Advisory unless a deterministic |
| | policy commits the output |
+--------------------------+---------------------------------+
Table 2
A deployment seeking interoperable authority uses the first; free-
text and model-assisted derivation are local policy unless a profile
pins them with a published policy identifier, version, and test
fixtures.
12. Mission Deployment Patterns
12.1. Binding Security Architectures
The bindings share Mission Context capabilities but are not one
security system: each has its own authority representation, trust
assumptions, cutoff behavior, and failure modes, and a deployment
names its architecture, not only its binding. Three patterns cover
the bindings:
* *credential-carried authority*: the credential names the Mission,
carries derived authority, and issuance is gated (the OAuth AS and
UMA AS);
* *PDP-joined*: credentials are ordinary and a join establishes the
association at the decision point (the standalone MAS); and
* *context-carried*: AAuth carries its native {approver, s256}
reference while authority remains in resource scopes and policy.
The PS gates PS-asserted and federated authorization, while direct
identity-based and resource-managed decisions bypass the PS.
The differences that decide a design:
+==============+=========+==========+==============+================+
| Property |OAuth AS |MAS | AAuth PS | UMA AS |
| | | | | (sketch) |
+==============+=========+==========+==============+================+
| Credential |yes |no | native | yes (claim or |
| carries the |(mission | | reference | introspection) |
| Mission |claim) | | where | |
| | | | supported | |
+--------------+---------+----------+--------------+----------------+
| Issuance |yes |no (the | PS-asserted | yes |
| gated on | |issuance | and | |
| state | |grant | federated | |
| | |restores | only | |
| | |it per | | |
| | |consuming | | |
| | |AS) | | |
+--------------+---------+----------+--------------+----------------+
| Runtime PDP |no |yes | required | no (per-use |
| required for |(issuance|(runtime | for direct | introspection |
| a kill |gate |is the | modes; PS- | cuts off) |
| switch |exists; |only | path | |
| |runtime |cutoff) | issuance | |
| |tightens)| | has a | |
| | | | bounded | |
| | | | cutoff | |
+--------------+---------+----------+--------------+----------------+
| Join |no |yes | no when the | no |
| ambiguity | |(bounded | native | |
| possible | |by join | reference | |
| | |assurance)| is | |
| | | | preserved; | |
| | | | it can be | |
| | | | ignored in | |
| | | | direct | |
| | | | modes | |
+--------------+---------+----------+--------------+----------------+
| Revocation |token |runtime | auth-token | next |
| latency |lifetime,|and status| lifetime on | introspection |
| source |status, |only | PS paths; | |
| |or | | no Mission | |
| |runtime | | cutoff on | |
| | | | direct | |
| | | | paths | |
+--------------+---------+----------+--------------+----------------+
| Offline |partial |limited | reference | JWT RPTs |
| Mission |(claims |(join | integrity | partial; |
| verification |verify; |assertion)| only; blob | opaque RPTs |
| |state | | is private | none |
| |does not)| | | |
+--------------+---------+----------+--------------+----------------+
Table 3
The table is the one-page answer to a question the object-level
framing invites: a MAS deployment does not provide AS-native
semantics because both hold the same Mission, and a reader comparing
deployments compares architectures first.
The OAuth binding stacks two independent chokepoints. Issuance
gating acts at the token layer: a revoked or expired Mission stops
all further derivation and refresh, and short-lived tokens age out.
Runtime enforcement acts at the action layer: each consequential
action is re-checked against current state at the point of use.
Issuance gating plus runtime enforcement is strictly stronger than
either alone: a gap in PEP coverage is still bounded at the token
layer, and an outstanding token is still stopped at the action layer.
The AAuth binding has a narrower structural chokepoint. The Person
Server refuses new PS-asserted issuance or federated brokering for a
terminated Mission Context, bounding those paths by auth-token
lifetime. Identity-based and resource-managed decisions do not cross
that chokepoint. The AAuth binding defines no generic family runtime
composition or independently resource-verifiable Authority Set
([I-D.draft-mcguinness-mission-aauth]).
Per-action enforcement is budgeted, not blanket: only consequential
actions are gated, the common-case decision is a local evaluation
against a materialized policy view whose network cost is paid per
freshness window, and only the high-consequence classes are required
by the runtime profile to hold a synchronous gate (the runtime
profile's deployment considerations,
[I-D.draft-mcguinness-mission-runtime]).
The composition is an overlay, not a substrate swap: a deployment
mediates the paths where the high-consequence classes live and lets
every other resource ride lifetime-bounded reliance (Section 13),
token lifetimes sized to the tolerated staleness, with no state
evaluation at the resource.
The standalone mode trades the token-layer kill switch for zero
Authorization Server changes. A MAS creates, approves, and serves
Missions while tokens remain ordinary; the PDP joins credentials to
Missions, and the MAS is the freshness source.
The cost is structural: no mission claim travels, revoking a Mission
stops nothing at the token layer, and enforcement rests entirely on
PEP coverage, so a token exercised outside that coverage is
ungoverned (the MAS's Limitations section). The path to a token-
layer chokepoint is the OAuth binding, where the estate's AS can
change; the record, anchors, and lifecycle carry over unchanged.
That is a move between peer architectures, not an upgrade from a
lesser one: the MAS remains a peer binding, not a staging area (its
own document's framing).
Between the two sits the issuance join
([I-D.draft-mcguinness-oauth-mission-issuance-grant]): the MAS
remains the Mission Issuer while estate Authorization Servers redeem
Mission Issuance Grants for Mission-bound, state-gated tokens,
restoring the token-layer chokepoint without moving approval.
12.2. Entry Ramps by Estate
Which chokepoint a deployment builds first is decided by the estate
it already runs, not by preference. The OAuth binding's issuance
ramp assumes an Authorization Server that supports pushed
authorization requests, rich authorization requests, and JWT access
tokens; the standalone ramp assumes none of that and trades it for
PEP coverage. By starting condition:
+=============+==========+=====================================================+
|Estate |Entry ramp|Day-one delta |
|starting | | |
|condition | | |
+=============+==========+=====================================================+
|AS |The OAuth |AS adds intent intake, derivation, approval, record, |
|changeable; |binding |and gating; scope-only Resource Servers and clients |
|PAR, RAR, and| |continue unchanged |
|JWT access | | |
|tokens in | | |
|place | | |
+-------------+----------+-----------------------------------------------------+
|AS |MAS first;|A MAS beside the AS; nothing else changes |
|changeable; |the OAuth | |
|RAR absent or|binding | |
|tokens opaque|once the | |
| |AS gains | |
| |the token | |
| |plane (a | |
| |peer move,| |
| |not an | |
| |upgrade) | |
+-------------+----------+-----------------------------------------------------+
|AS cannot |Standalone|Records and approvals first; enforcement arrives with|
|change |MAS, phase|PEP/PDP coverage |
|(shared, |by phase | |
|third-party, | | |
|SaaS) | | |
+-------------+----------+-----------------------------------------------------+
|Many |MAS as |Each AS adds grant redemption only |
|Authorization|estate |([I-D.draft-mcguinness-oauth-mission-issuance-grant])|
|Servers, one |control | |
|governance |plane; | |
|point |issuance | |
| |join per | |
| |consuming | |
| |AS | |
+-------------+----------+-----------------------------------------------------+
|No PEP/PDP |The OAuth |Lifetime-bounded reliance (short tokens, gated |
|over |binding |refresh); the runtime overlay added later, where the |
|consequential|where the |high-consequence classes live |
|paths |AS allows;| |
| |runtime | |
| |layer next| |
+-------------+----------+-----------------------------------------------------+
Table 4
Every row shares the record, anchors, and lifecycle, so a ramp is an
entry point, not a fork: Missions carry unchanged from any row to the
rows a deployment adopts later.
One ramp cuts across the rows: the *short mission*. A Mission whose
expires_at sits minutes out, run in records mode with lifetime-
bounded reliance, is a durable approval record with TTL-grade
operational cost: audit, anchors, and bounded exposure with no state
surface anywhere (Section 10.5). A deployment can adopt the family
this way first, per task, and add state surfaces only where missions
grow long enough to need suspend, complete, or kill-now.
In sequence, the standalone mode runs submit, poll, approve, join,
permit:
Client MAS Approver PEP/PDP
| | | |
| 1 submit Intent | | |
|------------------->| | |
| 2 202 pending | | |
|<-------------------| | |
| | 3 disclose | |
| |----------------->| |
| | 4 approve | |
| |<-----------------| |
| | Mission active | |
| 5 poll | | |
|------------------->| | |
| 6 approved, | | |
| mission_id | | |
|<-------------------| | |
| 7 action, token, | | |
| Mission ref | | |
|--------------------------------------------------->|
| | 8 signed status: | |
| | active | |
| |<------------------------------|
| |------------------------------>|
| | | 9 join; |
| | | evaluate |
| 10 permit | | |
|<---------------------------------------------------|
The token in step 7 is an ordinary OAuth token from the unchanged AS;
steps 8 through 10 are the Mission Join and the runtime decision (the
MAS's Mission Join section), and the MAS's staged walkthrough of the
same flow is its end-to-end appendix
([I-D.draft-mcguinness-mission-authority-server]).
The quarantine pattern removes a leg of the injection-to-exfiltration
chain instead of gating it: no single Mission ever holds untrusted
input and an egress path at once.
* Work that ingests untrusted content runs under a Mission with no
external-communication or external-commitment authority.
* Work that communicates externally runs under a separate Mission
whose inputs are the quarantined product.
* The crossing between them, a human review or a deterministic
transformation, is recorded as evidence, under the harness taint
policy ([I-D.draft-mcguinness-mission-harness]) and, where
claimed, the runtime profile's trifecta containment
([I-D.draft-mcguinness-mission-runtime]).
The quarantine pattern is the deployment-shaped case of a general
rule that holds for every work product one Mission passes to another.
A work product crossing into a receiving Mission is input, not
authority: the receiving Mission re-evaluates any proposed action
under its own Authority Set, and the producing Mission's authority
does not transfer through the artifact by copying, referencing,
embedding, or communicating it. The Mission Work Products companion
([I-D.draft-mcguinness-oauth-mission-work-products]) is the normative
home of this rule and defines the provenance object that attributes
an artifact without granting anything. Ingesting a work product is
an added conjunctive gate at the receiving Mission's boundary: it
composes with the three objects' independent gates and does not nest
inside them, so Actor, Agent Deployment, and Mission stay a gating
pipeline, not a containment hierarchy (Section 9.2).
Where the separation must hold within one Mission, the metering
profile's exclusivity control
([I-D.draft-mcguinness-mission-metering]) latches read-and-egress
apart under a single approval.
The *standing-agent pattern* governs the agent whose work never ends.
The agent stands; the authority cycles: the standing thing is a
charter, a Mission with a consented authority ceiling and drawdown
policy ([I-D.draft-mcguinness-oauth-mission-progressive],
experimental), and the working thing is the bounded Mission each unit
of work draws under it, as an in-ceiling successor or a policy-
approved Child Mission
([I-D.draft-mcguinness-oauth-mission-child-delegation]), each
expiring and discharging as its unit completes
([I-D.draft-mcguinness-oauth-mission-status]).
The progressive profile's prohibited set keeps the high-consequence
classes on a fresh human approval inside the ceiling, and its Ceiling
Review bounds the chain in time with an evidence-rendering renewal.
Without the progressive profile the same pattern runs as ordinary,
freshly approved unit Missions with deferred approval
([I-D.draft-mcguinness-oauth-mission-approval]) absorbing the volume:
the experimental profile changes the unit economics, not the
governance shape.
12.3. Comparison to a Conventional Stack
A skeptical reading of this family asks why Rich Authorization
Requests [RFC9396], short-lived tokens, and an AuthZEN PDP holding
policy and session state server-side would not suffice. Steelmanned
first: RAR supplies structured authorization data an Authorization
Server renders into an itemized approval experience; RAR itself
guarantees neither approval fidelity nor a consent UI. A short token
lifetime bounds revocation only when every issuance, refresh, and
exchange path re-evaluates current grant or session state; absent
that discipline a fresh short token keeps issuing against stale state
regardless of lifetime, the dependency the Validity Model already
states (Section 10.5). AuthZEN specifies a decision API, not a
global PDP, a durable session store, complete PEP placement, or a
state model; a deployment supplies those properties in either design.
Inside one administrative domain, a conventional stack (structured
request data, an Authorization Server's consent or grant record,
short credentials, and a stateful PDP) implements durable task state,
fan-out joins, persistent narrowing, and audit locally. Five places
mark where that local composition meets what this family
standardizes:
1. *Durable task semantics across tokens and restarts.* OAuth
grants, refresh families, or PDP records can outlive a token.
Mission standardizes an independently addressable, lifecycle-
bearing approved task with anchors consistently interpreted by
the Authorization Server, PDP, agents, audiences, and evidence
producers (the OAuth binding's Why a New Object and Relationship
to Other Authorization Objects sections,
[I-D.draft-mcguinness-oauth-mission]); it does not make
persistence newly possible.
2. *Multi-credential, multi-actor join.* A deployment can invent a
transaction, grant, or workflow identifier shared across
credentials. Mission gives that join stable approved-task
semantics, binds it to authority, and carries it through
delegation and fan-out outside one private PDP schema
(Section 9.3).
3. *A second trust domain.* A partner can call the origin PDP, share
state, or federate policy. The trade is synchronous coupling,
availability, and disclosure. Cross-Domain Projection offers
bounded local credentials and common anchors while accepting
local-token revocation latency (the Project verb). It is a
portability choice, not the only possible design.
4. *Approval as a first-class record.* A local consent or grant
database plus versioned decision logs can preserve what was
approved. Mission's value is a standardized immutable snapshot,
integrity anchors, and one reference portable evidence can cite
(the OAuth binding's Why a New Object section,
[I-D.draft-mcguinness-oauth-mission]; the Prove verb).
5. *Persistent narrowing.* A stateful Authorization Server or PDP
can store reduced entitlements and consult them at issuance.
Mission standardizes monotonic subset semantics across issuance,
delegation, attenuation, and cross-domain projections, auditable
across components (Section 8).
+=============+================+===================+===============+
| Requirement | Conventional | Mission | Illustrative |
| | OAuth+PDP | standardization | added Mission |
| | realization | | cost |
+=============+================+===================+===============+
| Durable | Grants, | An addressable, | Durable- |
| task | refresh | lifecycle-bearing | object and |
| semantics | families, or | approved task | lifecycle |
| | PDP records | with anchors | storage |
| | outlive the | consistently | |
| | token | interpreted | |
| | | across components | |
+-------------+----------------+-------------------+---------------+
| Multi- | A deployment- | A stable | New claims |
| credential | invented | approved-task | and endpoints |
| join | transaction, | reference bound | |
| | grant, or | to authority, | |
| | workflow | carried through | |
| | identifier | delegation and | |
| | | fan-out | |
+-------------+----------------+-------------------+---------------+
| Second | The partner | Bounded local | State |
| trust | calls the | credentials and | consistency |
| domain | origin PDP, | common anchors | and |
| | shares state, | carried by | distribution; |
| | or federates | projection | privacy and |
| | policy | | correlation |
| | | | surface |
+-------------+----------------+-------------------+---------------+
| Approval as | A consent or | A standardized | Evidence |
| a record | grant database | immutable | operations |
| | plus versioned | snapshot with | |
| | decision logs | integrity anchors | |
| | | and one portable | |
| | | reference | |
+-------------+----------------+-------------------+---------------+
| Persistent | A stateful | Monotonic subset | AS or MAS |
| narrowing | Authorization | semantics | integration; |
| | Server or PDP | enforced across | ecosystem |
| | stores reduced | issuance, | adoption |
| | entitlements | delegation, | |
| | and consults | attenuation, and | |
| | them at | cross-domain | |
| | issuance | projections | |
+-------------+----------------+-------------------+---------------+
Table 5
Past these crossovers, a conventional deployment often accumulates a
durable task record, a stable join key, lifecycle checks, narrowing
rules, and audit correlations. Mission standardizes that recurring
shape across bindings and trust domains; it does not claim local
policy systems cannot implement equivalent outcomes.
12.4. A Worked Composition
This non-normative example composes an Action-Enforced deployment
from four providers, none of which is the OAuth binding, to show that
the substrate contract ([I-D.draft-mcguinness-mission-substrate])
carries the weight: an AAuth agent acts under a PS-governed Mission
and calls a payment API whose authority vocabulary is owned by the
resource.
Four components publish provider claims:
+============+=======================+=========================+
| Provider | Capability supplied | Scope |
+============+=======================+=========================+
| AAuth | Contextual-governance | PS permission decisions |
| Person | kernel; Lifecycle- | and PS-brokered |
| Server | Gated Authorization | issuance |
+------------+-----------------------+-------------------------+
| AAuth | State-Observable | The payment PDP, |
| Mission | | maximum staleness five |
| Management | | seconds |
+------------+-----------------------+-------------------------+
| Payment | Structured Authority | Payment API actions and |
| policy | | constraints under the |
| adapter | | payment policy's own |
| | | versioned vocabulary |
+------------+-----------------------+-------------------------+
| Payment | Authorized Context | The schedule_payment |
| gateway | Correlation | and release_payment |
| PEP/PDP | | routes |
+------------+-----------------------+-------------------------+
Table 6: Provider claims in the worked composition
Action-time enforcement and decision evidence are supplied by the
runtime profile and its evidence companion at the gateway
([I-D.draft-mcguinness-mission-runtime]); they consume the capability
claims above as decision inputs. The AAuth rows come from the
binding's own published Mission Substrate Statement: the lifecycle
claim from the base Statement, and the state claim under its Mission
Management activation condition, each with the Statement's temporal
and failure elements ([I-D.draft-mcguinness-mission-aauth]). The
payment policy adapter's and the gateway's claims remain the
deployment's own, stated as deployment-local provider claims; nothing
here implies every provider claim becomes binding-owned. The
deployment declaration names the four providers, the two routes, and
the consequence class; no machine-readable declaration format is
defined (the Mission Deployment Profile's schema remains reserved
future work, Section 14), and the declaration is ordinary deployment
documentation.
The deployment runs PS-asserted access. Every resource token the
gateway accepts is PS-issued or PS-brokered and carries the signed
mission_s256 reference, the protected propagation path; identity-
based and resource-managed access are out of scope here, because
those paths are not PS-gated and may ignore the reference. The
gateway's join validates the carrying artifact's issuer (the Person
Server), its audience (the payment API), the actor binding (the
agent's key, proven on the request), and the request binding, before
joining the PS evidence, the Actor proof, the request, and the
adapter's output; the join is scoped to the two named routes with a
lifetime no longer than the state observation's declared freshness,
and a missing or conflicting input fails closed.
The composition succeeds with these results and limits:
+=============+============+==================================+
| Requirement | Provider | Result and material limit |
+=============+============+==================================+
| Kernel | AAuth | Satisfied; native private |
| | Person | Mission context and lifecycle |
| | Server | |
+-------------+------------+----------------------------------+
| Current | AAuth | Satisfied; five-second staleness |
| state | Mission | within the profile's declared |
| | Management | maximum |
+-------------+------------+----------------------------------+
| Structured | Payment | Satisfied only inside the |
| authority | policy | payment vocabulary; no cross- |
| | adapter | resource claim |
+-------------+------------+----------------------------------+
| Authorized | Payment | Satisfied; the gateway validates |
| join | gateway | PS provenance, Actor proof, the |
| | | request, and the adapter's |
| | | output before joining them |
+-------------+------------+----------------------------------+
| Action-time | Runtime | Satisfied for the two named |
| enforcement | profile at | routes; direct payment-API |
| | the | routes are prohibited or |
| | gateway | declared uncovered |
+-------------+------------+----------------------------------+
| Evidence | Evidence | Satisfied through the decision; |
| | companion | approval-to-effect completeness |
| | at the | additionally requires execution |
| | gateway | evidence |
+-------------+------------+----------------------------------+
Table 7: Composition result
Two classifications make the example honest. The payment authority's
fresh decision is decide_anew in the substrate's transition
classification, never an attenuation of AAuth authority across
vocabularies; and the AAuth Mission context never becomes a Rich
Authorization Request object. AAuth supplies work continuity, the
payment authority decides permission in its own vocabulary, and the
gateway is the scoped joining and enforcement authority.
The same composition fails when any of the following holds: the state
source is disabled with no equivalent fresh local read; the adapter
publishes descriptive strings rather than machine-evaluable
semantics; the gateway accepts a Mission reference from the agent
without validated provenance (context splicing); the state source's
staleness exceeds the declared maximum; a direct route bypasses the
gateway; the gateway accepts the reference on an identity-based or
resource-managed request; or the payment-vocabulary claim is
generalized to another resource's vocabulary.
13. Mission Assurance Levels
Two questions get asked of a Mission deployment: what to deploy for a
goal, and what guarantee it has earned. They share one progression,
so this document states a single set of levels, each carrying both
facets, the document set and the proof obligations, and names them so
a deployment, a procurement, or a review can cite one level. The
levels are guidance, not a conformance class; every companion is
optional and states its own scoped conformance.
Because the family's strongest properties are deployment properties,
not protocol properties (complete PEP placement, a trusted freshness
source, and credential custody are things a deployment does, not
things a token proves), a level is a claim, verifiable in the sense
the runtime profile fixes ([I-D.draft-mcguinness-mission-runtime]),
not a label: a deployment states the highest level it has earned in
its Enforcement Scope Statement, and a consumer treats an unstated or
unproven level as not claimed.
The levels build on one another: a deployment adopts recording and
governing the approved task (Baseline Issuance), then per-action
enforcement (Runtime-Enforced), then full agent safety (Governed and
High-Assurance Agent), advancing to the level its risk warrants and
stopping there.
A level is a dependency bundle: which documents a deployment runs, in
adoption order. What a deployment can prove is the orthogonal claims
axis (Section 13.2), and the proof obligations noted with each level
below are the claims that become available at that level, not
properties the level name itself asserts; the claims, not the level,
are what a relying party compares.
The levels are one axis; the *binding* is an orthogonal one. The
authority-bearing bindings name their level separately from their
binding. An AAuth deployment instead reports the Mission Context
capabilities and resource access modes it actually uses; selecting
the AAuth binding does not by itself satisfy structured-authority,
subset, portable-evidence, or runtime proof obligations.
The standalone MAS binding is the case that matters most: it provides
the Mission record, lifecycle, and authority but no Mission-bound
credential and no issuance gating, so under it the kill switch is the
runtime layer alone, not the token gate, and a deployment states
that. Binding is not a level.
The AAuth distinction is access-mode dependent: PS-asserted and
federated access have a PS lifecycle gate for new authorization;
identity-based and resource-managed access do not. Its native auth
token is Mission-referenced, not the strong Mission-bound credential
defined by the OAuth binding.
The levels, cumulative:
*Baseline Issuance*: the approved, anchored Mission record and its
lifecycle: authority derived and committed at the approval event
with the integrity anchors (the OAuth binding).
Where a structured-authority binding issues Mission-bound
credentials, issuance is bounded by the subset rule and gated on
Mission state, which grants task-bound, auditable authority and a
possession-independent kill switch at the issuance gate; it grants
no per-action control, and outstanding tokens run to their own
expiry.
Sized deliberately, that expiry is the level's revocation bound:
*lifetime-bounded reliance*, access-token lifetimes no longer than
the deployment's tolerated staleness
([I-D.draft-mcguinness-oauth-mission-status]), gives a quantified
cutoff, revocation within one token lifetime, with no Resource
Server changes and no status traffic; expiry is a state check
performed by the clock. Revocation latency is a number, not a
level: what the higher levels add is per-action enforcement,
parameter binding, and evidence, not a faster clock.
Under a binding without credential-carried authority (the
standalone MAS), Baseline grants governance and audit; no kill
switch of any kind exists until a freshness surface (the half-
step) and runtime enforcement (the next level) arrive, and a
deployment states that; the issuance join
([I-D.draft-mcguinness-oauth-mission-issuance-grant]) restores
gated issuance at each consuming Authorization Server, and
Baseline with it.
The nearest AAuth comparison, stated as capabilities rather than a
level: native approval, exact-byte commitment, active or
terminated state, and the ordered mission log. The possession-
independent issuance cutoff applies only to PS-asserted and
federated requests whose resource token carries the validated
Mission Reference; no Authority Set or subset proof is implied.
Proof obligations: the anchored approval and, where credentials
are issued, the subset rule. A deployment that adds only a
freshness surface, Mission Status or introspection with a
published staleness bound
([I-D.draft-mcguinness-oauth-mission-status]), gains state-aware
reliance, a revocation cutoff within that bound, without per-
action enforcement: a half-step into the next level, not a level
of its own.
A deployment demonstrates Baseline Issuance with the following
minimum test set, scoped by the capabilities its Mission Substrate
Statement claims, so a standalone MAS is never asked to prove a
credential behavior it does not claim. The executable realization
is planned in the family's conformance suite; no executable rows
exist yet.
Kernel, every Baseline deployment:
1. approval creates an active Mission;
2. an authenticated terminal transition takes effect in the
Controller's own subsequent decisions; and
3. the observed residual after a transition does not exceed the
published reliance bound.
Credential-Bound, where claimed:
1. no credential outlives the Mission's effective expiry; and
2. a credential from another Mission cannot be substituted (the
reference and its Controller namespace bind together).
Lifecycle-Gated Authorization, where claimed and limited to the
operations named in the claim:
1. an active Mission yields a positive result for a claimed
operation within policy;
2. a terminal transition prevents every claimed operation; and
3. for every lifecycle-gated operation in the claimed scope,
unavailable, invalid, stale, or unknown state prevents a
positive result (the forward-compatibility rule: only active
permits reliance, and lost state never fails open).
The OAuth binding additionally demonstrates:
1. refresh while the Mission is active succeeds within policy and
is refused after a terminal transition; and
2. a bare client-supplied Mission identifier creates no binding:
the grant, never the identifier, determines the Mission.
*Runtime-Enforced*: adds a PEP/PDP decision on every consequential
action, a trusted state source with a published staleness bound,
parameter binding, and runtime evidence
([I-D.draft-mcguinness-mission-runtime] and its AuthZEN binding).
Grants per-action enforcement and revocation bounded, for gated
classes, by the staleness bound plus the permit window plus the
class's execution bound, and by token lifetime for ungated paths.
This is the smallest deployment that turns a Mission from governed
issuance into action-time defense, and every normative dependency
it needs is ratified; it is a substantial build, not a wedge, and
a deployment sizes the effort from the runtime profile's
conformance section rather than from this level's one-line
summary.
Proof obligations: PEP-placement completeness and the declared
freshness source and bound. Documents: Baseline plus runtime, its
AuthZEN binding, and a freshness source.
*Governed Agent* (recommended for AI agents): adds Consent Evidence
and the harness, growing with Child Delegation, Expansion,
Orchestration, and Discovery (experimental, with Progressive) as
needed. Grants consent-rendering evidence and session-continuity
discipline. Documents: Runtime-Enforced plus consent-evidence and
the harness.
*High-Assurance Agent*: adds the guarantees that resist a
compromised agent. Two named claims live at this level, each with
proof obligations the runtime profile fixes.
*Agent-compromise-resistant enforcement*: mediated (gateway)
credential custody, a declared-and-audited path scope, action-
bound approval for the high-consequence classes, an active-
freshness state source, and approval disclosures rendered by a
component isolated from the agent, so a compromised agent cannot
unilaterally take a high-consequence action for which it does not
hold a mediated credential.
*Trifecta containment*: least exposure, the harness taint rule
enforced as a mandatory requirement of the harness profile, with
pre-consented egress to Approver-named destinations as its one
carve-out, and full mediation of the external-communication and
external-commitment classes with the egress-channel enumeration,
so an injected agent cannot egress on the strength of untrusted
content alone.
These are named high bars, never implied by basic adoption; a
deployment can bind its Enforcement Scope Statement to execution-
environment attestation so a claim is technical rather than
organizational ([I-D.draft-mcguinness-mission-runtime],
[I-D.draft-mcguinness-mission-harness]).
Read as an adoption ladder, each level makes a broader class of agent
work defensible to grant. The mapping is informative: the action
classes are the runtime profile's
([I-D.draft-mcguinness-mission-runtime]), resource policy remains
authoritative for its own objects, and what a level grants varies
with the binding; the Mission Deployment Profile (Section 14) is
where a deployment states its own mediated_action_classes and
exclusions.
+==================+===========================================+
| Level | What a deployment can defensibly grant |
+==================+===========================================+
| Baseline | Consequential reads that are attributable |
| Issuance | and killable at the issuance gate: the |
| | governed pilot |
+------------------+-------------------------------------------+
| Runtime-Enforced | Consequential writes inside approved |
| | bounds, reversible under the deployment's |
| | own authority |
+------------------+-------------------------------------------+
| Governed Agent | Unattended operation and delegation, with |
| | approval evidence behind every grant |
+------------------+-------------------------------------------+
| High-Assurance | The high-consequence classes |
| Agent | ([I-D.draft-mcguinness-mission-runtime]), |
| | under mediated custody and action-bound |
| | approval |
+------------------+-------------------------------------------+
Table 8
Every level above Baseline Issuance also carries the cross-cutting
obligations its mechanisms imply:
* operation-profile normalization where duration or parameter
digests are metered ([I-D.draft-mcguinness-mission-metering],
[I-D.draft-mcguinness-mission-authzen]);
* evidence retention for the audit horizon; and
* a registration schedule where audit transparency is run
([I-D.draft-mcguinness-mission-audit]).
The evidence levels are accountability, not prevention: they make
what was recorded tamper-evident, not what was perceived true or what
was never recorded present.
13.1. Composed Kill-Switch Reality
"Baseline" and "Runtime-Enforced" name two different things that
share spelling. Above, they name a level a deployment adopts. The
containment profile uses the same two words for a property a consumer
obtains per action class
([I-D.draft-mcguinness-oauth-mission-containment],
Section "Containment Properties"). The two are not 1:1: a Runtime-
Enforced deployment can still provide only the Baseline property for
a class its Enforcement Scope Statement leaves lifecycle-gated-only,
because the property requires a state-observable substrate per class,
not per deployment ([I-D.draft-mcguinness-mission-runtime]). The
table below names the property in its own column, apart from the
rung; a row can carry a Runtime-Enforced rung and a Baseline property
together without contradiction.
The table composes a deployment that runs the containment profile
with a rung and a binding. A rung and a binding alone confer neither
containment property: containment is an overlay a deployment
separately adopts ([I-D.draft-mcguinness-oauth-mission-containment]).
"Stops at commit" names what a contain transition's own state-version
commit reaches immediately
([I-D.draft-mcguinness-oauth-mission-containment], Section "The
Contain Transition"); "runs to its own bound" names the residual the
transition does not reach. Every cell is informative and carries no
RFC 2119 language of its own; the cited normative profile controls
wherever a cell and its citation appear to differ.
+========+============+=====================================================+==================================================+=====================================================+
|Rung |Binding |Property |Stops at commit |Runs to its own bound |
+========+============+=====================================================+==================================================+=====================================================+
|Baseline|OAuth |Baseline, a new-derivation kill |New derivation, delegation, cross-domain |Tokens already issued, to exp; a cross-domain |
|Issuance|binding, |([I-D.draft-mcguinness-oauth-mission-containment], |projection, and offline attenuation roots minted |projection grant already redeemed and an offline |
| |structured- |Section "Containment Properties") |after the transition |attenuation root already minted before the |
| |authority | |([I-D.draft-mcguinness-oauth-mission-containment],|transition, each to its own lifetime or del_max_depth|
| | | |Section "Derivation Gating") |([I-D.draft-mcguinness-oauth-mission-containment], |
| | | | |Section "The Materialized-Capability Residual"); a |
| | | | |consequential read under the token-lifetime default, |
| | | | |the same bound |
| | | | |([I-D.draft-mcguinness-mission-runtime]) |
+--------+------------+-----------------------------------------------------+--------------------------------------------------+-----------------------------------------------------+
|Baseline|Standalone |Neither; the runtime layer is the only cutoff, and it|Nothing at the resource; the transition commits |Every action, to whatever native credential, session,|
|Issuance|MAS, no |is absent at this rung |and is visible on the Mission Status Response and |or resource-local bound the resource enforces on its |
| |credential- | |the introspection projection |own, if any, until a freshness half-step arrives or |
| |carried | |([I-D.draft-mcguinness-oauth-mission-containment],|the issuance join restores a gate |
| |authority | |Section "Visibility") |([I-D.draft-mcguinness-oauth-mission-issuance-grant])|
+--------+------------+-----------------------------------------------------+--------------------------------------------------+-----------------------------------------------------+
|Runtime-|Any binding,|Runtime-Enforced for that class |The contained capability, denied at the class's |Ungated paths, bounded by token lifetime alone |
|Enforced|a class |([I-D.draft-mcguinness-oauth-mission-containment], |next gated action once the source reflects the | |
| |using a |Section "Containment Properties"): full Status or |overlay, within the staleness bound plus the | |
| |containment-|introspection carrying containment_version, or |permit window plus the class's execution bound | |
| |aware state |Signals carrying the overlay change; a fresh |([I-D.draft-mcguinness-mission-runtime]) | |
| |source |derivation narrows what it mints and can shorten the | | |
| |within its |residual, but it checks nothing at action time, so it| | |
| |published |carries Baseline, not Runtime-Enforced | | |
| |bound |([I-D.draft-mcguinness-oauth-mission-containment], | | |
| | |Section "Containment Properties"); a class checked | | |
| | |only against an active-but-not-containment-aware | | |
| | |source, gated only by fresh derivation, or left | | |
| | |lifecycle-gated-only, gets Baseline only regardless | | |
| | |of rung ([I-D.draft-mcguinness-mission-runtime]) | | |
+--------+------------+-----------------------------------------------------+--------------------------------------------------+-----------------------------------------------------+
|Baseline|MAS as |Baseline, from Derivation Gating at the Mission |New grant minting only: the Mission Issuer's |An outstanding grant redeems once, to its own maximum|
|Issuance|estate |Issuer |Derivation Gating evaluates the Effective |lifetime of 300 seconds, at any consuming AS whose |
| |control |([I-D.draft-mcguinness-oauth-mission-containment], |Authority Set, so a grant minted after the |redemption check is active-only rather than |
| |plane, |Section "Derivation Gating"); the consuming AS's |transition excludes contained authority |containment-aware |
| |issuance |redemption and refresh checks are the issuance |([I-D.draft-mcguinness-oauth-mission-containment],|([I-D.draft-mcguinness-oauth-mission-issuance-grant],|
| |join at each|profile's ordinary active gate, not containment-aware|Section "Derivation Gating") |Section "Redemption") |
| |consuming AS|on their own, since a contained Mission stays active,| | |
| | |unless the consuming AS separately retrieves and | | |
| | |applies the containment overlay or current Effective | | |
| | |Authority Set | | |
| | |([I-D.draft-mcguinness-oauth-mission-issuance-grant],| | |
| | |Section "Redemption") | | |
+--------+------------+-----------------------------------------------------+--------------------------------------------------+-----------------------------------------------------+
Table 9
None of this closes the conforming Baseline residual on a path or for
a class no containment-aware action-time gate reaches. For a class a
Runtime-Enforced action-time gate reaches instead, a pre-transition
credential does not run to its own bound at all. The binding
determines the artifact and its cutoff where the residual does
persist: an ungated standalone-MAS path, for instance, runs to
whatever native credential, session, or resource-local bound the
resource enforces on its own, if any, or to none, not to a token
lifetime. What changes row to row is which gate, if any, reaches a
class before its own bound, and how tight that bound is.
13.2. Assurance Claims
The levels are the adoption ladder: what a deployment has built, in
the order deployments build it. What a deployment can prove is an
orthogonal axis, claimed as named *assurance claims*, each with a
proof obligation an existing profile fixes, and listed in the
Deployment Profile (Section 14) rather than implied by a level:
* *Approved-record integrity*: the anchors reproduce from the record
alone (the OAuth binding's integrity anchors).
* *Bounded revocation latency*: the published staleness bound plus
the permit window and the class's execution bound
([I-D.draft-mcguinness-mission-runtime]).
* *Action-time enforcement*: PEP coverage for the Enforcement Scope
Statement's mediated set, and nothing outside it.
* *Parameter-bound enforcement*: permits bound to concrete
parameters for the classes claimed.
* *Transaction-grade execution*: the runtime profile's transaction-
assurance tier machinery (single-use permits, leases, outcome
reconciliation) for the classes claimed
([I-D.draft-mcguinness-mission-runtime]).
* *Compromise-resistant custody* and *trifecta containment*: the two
named High-Assurance claims, unchanged (Section 13).
Two deployments at the same level under different bindings can hold
different claims; the MAS modes are the worked case
([I-D.draft-mcguinness-mission-authority-server]). The claims, not
the level, are what a relying party compares.
13.3. Mission Binding Properties
Whether an operation is bound to a Mission is not one question but
three independent ones: who selected and attached the Mission to this
work item (attachment provenance), whether the acting credential's
authority was issued and bounded for the Mission (credential
binding), and whether one authenticated permit covers these exact
operation inputs (action binding). The dimensions are independent: a
native Mission-bound token has strong credential binding with no
harness in sight, a trusted harness attributes work items precisely
while the credential is an ordinary bearer token, and an action-bound
permit can exist over either. No single ladder orders them, so the
family names the properties directly, as a vector, and a deployment
claims the combination each path actually has.
+===========+=============+==================================================+
|Property |Meaning |Minimum proof |
+===========+=============+==================================================+
|mission- |A Mission |The canonical (issuer, mission id) pair; grants |
|reference- |tuple was |nothing and makes no security claim |
|selected |supplied for | |
| |routing and | |
| |selection | |
+-----------+-------------+--------------------------------------------------+
|work-item- |A trusted |An authenticated attacher, a tamper-resistant |
|bound |component |work-item identifier, and stated inheritance and |
| |bound that |retry rules |
| |tuple to this| |
| |session, | |
| |queue, or | |
| |task item | |
+-----------+-------------+--------------------------------------------------+
|credential-|The presented|A mapping join or Mission Join Assertion |
|correlated |credential is|([I-D.draft-mcguinness-mission-authority-server]),|
| |correlated to|with its stated ceiling |
| |the Mission's| |
| |parties | |
+-----------+-------------+--------------------------------------------------+
|credential-|The |The six equivalence properties below |
|mission- |credential's | |
|bound |authority was| |
| |issued or | |
| |derived for | |
| |the Mission | |
+-----------+-------------+--------------------------------------------------+
|presenter- |The presenter|Issuance-time key targeting (cnf or an equivalent |
|key-bound |proves |confirmation) plus presentation-time proof of |
| |possession of|possession |
| |the key the | |
| |credential is| |
| |constrained | |
| |to | |
+-----------+-------------+--------------------------------------------------+
|instance- |The concrete |presenter-key-bound plus the instance requirements|
|bound |acting |below |
| |instance is | |
| |identified | |
| |and holds the| |
| |bound key | |
+-----------+-------------+--------------------------------------------------+
|action- |An |One of the two proof forms below |
|bound |authenticated| |
| |permit | |
| |authorizes | |
| |one | |
| |operation, | |
| |resource, and| |
| |input | |
| |projection | |
+-----------+-------------+--------------------------------------------------+
Table 10: Mission binding properties
The properties are claimed per covered Authorization Server,
resource, and action path, never as a product-wide maximum: a mixed
estate claims what each path has, and a weaker path never inherits a
stronger path's claim from the deployment's name. Where policy
requires a property on a path, its absence denies; nothing falls back
silently to a weaker binding.
*Credential-mission-bound* is defined by equivalence, not by one
artifact. For the covered path the credential establishes all of:
1. a trusted issuer authorized to issue for the Mission;
2. the canonical (mission.issuer, mission.id) pair and the recorded
authority_hash;
3. an issued authority projection no broader than the Mission's
Authority Set for the target audience;
4. the mapped subject, the requesting client_id, and actor or
delegation context where applicable;
5. bounded lifetime plus active-state issuance and refresh gates;
and
6. an auditable derivation link to the Mission authorization: an
Issuance Grant jti
([I-D.draft-mcguinness-oauth-mission-issuance-grant]), a native
issuance record ([I-D.draft-mcguinness-oauth-mission]), a cross-
domain projection's provenance
([I-D.draft-mcguinness-oauth-mission-cross-domain]), or an
equivalently specified artifact.
Sender constraint is deliberately not among them: issuance-time key
targeting and presentation-time proof are presenter-key-bound, a
separate property, so a path that needs possession requires the
composition rather than reading it into the equivalence. That is
also what the mechanisms support: the OAuth binding's tokens SHOULD
be sender-constrained and the generic Issuance Grant's cnf is
OPTIONAL, so native issuance, the Mission Issuance Grant, and a
conforming cross-domain exchange satisfy this one property, and
supply presenter-key-bound exactly where their confirmation binding
is actually in force. A Mission Join Assertion fails properties 3,
5, and 6 by design, which is what separates correlation from
issuance.
*Presenter-key-bound* is possession and nothing more: the credential
names a confirmation key at issuance, and the presenter proves
possession at use, with DPoP or mutual TLS. It does not identify
which concrete agent process or workload holds the key.
*Instance-bound* requires all of: an authenticated instance
identifier; a verified binding from that identity to the confirmation
key; current proof of possession; and no key sharing across
instances. End-to-end sender constraint alone establishes presenter-
key-bound, never this property.
*Action-bound* requires an authenticated permit binding the Mission,
the action and resource, and the normalized parameters or complete
request projection, under the permit's validity and use controls, in
one of two proof forms:
* *portable permit*: an audience-restricted, presenter- or sender-
bound artifact, verified where it is presented; the transaction
token of
[I-D.draft-mcguinness-oauth-mission-transaction-authorization] is
the family's discharge; or
* *channel-bound permit*: a permit bound to the mutually
authenticated requesting and executing parties and enforced on
that same channel, with request cache-key equality, its validity
window, and the applicable use controls; the runtime permit of the
AuthZEN binding ([I-D.draft-mcguinness-mission-authzen])
discharges it under exactly those conditions.
A parameter binding alone makes a response neither form, and an
evaluation identifier alone is a correlator, never the property: it
qualifies only where dereferencing it through an authenticated,
audience-bound, freshness- and use-controlled permit store yields one
of the two forms above, complete.
Deployments claim compositions, and a claimed composition requires
every member property:
* *harness-attributed*: work-item-bound, under the attacher and
inheritance rules the harness states
([I-D.draft-mcguinness-mission-harness]);
* *mission-credential-bound*: credential-mission-bound plus
presenter-key-bound, end to end; instance-bound strengthens the
claim where an instance identity exists and is verified; and
* *runtime-action-bound*: authoritative Mission establishment plus
action-bound.
A work-item-attribution composition is deliberately absent. work-
item-bound and action-bound holding together does not prove the
permitted action came from that work item: concurrent items under one
Mission still substitute. The composition becomes definable only
when a verified cross-link exists, the action permit or its
authenticated request context binding the same tamper-resistant work-
item identifier the harness recorded; no family carrier supplies that
today, so a deployment claims the two properties separately and
nothing more.
The mechanism mapping is conservative: a propagated Mission-Reference
is selection only; a mapping join is credential-correlated, with its
equivalence-class ambiguity; a Mission Join Assertion is a stronger,
token- and key-specific credential-correlated, still never issuance;
a trusted harness supplies work-item-bound where its attacher
requirements hold; a native or issuance-grant-derived token is
credential-mission-bound, and presenter-key-bound where its
confirmation binding is in force end to end; an authenticated client-
instance assertion with a verified key binding is what makes a path
instance-bound; a verified transaction token is the portable action-
bound form, and an AuthZEN runtime permit is the channel-bound form
under that binding's conditions.
The property names above are stable identifiers, and a claim is a
per-path declaration, not prose: each claimed property or composition
names the covered issuer, resource, and action-class paths. The
Enforcement Scope Statement carries the per-path declarations for the
enforcement-adjacent properties, and the Mission Deployment Profile
(Section 14) composes them; a binding's Statement declares what the
binding can supply, which is never itself a deployment claim. An
unknown property identifier, an undeclared path, or an unstated
property is not claimed, and a consumer treats it as not held;
nothing downgrades silently. Schema-level claim identifiers and
validation rules remain the Deployment Profile's own future work.
Binding properties and the assurance claims above compose rather than
repeat: a binding property says whose Mission a path's work and
credentials are bound to; an assurance claim says what the
deployment's enforcement proves. Credential-level and action-level
binding likewise compose rather than substitute.
14. The Mission Deployment Profile
The Mission Assurance Levels (Section 13) name what to deploy, and
the assurance claims (Section 13.2) name what may be proven; a claim
is only checkable if a deployment states, concretely, what it
enforces and what it leaves outside the boundary. The *Mission
Deployment Profile* is that system-level artifact: the published
composition of the per-layer statements the profiles themselves
demand (the runtime profile's Enforcement Scope Statement, the
harness environment statement, the MAS mapping contract, the Resource
Server coverage split, the transparency-service topology and
schedule, and the progressive profile's bounds and ceiling-review
cadence, each where its profile is run), composed into one object an
auditor, a procurement, or a security review can read. It is one
artifact, not a second one: each fact's owning profile governs its
meaning and normative force, and this document fixes no
serialization. A machine-readable manifest schema, with stable claim
identifiers and validation rules, is deferred family work; until it
exists, the shape below is illustrative and the per-profile
statements are the checkable form.
Its distinguishing field is residual_risks: the profile is not
credible unless it states, in the same object as its guarantees, what
it does not cover. An illustrative shape:
{
"profile": "mission-governed-agent-runtime",
"assurance_level": "high-assurance-agent",
"mission_issuer": "https://as.example.com",
"state_sources": [
{ "type": "status_endpoint", "max_staleness_seconds": 30 }
],
"issuance": {
"binding": "oauth-core",
"mission_claim_required": true,
"refresh_gated_on_active_state": true
},
"runtime": {
"pdp": "authzen",
"pep_locations": ["tool-gateway", "browser-action-proxy"],
"mediated_action_classes": [
"irreversible_action", "external_commitment",
"external_communication", "privileged_administration"
],
"action_bound_approval_classes": [
"irreversible_action", "privileged_administration"
],
"unmediated_exclusions": [
"internal_reasoning", "local_cache_read"
]
},
"credential_custody": {
"held_by": "pep",
"sender_constrained": true,
"key_generated_in_pep": true,
"agent_receives_bearer_token": false
},
"key_custody": [
{
"key_class": "issuer_signing",
"artifact_classes": ["mission_tokens"],
"kid_selector": "issuer-token-2026",
"holder": "hsm_or_kms",
"exportable": false,
"generation": "dual_controlled",
"signing_use_controls": "online_token_signing",
"compromise_recovery_ref": "https://ops.example.com/procedures/issuer-key-compromise"
},
{
"key_class": "issuer_signing",
"artifact_classes": ["registered_evidence", "portable_artifacts"],
"kid_selector": "issuer-evidence-2026",
"holder": "hsm_or_kms",
"exportable": false,
"generation": "dual_controlled",
"signing_use_controls": "low_volume_high_value_signing",
"compromise_recovery_ref": "https://ops.example.com/procedures/issuer-key-compromise"
},
{
"key_class": "mediating_pep_custody",
"artifact_classes": ["sender_constraint_proof"],
"kid_selector": "pep-dpop-2026",
"holder": "software",
"exportable": false,
"generation": "generated_in_pep",
"signing_use_controls": "per_session_sender_constraint",
"compromise_recovery_ref": "https://ops.example.com/procedures/pep-key-rotation",
"attestation_ref": "https://attest.example.com/pep/2026"
}
],
"approval_rendering": {
"rendered_by": "agent-isolated-component"
},
"harness": {
"subagent_inheritance": "explicit_delegation_only",
"resume_requires_active_state": true,
"cached_credentials_revalidated": true,
"secondary_egress_enumerated": true
},
"exposure": {
"taint_rule": "enforced",
"egress_channels_enumerated": true
},
"standing_charters": {
"ceiling_review_cadence_days": 90,
"per_drawdown_bound": "single_entry_delta",
"drawdown_rate_bound_per_chain_per_hour": 60
},
"resource_servers": {
"authorization_details_enforcing": ["https://erp.example.com"],
"scope_projection_only": ["https://mail.example.com"],
"constraint_enforcement_for_scope_only": "runtime_pep"
},
"evidence": {
"decision_evidence": true,
"execution_evidence": true,
"retention_days": 365,
"field_classification": "evidence-schema-v2",
"evidence_access_audited": true,
"erasure_policy": "erasure-records",
"transparency": {
"service_operator": "third_party",
"monitor": "sec-ops",
"registration_time_bound_seconds": 3600
}
},
"residual_risks": [
"unmediated local reasoning is outside enforcement",
"revocation latency up to 30 seconds",
"PEP compromise is not prevented",
"per-entry constraints reach scope-only resources only via the PEP",
"long-term memory and provider model context are not Mission-scoped exposure points"
]
}
The evidence member carries the deployment's evidence-handling
posture beside its guarantees: the field-classification scheme its
records use, whether access to Mission evidence is itself audited,
and the erasure policy that pairs retention with deletion
accountability ([I-D.draft-mcguinness-mission-audit]).
The key_custody member declares, as a list keyed by key and
application rather than one row per key class, the custody a
deployment states for each signing key it operates: the key class
(the five classes [I-D.draft-mcguinness-mission-security-model]
enumerates: issuer signing, evidence signing, agent sender-
constraint, mediating-PEP custody, attenuation roots), the artifact
classes or kid selector the entry covers (core recommends segmenting
issuer signing keys by artifact class under distinct kid values
within one jwks_uri, [I-D.draft-mcguinness-oauth-mission]), the
holder, whether the key is exportable, its generation and signing-use
controls, a reference to its documented compromise-recovery
procedure, and any attestation or verifier reference for that key.
software and hsm_or_kms are example holder values, a mechanism family
rather than an assurance grade; this document defines neither as a
normative custody-grade enum and fixes no validation rule for either.
key_custody makes the trusted-base key-custody statement
[I-D.draft-mcguinness-mission-security-model] already requires
legible in the Deployment Profile; it does not make that statement
checked. Custody assurance stays open until a normative reader or
verifier for this declaration exists.
Two deployments that both "support Mission" but publish different
Deployment Profiles provide different security properties, and the
profile is what makes that difference legible. A deployment claiming
a level (Section 13) states it here and lists the residuals that
level leaves.
15. Prevention, Detection, and Residue
Each layer earns a specific property and leaves a specific residue.
Stated as a table so a claim cannot be read as more than it is:
+==============+=====================+============+==============+
| Mechanism | Prevents | Detects | Does not |
| | | | solve |
+==============+=====================+============+==============+
| Core | over-issuance | the | action-time |
| issuance | beyond the approved | approved | misuse |
| | authority; issuance | authority | within scope |
| | after revocation or | (anchored) | |
| | expiry | | |
+--------------+---------------------+------------+--------------+
| Runtime | an unauthorized | each PDP/ | actions on |
| enforcement | action on a | PEP | an |
| | mediated path | decision | unmediated |
| | | (evidence) | path |
+--------------+---------------------+------------+--------------+
| Consent | silent divergence | the | whether a |
| Evidence | between what was | rendered | human |
| | shown and what was | disclosure | perceived or |
| | committed | | understood |
| | | | it |
+--------------+---------------------+------------+--------------+
| Audit | undetectable log | the | a producer |
| Transparency | tampering or | evidence | logging a |
| | omission (under | timeline | false record |
| | expected | | |
| | registration) | | |
+--------------+---------------------+------------+--------------+
| Mandate | reliance on | portable | authority |
| | unverifiable | Mission | (it grants |
| | committed facts | facts | none) |
+--------------+---------------------+------------+--------------+
Table 11
The pattern is uniform: the family commits and checks what a party
was shown, decided, or did; it does not make the human attentive, the
producer honest, or the unmediated path disappear. Those are the
residues the Mission Assurance Levels (Section 13) and the security
model make a deployment state rather than assume, and the exposure
arm (Section 4.1) carries the same honesty in the other direction.
15.1. The Containment Matrix
Mission termination is one control in a larger containment surface.
Each kill has a different blast radius, and an incident responder
needs the whole matrix:
+==========+=============+=======================================================+
|Control |Stops |Home |
+==========+=============+=======================================================+
|Capability|one |the issuer-held containment overlay |
|kill |capability |([I-D.draft-mcguinness-oauth-mission-containment]) |
| |within one | |
| |Mission, with| |
| |the body of | |
| |work still | |
| |running | |
+----------+-------------+-------------------------------------------------------+
|Mission |one body of |the OAuth binding's revocation; cascades to Child |
|kill |work: new |Missions |
| |derivation at|([I-D.draft-mcguinness-oauth-mission-child-delegation])|
| |once, and | |
| |residual | |
| |credentials | |
| |at the | |
| |earliest of | |
| |revocation, | |
| |re-check, or | |
| |their own | |
| |expiry | |
| |(Section | |
| |10.5) | |
+----------+-------------+-------------------------------------------------------+
|Agent kill|all work by |the deployment's agent IAM (Section 9.2) |
| |one agent, | |
| |across its | |
| |Missions | |
+----------+-------------+-------------------------------------------------------+
|Agent |every |the deployment's change governance (Section 9.2) |
|Deployment|instance | |
|kill |running a | |
| |compromised | |
| |version | |
+----------+-------------+-------------------------------------------------------+
|Credential|credentials |the binding's substrate, where it supports revocation; |
|kill |already |otherwise expiry (Section 10.5) |
| |issued | |
+----------+-------------+-------------------------------------------------------+
|Workload |the running |the platform |
|kill |compute | |
| |itself | |
+----------+-------------+-------------------------------------------------------+
|Egress |the |gateway and network controls |
|kill |communication| |
| |path | |
+----------+-------------+-------------------------------------------------------+
Table 12
Mission termination participates in incident response; it does not
replace it. Revoking the Mission stops issuance at once and stops
mediated actions within the staleness bound (Section 10.5), but it
terminates no process and closes no network path. The converse holds
too: killing a workload leaves the Mission active and its authority
derivable to a replacement instance unless the Mission is also
revoked. Capability kill claims one of two properties, and which one
tracks the deployment's assurance level
([I-D.draft-mcguinness-oauth-mission-containment]): at Baseline
Issuance, a new-derivation kill, gating derivations minted after the
transition and propagating to Child Missions justified by the
contained entry, while a cross-domain grant already redeemed or an
offline attenuation root already minted before the transition keeps
its own bounded lifetime, exactly as the credential-kill row's
residual does; at Runtime-Enforced and above, an action-time kill
that additionally reaches a token issued before the transition,
bounded by the state source's staleness plus the permit and execution
windows. A deployment's incident runbook names which of these
controls exist, who may pull each, and which capability-kill property
its own assurance level claims.
16. Mission Requirements
The requirements the family answers are stated implementation-
neutrally; each names its answering documents by short form
(Section 17). They stand on their own as a checklist, but
conformance is capability- layered rather than measured by
resemblance to the OAuth wire model
([I-D.draft-mcguinness-mission-substrate]).
A design provides the shared *Mission Context* capabilities when the
first four properties, a compact restatement of the substrate
contract's kernel ([I-D.draft-mcguinness-mission-substrate]), hold:
1. *An approved task context*: the task is durable and explicitly
approved rather than only a session or token.
2. *Stable binding and integrity*: a native reference binds the
controlling authority, acting actor, and immutable approved
context, or a verifiable commitment to that context, and
propagation or correlation rules carry the reference across
parties without conferring authority.
3. *Lifecycle gate with a reliance bound*: only an active context
supports new governed decisions at the binding's declared control
point, and no decision or artifact outlives both its stated bound
and the transition that ends the context.
4. *Governance history*: decisions and interactions are correlated
to the stable reference in an ordered audit or governance record.
A design additionally provides *structured-authority* capabilities
when two more properties hold:
1. *Deterministic authority representation*: credentials or
decisions carry authority that an identified enforcement point
can evaluate.
2. *Monotonic derivation*: derived and delegated authority only
narrows, and widening requires a fresh approval or a drawdown
already bounded by an approved ceiling.
A design provides *Runtime-Enforced Mission* capabilities when two
further properties hold:
1. *Per-action runtime enforcement*: consequential actions are
checkable against the object at the point of use.
2. *Evidence that joins*: what was approved, shown, decided, and
done is reconstructible from evidence joined on the object's
identity.
AAuth supplies the first four natively (its expires_at member carries
the reliance bound), with its lifecycle gate scoped to PS endpoints
and PS-mediated paths carrying the validated reference. The OAuth
binding supplies the structured-authority layer as well. Runtime and
portable evidence remain separately claimed capabilities; the
requirements below unpack the family mechanisms without implying
every binding implements every one.
16.1. Context and Intent
* *R1*: The task an agent pursues is a durable, structured, approved
object (oauth-mission; mission-authority-server).
* *R2*: The task and its derived authority are integrity-committed
at approval, reproducible from the record alone (oauth-mission).
* *R3*: Task proposals are untrusted input: fields the agent can
influence never derive, widen, or gate authority (oauth-mission;
mission-shaping).
16.2. Consent and Approval
* *R4*: The derived authority is disclosed to the Approver before it
takes effect, and the approval covers it (oauth-mission).
* *R5*: A single accountable Approver is recorded immutably on the
object (oauth-mission).
* *R6*: What was shown at approval is committed and reconstructible
by an auditor (oauth-mission-consent-evidence).
* *R7*: Approval can be asynchronous, and any in-review negotiation
only narrows (oauth-mission-approval; the experimental oauth-
mission-approval-revision).
16.3. Lifecycle
* *R8*: Reliance is gated on task state: only active permits it, and
unrecognized states fail safe (oauth-mission).
* *R9*: Revocation is independent of credential possession, and
state changes propagate by pull or push (oauth-mission; oauth-
mission-status; oauth-mission-signals).
* *R10*: A task can be suspended and resumed without being
terminated (oauth-mission-status).
* *R11*: Authority widens only through a fresh approval that creates
a successor (oauth-mission-expansion).
* *R12*: Authority retires per entry when the work an entry served
is done (oauth-mission-status).
16.4. Delegated, Projected, and Enforced Execution
* *R13*: Derived and delegated authority only narrows (oauth-
mission; oauth-mission-attenuation).
* *R14*: Sub-agents receive authority by explicit delegation with
lineage, fan-out control, and cascade revocation, never by session
ancestry (oauth-mission-child-delegation).
* *R15*: Each consequential action is checked at the point of use,
the permit bound to the concrete parameters (mission-runtime;
mission-authzen).
* *R16*: When a task stops, governed work stops with it and in-
flight work unwinds safely (mission-harness; mission-
orchestration).
* *R17*: Task evidence is tamper-evident and verifiable outside the
deployment (mission-audit; mission-mandate).
* *R18*: A Mission's committed facts and authority are honorable in
another trust domain without widening, and verification needs no
session with the issuer (oauth-mission-cross-domain; mission-
mandate).
* *R19*: Delegation history follows authorization continuity, never
organizational topology. A Child Mission, an Expansion successor,
or any fresh approval starts a new approval basis and actor chain;
topology alone neither restarts nor extends one. Representation
is profile-specific: issuer-mediated delegation nests act; holder-
mediated attenuation reconstructs history from per-hop actors; and
cross-domain projection carries no upstream act chain, so any
destination-domain chain begins locally. Actor identity is
attribution and policy input; it does not itself grant or prove
authority (oauth-mission; oauth-mission-child-delegation; oauth-
mission-expansion; oauth-mission-attenuation; oauth-mission-cross-
domain).
17. Mission Document Map
One row per document, grouped as the family groups them; the short
form drops the draft-mcguinness- prefix, and the repository's
DRAFTS.md is the full catalog with maturity and adoption metadata.
The naming encodes a boundary: profiles extending the Authorization
Server's own surfaces keep "oauth" in their names; profiles defined
against the substrate of Section 10 are named without it. This
document is named without it because the architecture is substrate-
neutral by construction.
Maturity is a dependency boundary. A Standards-Track profile never
depends normatively on an experimental one: the experimental profiles
extend the stable interface only through its declared seams, the
controls extension of the OAuth binding and the coordinated-extension
rules of the evidence objects, and a Standards-Track document cites
them informatively at most. An experimental profile that stabilizes
crosses the boundary by reclassification, not by a stable document
absorbing a dependency.
Within Lifecycle, Status is the OAuth lifecycle suite's root
document, with Signals (the push channel) and Management (the
operator plane) as its satellites; AAuth keeps its native two-state
lifecycle, served by mission-aauth-management, with the expiry bound
profiled by aauth-mission-expiry.
*Architecture mappings:*
+=============+================================================+
| Document | Role |
+=============+================================================+
| mission-aam | Experimental sketch. Cloudflare's Agent |
| | Access Model realized on the family: the six |
| | AAM components map onto issuance, the PDP, the |
| | mediated harness, Containment, Mission |
| | Templates, and the evidence join, and the |
| | grant review loop is deliberately not adopted. |
| | It defines no binding and no new mechanism. |
+-------------+------------------------------------------------+
Table 13
*The substrate and the bindings:*
+==============================+====================================+
| Document | Role |
+==============================+====================================+
| oauth-mission | The OAuth binding, its OAuth |
| | companions' issuance profile: |
| | the OAuth realization of the |
| | Mission, the approval event |
| | and anchors, the mission |
| | claim, the subset rule, state- |
| | gated issuance. |
+------------------------------+------------------------------------+
| mission-authority-server | The standalone Mission Issuer |
| | and the PDP join of ordinary |
| | credentials to Missions. |
+------------------------------+------------------------------------+
| oauth-mission-issuance-grant | The issuance join: MAS-minted |
| | grants an estate Authorization |
| | Server redeems at its token |
| | endpoint for Mission-bound, |
| | state-gated tokens. |
+------------------------------+------------------------------------+
| mission-aauth | The AAuth Mission Context |
| | binding: the Person Server as |
| | controlling authority, the |
| | exact-byte mission blob under |
| | AAuth's s256 commitment, |
| | native {approver, s256} |
| | propagation, and active-state |
| | gating on PS endpoints and the |
| | PS-asserted and federated |
| | paths. It defines no OAuth |
| | Authority Set or additional |
| | AAuth wire members. |
+------------------------------+------------------------------------+
| mission-uma | Experimental sketch. The UMA |
| | 2.0 binding: the pushed |
| | Mission Intent rides claims |
| | pushing, the resource owner's |
| | decision fills UMA's |
| | authorization assessment, the |
| | RPT is the Mission-bound |
| | credential, and the PCT is |
| | continuity that is never |
| | authority; the first binding |
| | authored against the substrate |
| | contract. |
+------------------------------+------------------------------------+
| mission-gnap | Experimental sketch. The GNAP |
| | binding: the Mission Intent |
| | rides a registered grant |
| | request member, interaction or |
| | a companion-supplied standing |
| | basis is the approval event, |
| | grant modification splits into |
| | in-Mission drawdown and |
| | Approver-routed expansion, and |
| | the continuation access token |
| | is continuity that is never |
| | authority; the second binding |
| | authored against the substrate |
| | contract. |
+------------------------------+------------------------------------+
| mission-substrate | The binding-neutral kernel |
| | contract: normative on any |
| | further binding, conformed to |
| | by the existing bindings |
| | through their published |
| | Substrate Statements, with |
| | vocabulary ownership migrating |
| | to it by touch. |
+------------------------------+------------------------------------+
Table 14
*Approval time:*
+=================================+=================================+
| Document | Role |
+=================================+=================================+
| mission-shaping | Client-side shaping of a |
| | user's request into a |
| | candidate Mission Intent, as |
| | untrusted proposal. |
+---------------------------------+---------------------------------+
| oauth-mission-consent-evidence | The consent_rendering_hash |
| | anchor and signed evidence of |
| | what the Approver was shown, |
| | with the translation floor and |
| | Disclosure Interrogation that |
| | keep the approval surface |
| | readable and questionable. |
+---------------------------------+---------------------------------+
| oauth-mission-approval | Asynchronous approval over the |
| | deferred substrate. |
+---------------------------------+---------------------------------+
| mission-approval-governance | The Approval Governance |
| | Record: authenticated, event- |
| | bound, policy-authorized |
| | assertions standing behind an |
| | approval decision, committed |
| | atomically with Mission |
| | activation and immutable once |
| | signed. |
+---------------------------------+---------------------------------+
| oauth-mission-approval-revision | Experimental: in-review |
| | narrowing revision of a |
| | deferred proposal. |
+---------------------------------+---------------------------------+
| oauth-mission-template | Experimental: one consent to a |
| | task template's ceiling; each |
| | dispatch instantiates an |
| | ordinary Mission from it by |
| | policy, at machine speed, |
| | bounded by its own derived |
| | Authority Set and never |
| | exceeding the ceiling. |
+---------------------------------+---------------------------------+
Table 15
*Lifecycle:*
+===========================+======================================+
| Document | Role |
+===========================+======================================+
| oauth-mission-status | The signed pull surface and the |
| | lifecycle endpoint, with suspended |
| | and completed, and per-entry |
| | discharge via the terminal_when |
| | constraint. |
+---------------------------+--------------------------------------+
| oauth-mission-signals | A signed event per lifecycle |
| | transition, push or poll. |
+---------------------------+--------------------------------------+
| oauth-mission-expansion | Widening through an approved |
| | successor Mission. |
+---------------------------+--------------------------------------+
| oauth-mission-containment | Event-triggered, monotonic narrowing |
| | of a live Mission's effective |
| | authority, with restoration only |
| | through an approved successor. |
+---------------------------+--------------------------------------+
| oauth-mission-progressive | Experimental: policy-adjudicated |
| | expansion within a pre-consented |
| | ceiling. |
+---------------------------+--------------------------------------+
| mission-discovery | Experimental: the open-world |
| | encounter as a governed operation: |
| | identity pinning, ceiling and |
| | contextual adjudication with the |
| | lying-resource and tainted-session |
| | floors, Discovery Evidence. |
+---------------------------+--------------------------------------+
| oauth-mission-management | Fleet enumeration and bulk lifecycle |
| | operations for operators and |
| | incident response; dry-run-first, |
| | per-Mission semantics. |
+---------------------------+--------------------------------------+
| mission-aauth-management | AAuth-native status, permanent |
| | termination, optional expiry, and |
| | delegation-tree queries at the |
| | Person Server, keyed only by |
| | {approver, s256} and preserving |
| | AAuth's active and terminated |
| | states. |
+---------------------------+--------------------------------------+
| aauth-mission-expiry | Profile of AAuth's expires_at |
| | mission lifetime bound (RFC 3339 |
| | precision, skew documentation, |
| | prompt termination). The base |
| | protocol enforces the bound on every |
| | Person Server decision path and caps |
| | every token carrying mission_s256; |
| | the AAuth binding requires the |
| | member on every mission. |
+---------------------------+--------------------------------------+
Table 16
*Cross-domain projection and continuity:*
+====================================+==============================+
| Document | Role |
+====================================+==============================+
| oauth-mission-cross-domain | Single-hop projection of |
| | a Mission to another |
| | trust domain via the |
| | cross-domain grant. |
+------------------------------------+------------------------------+
| oauth-mission-cross-org-delegation | Recursive cross- |
| | organizational delegation |
| | as a profile of offline |
| | attenuation: the chain is |
| | the portable authority |
| | proof, each hop names its |
| | own actor under the |
| | identity-binding rule, |
| | and projection turns a |
| | verified chain into a |
| | local token. |
+------------------------------------+------------------------------+
| oauth-mission-continuation | The authorization- |
| | continuity profile: a |
| | Mission continues its |
| | authorization over |
| | identity-continuity |
| | transports (Identity |
| | Continuation, async |
| | delegation, cross- |
| | domain), state-gated, |
| | with the invariant that a |
| | continuation handle |
| | grants nothing. |
+------------------------------------+------------------------------+
| oauth-id-continuation-assertion | A continuation transport: |
| | a short-lived token- |
| | exchange subject token |
| | yielding an ID-JAG for an |
| | intra-domain hop, bound |
| | to a Mission's |
| | authorization by mission- |
| | continuation. |
+------------------------------------+------------------------------+
Table 17
*Runtime enforcement:*
+=========================================+========================+
| Document | Role |
+=========================================+========================+
| mission-runtime | The per-action |
| | decision contract: |
| | parameter binding, |
| | custody, fail-closed |
| | behavior. |
+-----------------------------------------+------------------------+
| mission-authzen | The concrete decision- |
| | API binding: the |
| | AuthZEN request and |
| | response mapping and |
| | the denial |
| | classification. |
+-----------------------------------------+------------------------+
| mission-runtime-evidence | The binding-neutral |
| | Decision Evidence, |
| | Execution Evidence, |
| | and Refusal Record |
| | objects a decision-API |
| | binding's PDP and PEP |
| | emit, their integrity |
| | envelope, and |
| | retention. |
+-----------------------------------------+------------------------+
| mission-metering | Experimental: |
| | cumulative consumption |
| | bounds and the |
| | metering that enforces |
| | them. |
+-----------------------------------------+------------------------+
| oauth-mission-transaction-authorization | Experimental: the |
| | transaction |
| | authorization |
| | challenge profiled for |
| | the cross-domain case, |
| | minting a single-use |
| | action-bound token |
| | after a fresh decision |
| | with a governed |
| | approval as input. |
+-----------------------------------------+------------------------+
Table 18
*Agent runtime:*
+============================+===================================+
| Document | Role |
+============================+===================================+
| mission-harness | Binding sessions, queues, and |
| | sub-agent handles to Mission |
| | state; the mediated environment. |
+----------------------------+-----------------------------------+
| mission-capability-binding | Binds an approved catalog-sourced |
| | entry (an MCP tool, an OpenAPI |
| | operation) to its capability |
| | source at derivation and refuses |
| | on drift at decision time, with |
| | the AuthZEN MCP profile's (COAZ) |
| | mapping for MCP deployments. |
+----------------------------+-----------------------------------+
| mission-orchestration | Experimental: reversibility |
| | classes, unwind plans, and |
| | compensation after a stop. |
+----------------------------+-----------------------------------+
Table 19
*Sub-agents:*
+================================+================================+
| Document | Role |
+================================+================================+
| oauth-mission-child-delegation | Child Missions with lineage, |
| | strict-subset authority, |
| | cascade revocation. |
+--------------------------------+--------------------------------+
| oauth-mission-attenuation | Experimental: narrower |
| | Mission-bound tokens minted |
| | offline; the kill switch |
| | preserved by runtime re-check. |
+--------------------------------+--------------------------------+
Table 20
*Proof and portability:*
+=================+==============================================+
| Document | Role |
+=================+==============================================+
| mission-mandate | A signed, portable statement of a Mission's |
| | committed facts; evidence, not a credential. |
+-----------------+----------------------------------------------+
| mission-audit | Registration of Mission evidence in a SCITT |
| | Transparency Service; receipts verifiable |
| | offline. |
+-----------------+----------------------------------------------+
Table 21
*Security model:*
+=============================+=====================================+
| Document | Role |
+=============================+=====================================+
| oauth-mission-work-products | Experimental: work-product |
| | provenance, attribution and |
| | not authority, and the non- |
| | transitive Mission-to-Mission |
| | handoff rule; a work product |
| | crossing into a Mission is |
| | input, re-evaluated under the |
| | receiver's Authority Set. |
+-----------------------------+-------------------------------------+
| mission-security-model | The trusted base in one view: |
| | what each component must |
| | achieve and what its |
| | compromise costs. |
+-----------------------------+-------------------------------------+
Table 22
18. Security Considerations
This document introduces no mechanism and therefore no new security
considerations. The consolidated trusted base and compromise
analysis are the Mission Security Model's
([I-D.draft-mcguinness-mission-security-model]), and each profile's
own Security Considerations remain normative.
19. Privacy Considerations
The privacy properties of the Mission record and the Mission Intent
are the OAuth binding's ([I-D.draft-mcguinness-oauth-mission]) and
each adopted profile's; this document describes them and adds no data
element of its own. The OAuth binding's Privacy Considerations cover
Mission Identifier correlation, token payload disclosure, and Intent
retention, with the audit profile's erasure record as the
transparency-side mechanism ([I-D.draft-mcguinness-mission-audit]).
The status profile's anti-oracle property bounds what its status
surfaces disclose ([I-D.draft-mcguinness-oauth-mission-status]).
The AAuth binding's privacy posture is its own
([I-D.draft-mcguinness-mission-aauth]): the private mission blob
never leaves the agent and the Person Server, the stable {approver,
s256} reference is a correlation handle across every resource that
sees it, and the mission log concentrates a detailed activity history
at the Person Server, with the binding's minimization and retention
duties applying there.
20. IANA Considerations
This document makes no IANA request.
21. Informative References
[A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification,
Version 1.0", 2026,
.
[I-D.draft-ietf-oauth-attestation-based-client-auth]
Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0
Attestation-Based Client Authentication", Work in
Progress, Internet-Draft, draft-ietf-oauth-attestation-
based-client-auth-10, 6 July 2026,
.
[I-D.draft-ietf-oauth-spiffe-client-auth]
Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen,
S., and N. Cam-Winget, "OAuth SPIFFE Client
Authentication", Work in Progress, Internet-Draft, draft-
ietf-oauth-spiffe-client-auth-02, 15 June 2026,
.
[I-D.draft-mcguinness-aauth-mission-expiry]
McGuinness, K., "AAuth Mission Expiry", 2026,
.
[I-D.draft-mcguinness-mission-aauth]
McGuinness, K., "Mission Context Binding for AAuth", 2026,
.
[I-D.draft-mcguinness-mission-aauth-management]
McGuinness, K., "AAuth Mission Management", 2026,
.
[I-D.draft-mcguinness-mission-audit]
McGuinness, K., "Mission Audit Transparency", 2026,
.
[I-D.draft-mcguinness-mission-authority-server]
McGuinness, K., "Mission Authority Server", 2026,
.
[I-D.draft-mcguinness-mission-authzen]
McGuinness, K., "Mission-Bound Runtime Enforcement:
AuthZEN Profile", 2026, .
[I-D.draft-mcguinness-mission-capability-binding]
McGuinness, K., "Mission Capability Binding", 2026,
.
[I-D.draft-mcguinness-mission-discovery]
McGuinness, K., "Mission Open-World Discovery", 2026,
.
[I-D.draft-mcguinness-mission-gnap]
McGuinness, K., "Mission-Bound Authorization for GNAP",
2026, .
[I-D.draft-mcguinness-mission-harness]
McGuinness, K., "Mission-Aware Agent Harnesses", 2026,
.
[I-D.draft-mcguinness-mission-mandate]
McGuinness, K., "Mission Mandate", 2026,
.
[I-D.draft-mcguinness-mission-metering]
McGuinness, K., "Mission Consumption Metering", 2026,
.
[I-D.draft-mcguinness-mission-orchestration]
McGuinness, K., "Mission Orchestration and Unwinding",
2026, .
[I-D.draft-mcguinness-mission-runtime]
McGuinness, K., "Mission-Bound Runtime Enforcement", 2026,
.
[I-D.draft-mcguinness-mission-runtime-evidence]
McGuinness, K., "Mission Runtime Evidence", 2026,
.
[I-D.draft-mcguinness-mission-security-model]
McGuinness, K., "Mission Security Model", 2026,
.
[I-D.draft-mcguinness-mission-shaping]
McGuinness, K., "Mission Intent Shaping", 2026,
.
[I-D.draft-mcguinness-mission-substrate]
McGuinness, K., "Mission Substrate Requirements", 2026,
.
[I-D.draft-mcguinness-mission-uma]
McGuinness, K., "Mission-Bound Authorization for UMA 2.0",
2026, .
[I-D.draft-mcguinness-oauth-ai-agent-instance]
McGuinness, K., "OAuth 2.0 AI Agent Instance Profile",
Work in Progress, Internet-Draft, draft-mcguinness-oauth-
ai-agent-instance-00, 4 July 2026,
.
[I-D.draft-mcguinness-oauth-client-instance-assertion]
McGuinness, K., "OAuth 2.0 Client Instance Assertion",
Work in Progress, Internet-Draft, draft-mcguinness-oauth-
client-instance-assertion-01, 24 June 2026,
.
[I-D.draft-mcguinness-oauth-id-continuation-assertion]
McGuinness, K., "Identity Continuation Assertion for OAuth
2.0 Token Exchange", 2026,
.
[I-D.draft-mcguinness-oauth-mission]
McGuinness, K., "Mission-Bound Authorization for OAuth
2.0", 2026, .
[I-D.draft-mcguinness-oauth-mission-approval]
McGuinness, K., "Mission Deferred Approval for OAuth 2.0",
2026, .
[I-D.draft-mcguinness-oauth-mission-attenuation]
McGuinness, K., "Mission Offline Attenuation for OAuth
2.0", 2026, .
[I-D.draft-mcguinness-oauth-mission-child-delegation]
McGuinness, K., "Mission Child Delegation for OAuth 2.0",
2026, .
[I-D.draft-mcguinness-oauth-mission-consent-evidence]
McGuinness, K., "Mission Consent Evidence for OAuth 2.0",
2026, .
[I-D.draft-mcguinness-oauth-mission-containment]
McGuinness, K., "Mission Containment for OAuth 2.0", 2026,
.
[I-D.draft-mcguinness-oauth-mission-continuation]
McGuinness, K., "Mission Continuation: Authorization
Continuity for Mission-Bound Authorization", 2026,
.
[I-D.draft-mcguinness-oauth-mission-cross-domain]
McGuinness, K., "Mission Cross-Domain Projection for OAuth
2.0", 2026, .
[I-D.draft-mcguinness-oauth-mission-expansion]
McGuinness, K., "Mission Expansion for OAuth 2.0", 2026,
.
[I-D.draft-mcguinness-oauth-mission-issuance-grant]
McGuinness, K., "Mission Issuance Grant for OAuth 2.0",
2026, .
[I-D.draft-mcguinness-oauth-mission-management]
McGuinness, K., "Mission Management for OAuth 2.0", 2026,
.
[I-D.draft-mcguinness-oauth-mission-progressive]
McGuinness, K., "Mission Progressive Authorization for
OAuth 2.0", 2026, .
[I-D.draft-mcguinness-oauth-mission-signals]
McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0",
2026, .
[I-D.draft-mcguinness-oauth-mission-status]
McGuinness, K., "Mission Status and Lifecycle for OAuth
2.0", 2026, .
[I-D.draft-mcguinness-oauth-mission-transaction-authorization]
McGuinness, K., "Mission Transaction Authorization Profile
for OAuth 2.0", 2026, .
[I-D.draft-mcguinness-oauth-mission-work-products]
McGuinness, K., "Mission Work Products", 2026,
.
[I-D.draft-zehavi-oauth-rar-metadata]
Zehavi, Y., "OAuth 2.0 RAR Metadata and Error
Remediation", Work in Progress, Internet-Draft, draft-
zehavi-oauth-rar-metadata-06, 9 August 2026,
.
[I-D.draft-zhu-oauth-async-delegation]
Zhu, L. and Z. Berg, "Delegated Refresh Tokens for OAuth
2.0 Token Exchange", Work in Progress, Internet-Draft,
draft-zhu-oauth-async-delegation-05, 3 August 2026,
.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
.
[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
RFC 9126, DOI 10.17487/RFC9126, September 2021,
.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
.
Acknowledgments
This document is part of the Mission-Bound Authorization work and
maps the structure that its profiles establish individually.
Author's Address
Karl McGuinness
Independent
Email: public@karlmcguinness.com