An Architecture for 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 6 April 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

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 ([I-D.draft-hardt-oauth-aauth-protocol]), the Mission Context instead governs resource decisions at the Person Server (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 that deployments pay 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]). 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: each attaches to its own protocol as an equally adoptable unit and declares what it supplies, in a Mission Substrate Statement or, for the OAuth binding, an informative Mapping Assessment. What peer standing implies, and how the bindings differ, is stated once with the binding architectures (Section 10.5).¶

This document is Informational. It defines no protocol, mechanism, requirement, conformance class, or wire format. It does define descriptive vocabulary that other documents cite: the assurance levels and claims (Section 11) and the binding properties (Section 11.3), whose credential-mission-bound equivalence is what earns the Mission-bound token class (Section 10.2). Material marked illustrative (the worked composition, the Deployment Profile shapes, and the verification scenarios) shows one way to apply the model and fixes nothing. Every other passage summarizes rules owned by the documents it cites; where a summary and its owning profile appear to differ, the profile governs.¶

This document describes components, interfaces, and data flows; the Mission Security Model ([I-D.draft-mcguinness-mission-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.¶

2. 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. Binding-neutral Mission terms (the Mission Reference and Controller, the approved context, the approval event, the governance gate, bounded reliance, and the named substrate capabilities) are the substrate contract's ([I-D.draft-mcguinness-mission-substrate]). Terms of the OAuth realization (Mission Intent, Authority Set, integrity anchors, and Mission Issuer) are the OAuth binding's ([I-D.draft-mcguinness-oauth-mission]); a passage that uses them describes that realization or a binding that adopts it. No binding is the default reading of a passage that does not name one.¶

Policy Enforcement Point (PEP), Policy Decision Point (PDP), consequential action, the high-consequence classes, and the Enforcement Scope Statement are the runtime profile's ([I-D.draft-mcguinness-mission-runtime]). Effective Authority Set is the status profile's ([I-D.draft-mcguinness-oauth-mission-status]), and the transition classification, including decide_anew, is the substrate contract's ([I-D.draft-mcguinness-mission-substrate]). Mission Authority Server (MAS) is defined by [I-D.draft-mcguinness-mission-authority-server], and the AAuth binding by [I-D.draft-mcguinness-mission-aauth].¶

3. A Mission's Life

Under the OAuth binding, an operator gives an agent the task "reconcile Q3 invoices," and one Mission carries it end to end:¶

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-discharge]).¶

7. Stop. Revocation or expiry turns every gate: issuance refuses at once, the PDP denies within its state source's staleness bound, 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]); a token no state-aware gate reaches runs to its own expiry (Section 10.4).¶

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; there, revocation stops nothing at the token layer, and runtime enforcement is the only cutoff (Section 10.5). In sequence, the standalone mode runs submit, approve, poll, 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]).¶

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 10.5, Section 11).¶

4. The Mission

OAuth 2.0 standardizes authorization: an access token represents authorization granted to the client, for a delegating user or for the client's own behalf, and can serve many requests, and a deployment may retain durable grant or consent state behind it. What OAuth does not standardize is an independently addressable, lifecycle-bearing approved-task object: an artifact whose semantics persist across tokens, actors, audiences, and evidence.¶

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.¶

In every binding, an explicit approval event creates the Mission and commits its approved context, or a verifiable commitment to it, and the Mission's Controller then owns its state. In the OAuth binding, a client proposes a Mission Intent, and may propose concrete authority alongside it; the Mission Issuer derives an Authority Set; and the approval event commits both.¶

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 anchor is 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).¶

In the OAuth binding the lifecycle states are active, revoked, and expired, and only active permits issuance or a new positive governance decision. 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.4).¶

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).¶

In OAuth's names, authority then moves along one path from the approval event to an action, and no stage holds more than the stage before it:¶

 approval basis
       |
       | adjudication
       v
 approval event
       |
       v
 Approved Authority Set (anchored, immutable)
       |
       | containment, discharge: subtract only
       v
 Effective Authority Set --child creation--> new approval event
       |               |                     for a Child Mission
       | derivation:   |
       | subset rule   | current set
       v               |
 derived credential    |
       |               |
       v               v
 runtime decision, where deployed
 (with action parameters and lifecycle state)
       |
       v
 action

The lifecycle gate sits beside the path, not on it: only active permits issuance, refresh, and a new positive governance decision, and resume reopens a suspended Mission's gate without changing either set ([I-D.draft-mcguinness-oauth-mission-status]). Widening and restoration never happen in place; a new approval event creates a successor ([I-D.draft-mcguinness-oauth-mission-expansion]). The runtime decision takes the current Effective Authority Set as its own input, so narrowing applied after issuance binds there ([I-D.draft-mcguinness-mission-runtime]). Where no runtime decision is deployed, a resource relies on the credential alone, and the materialized-credential residual remains (Section 10.4). Table 2 places each mechanism on this path.¶

AAuth realizes the separation differently. Its exact-byte s256 commits the private approved mission blob. The approving PS and s256 are the Mission Reference, AAuth's mission identity (Section 8.2.1 of [I-D.draft-hardt-oauth-aauth-protocol]). The blob carries no member naming the PS: a person token names it by iss, a resource or auth token by ps, and a request by its destination. On the wire the reference is the mission_s256 claim or parameter. The PS applies contextual governance using that blob and the ordered mission log; scopes, resource tokens, Resource and Access Server policy, and optionally AAuth Rich Resource Requests (R3, [I-D.draft-hardt-aauth-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. In control-plane terms:¶

• 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.¶

Grouped as planes, the roles of Section 6 form this layer, with the evidence surface crossing all of them:¶

 control       Mission control point (OAuth AS | MAS | AAuth PS |
               UMA AS | GNAP AS):
               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

5. Non-Goals

The family does not define:¶

• A new grant protocol. Rich Authorization Requests [RFC9396] and kindred mechanisms already fill the authority-expression role; the family leaves the grant exchange to them and defines its own cross-resource authorization_details type only where [RFC9396] leaves type semantics to the type, in the OAuth binding's Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]). 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 6.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 9.2).¶

• 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. Mission Roles and Components

What each component's 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 with client instance identification, which extends attestation-based client authentication ([I-D.draft-ietf-oauth-attestation-based-client-auth]), and endorse its attesters in client metadata ([I-D.draft-mcguinness-oauth-client-instance-id], [I-D.draft-mcguinness-oauth-client-attesters]), sharpening joins and evidence attribution to instance granularity without touching the Mission model. Instance evidence alone identifies no actor or delegate ([I-D.draft-mcguinness-oauth-client-instance-id], Section 5); SPIFFE workload credentials ([I-D.draft-ietf-oauth-spiffe-client-auth]) on their own convey no instance identity under that profile ([I-D.draft-mcguinness-oauth-client-instance-id], Section 8.2); and none of these mechanisms defines 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 approver is always the PS, not a portable person identifier, and the blob carries no member naming it; 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]).¶

• GNAP authorization server (experimental sketch): the Mission Intent rides the grant request as a registered member, the interaction or a standing basis is the approval event, and access token issuance and rotation are gated on state ([I-D.draft-mcguinness-mission-gnap]).¶

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. In person identity the PS gates person-token issuance but does not decide at the resource; it gates PS authorization (three-party) and federated authorization (four-party). It does not gate agent identity or resource-managed access (Section 4.2 of [I-D.draft-hardt-oauth-aauth-protocol], [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| GNAP AS   | |
  | | Mission-  | MAS: no   | Mission   | (sketch): | (sketch): | |
  | | bound     | tokens;   | Context;  | pushed    | Intent in | |
  | | tokens    | the PDP   | PS paths  | Intent;   | request;  | |
  | | gated on  | joins to  | gated     | RPTs gated| tokens    | |
  | | state     | Mission   |           | on state  | gated     | |
  | +-----------+-----------+-----------+-----------+-----------+ |
  +-------|-----------|-----------|-----------|-----------|-------+
          v           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

7. 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, AAuth Person Server
              contextual-governance binding, UMA AS, or
              GNAP AS (+ 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 profile:
 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)

The family manifest records each verb's owning documents. The Packages column gives the product architect's view of the same system: five architecture packages a deployment builds, independent of how the drafts are cut for standardization. They are Mission Control; Authority Distribution, which includes the four Mission Issuer bindings (OAuth, the MAS, UMA, and GNAP); Runtime Enforcement; Agent Execution Governance; and Evidence and Accountability. A document can serve more than one package, and the document map (Appendix G) names every draft.¶

The same mechanisms, placed on the authority path (Figure 1) by the transition each acts on:¶

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. Read as shared capabilities rather than universal wire semantics, all the bindings carry durability, attribution, and termination; narrowing and containment require a structured-authority capability, so they are not baseline AAuth Mission Context properties.¶

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 every new positive governance decision require the exact state active; every other state, including an unrecognized one, fails safe (the OAuth binding's Mission Lifecycle and Gating section). A state-aware consumer relies only while it observes active; a state-unaware consumer retains the bounded materialized-credential residual (Section 10.4). In AAuth, only PS operations are structurally gated, and agent identity and resource-managed access do not pass through the PS. In person identity access the gate is person-token issuance (Section 7.1 of [I-D.draft-hardt-oauth-aauth-protocol]). In PS authorization and federated authorization access it covers auth-token issuance and federated brokering for requests whose resource token carries the validated Mission Reference; a stripped or mismatched reference fails the request, which is never evaluated as missionless ([I-D.draft-mcguinness-mission-aauth]).¶

Authority only narrows:

Derived tokens, delegated child Missions, attenuated tokens, and cross-domain projections carry subsets (Figure 1); 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]). Within a live Mission, issuer-held narrowing such as containment or discharge only subtracts: each mechanism feeds a single Effective Authority Set, every derivation reads it, and none restores authority ([I-D.draft-mcguinness-oauth-mission-status]). The relation is typed: a type's specification defines its subset relation, and an issuer narrows, delegates, or projects an entry only under a capability it declares for that type (for example, on the OAuth binding, mission_resource_access and its Common Constraints, [I-D.draft-mcguinness-oauth-mission-resource-access]). Without that capability the entry is carried exactly as approved. Moving authority into expressive policy-language entries weakens this guarantee exactly there, a trade to make knowingly ([I-D.draft-mcguinness-mission-security-model]).¶

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.4; [I-D.draft-mcguinness-oauth-mission-status]).¶

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 6.1). 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 10.5).¶

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 9.2). AAuth's corresponding integrity property is the s256 commitment over exact mission-blob bytes, not the OAuth integrity anchors.¶

Three readings follow from the seven invariants and add no eighth:¶

Authorization bases:

"Approved" in the first invariant has more than one basis. The OAuth binding fully defines one, direct, a human's own approval. It also 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; policy_drawdown, a child instance a policy adjudicates within a bound the parent's human already consented to; and ceiling_drawdown, a successor a policy adjudicates within an authority ceiling the Approver consented to at the initial approval. Every basis fixes the same accountable human as consent_principal; the bases differ only in what activated this instance and what root that activation traces to (the OAuth binding).¶

Work products:

Authority never rides a work product. Crossing into a Mission, a work product is input the receiving Mission re-evaluates under its own Authority Set, never a source of authority itself. The Mission Work Products companion carries this through non-transitive Mission-to-Mission handoff ([I-D.draft-mcguinness-oauth-mission-work-products]), and the OAuth binding states the rule in its "Authority Does Not Propagate With Information" section ([I-D.draft-mcguinness-oauth-mission]).¶

Composition:

An approval bounds the authority each derivation under the Mission carries; it does not bound the aggregate effect of a body of work. The invariants bound one Mission's own Authority Set, not the surface a delegation tree, a cross-domain hop, or a chain of child generations reaches together. The per-Mission figures differ in kind and do not multiply into a lifetime total: in the child-delegation profile, max_children limits concurrently non-terminal children, so a completed child frees its slot; max_child_depth limits generations; and each Child Mission's derivation cap is its own, independent of its parent's. Delegation depth also resets at each cross-domain hop and child generation. Disclosing what these figures bound at the consent surface is the cross-domain and child-delegation profiles' role. An aggregate bound holds only where a deployment enforces one, the metering profile's lineage budget, and is never rendered as in force otherwise ([I-D.draft-mcguinness-oauth-mission-cross-domain], [I-D.draft-mcguinness-oauth-mission-child-delegation], [I-D.draft-mcguinness-mission-metering]). The OAuth binding states the same property in its "Composition and the Effective Ceiling" section ([I-D.draft-mcguinness-oauth-mission]).¶

9. Meaning and Derivation

Three questions sit between a proposed task and enforced authority: who owns what an operation means (Section 9.1), who commits the authority derived from the task (Section 9.2), and what the approval event fixes (Section 9.3).¶

10. The Mission Substrate

The binding-neutral contract is Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]), which states the checklist below normatively for any further binding. Its contextual-governance kernel is what every binding provides: a mission-based protocol supplies a Mission Context when it maps these 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.¶

Beyond the kernel, each binding that publishes a Mission Substrate Statement claims through it any of eight optional capabilities (Lifecycle-Gated Authorization, State-Observable, Structured Authority, Monotonic Derivation, Credential-Bound, Authorized Context Correlation, Independently Verifiable, and Portable Evidence), and composes only the profiles whose required capabilities it provides. The OAuth binding publishes no Statement and is mapped to the same capabilities in its informative Mapping Assessment ([I-D.draft-mcguinness-oauth-mission]).¶

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 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 OAuth binding instantiates the substrate through eight primitives, each with its normative home and its consumers: six in the table below, the Mission-Bound Credential in its own subsection after Token Classes, and the approval event, whose fidelity is described with the derivation boundary (Section 9.3).¶

The binding-neutral kernel requires none of these OAuth-binding representations or stronger semantics verbatim. 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.¶

11. Mission Assurance Levels

This document uses six frames for what a deployment does and what it can show. Each answers a different question, and none substitutes for another:¶

The levels are adoption bundles: which documents a deployment runs, named so a deployment, a procurement, or a review can cite one bundle. They are guidance, never a conformance class, an earned label, or a ladder a deployment must climb; a deployment adopts the bundle its risk warrants and stops there. A level does not determine any action class's containment property. The proof obligations noted with each level are the claims that become available at that bundle, not properties the level name asserts.¶

A relying party compares claims, not levels (Section 11.2), 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.¶

The levels build on one another in the order deployments build: recording and governing the approved task (Baseline Issuance), then per-action enforcement (Runtime-Enforced), then agent governance and compromise resistance (Governed Agent and High-Assurance Agent).¶

The binding is an orthogonal axis, and a binding is not a level. The authority-bearing bindings name their level separately from their binding. The standalone MAS is the case that matters most: it provides the Mission record, lifecycle, and authority but no Mission-bound credential and no issuance gating. Under the standalone MAS, the kill switch is the runtime layer alone, not the token gate, and a deployment states that.¶

An AAuth deployment reports the Mission Context capabilities and resource access modes it actually uses instead of a level. Selecting the AAuth binding does not by itself satisfy structured-authority, subset, portable-evidence, or runtime proof obligations. Its lifecycle gate covers person identity, PS authorization, and federated authorization but not agent identity or resource-managed access, and its native auth token is Mission-referenced, not Mission-bound (Section 10.2).¶

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. That gated issuance 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 closes the temporal bound by the clock alone and observes no revocation, suspension, completion, or containment, which is why the lifetime must not exceed the tolerated staleness. 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 under such a binding until a freshness surface 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 person-token issuance and to PS authorization 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. Where the binding gates issuance, 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.¶

Illustrative verification scenarios for this level, each traced to the rule its home document states, are in Appendix E.¶

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 profile). Grants per-action enforcement and bounded revocation: for gated classes, within the staleness bound plus the permit window plus the class's execution bound; for paths no runtime gate reaches, within token lifetime where issuance is gated.¶

Runtime-Enforced is the smallest deployment that turns a Mission from governed issuance into action-time defense, and every normative dependency it needs is a family document intended for the Standards Track. It is a substantial build, not a wedge: 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 the substrate contract (the kernel that runtime and AuthZEN consume normatively), runtime, its AuthZEN profile, runtime evidence, and a concrete freshness source, Status being the reference choice.¶

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. With these, 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. With both, 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 in adoption order, 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. A deployment states its own mediated_action_classes and exclusions in the Mission Deployment Profile (Section 12.6).¶

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 mechanisms are accountability, not prevention: they make what was recorded tamper-evident, not what was perceived true or what was never recorded present.¶

12. Mission Deployment Patterns

13. Security Considerations

This document defines no wire mechanism; each profile's own Security Considerations remain normative, and the consolidated trusted base and compromise analysis are the Mission Security Model's ([I-D.draft-mcguinness-mission-security-model]). This document introduces composition, and its security subject matter is the risks that emerge only at composition:¶

• stale state and materialized authority: an already-issued credential, redeemed grant, or minted attenuation root stays usable to its artifact-specific bound only where no timely state-aware or action-time gate reaches it, and, for a contained capability, where no containment-aware gate does (Section 11.5); where one does, reliance ends at that earlier gate (Section 10.4, Section 11.5);¶

• unmediated paths: enforcement claims hold only inside the declared PEP boundary, and the Enforcement Scope Statement's exclusions are where a compromised agent goes first;¶

• semantic-derivation trust: the derivation boundary (Section 9.2) concentrates meaning-to-authority translation at the issuer, and the anchors commit its output, not its correctness;¶

• component compromise: issuer, PDP, PEP, state source, and evidence producer each void a different guarantee when compromised, and the security model prices each;¶

• context splicing and join ambiguity: independently valid identity, credential, and Mission facts compose into an unauthorized whole wherever they are combined without an authorized joining authority, verified inputs, an association policy, and conflict handling ([I-D.draft-mcguinness-mission-substrate]);¶

• false but correctly signed evidence: signatures make records tamper-evident, never true; and¶

• correlation: the Mission Identifier, actor chain, and evidence joins that make audit possible are the same joins that correlate activity across audiences (Section 14).¶

14. Privacy Considerations

The privacy properties of the Mission record and the Mission Intent are the OAuth binding's ([I-D.draft-mcguinness-oauth-mission]), for it and for the bindings that import its record, and each adopted profile's; the AAuth binding's are its own, below. 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]).¶

Read across profiles, the dataflow concentrates in three places: the record and its evidence at the issuer (task prose, principals, authority, provenance); the decision and execution evidence joined on the Mission Identifier at the runtime and audit layers; and the correlation surface that identifier creates wherever it travels (tokens, status responses, evidence, receipts, the Mandate).¶

Minimization therefore has one shape everywhere: audience-scope what each party receives, prefer audience-scoped references over content (a stable reference reused across audiences is itself a correlation surface), and let the record's access governance, not possession of a reference, decide who reads the concentrated view.¶

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, and the stable Mission Reference (mission_s256 with the approving PS) is a correlation handle across every resource that sees it. The mission log concentrates a detailed activity history at the Person Server, where the binding's minimization and retention duties apply.¶

15. IANA Considerations

This document makes no IANA request.¶

16. Informative References

[A2A]

A2A Project, "Agent2Agent (A2A) Protocol Specification, Version 1.0", 2026, <https://a2a-protocol.org/v1.0.0/specification/>.

[I-D.draft-hardt-aauth-r3]

Hardt, D., "AAuth Rich Resource Requests (R3)", Work in Progress, Internet-Draft, draft-hardt-aauth-r3-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-hardt-aauth-r3-00>.

[I-D.draft-hardt-oauth-aauth-protocol]

Hardt, D., "AAuth Protocol", Work in Progress, Internet-Draft, draft-hardt-oauth-aauth-protocol-11, 25 September 2026, <https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11>.

[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-11, 3 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-11>.

[I-D.draft-ietf-oauth-rar-metadata-remediation]

Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft-ietf-oauth-rar-metadata-remediation-00, 23 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-metadata-remediation-00>.

[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, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02>.

[I-D.draft-mcguinness-aauth-mission-expiry]

McGuinness, K., "AAuth Mission Expiry", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-aauth-mission-expiry.html>.

[I-D.draft-mcguinness-mission-aauth]

McGuinness, K., "Mission Context Binding for AAuth", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-aauth.html>.

[I-D.draft-mcguinness-mission-aauth-management]

McGuinness, K., "AAuth Mission Management", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-aauth-management.html>.

[I-D.draft-mcguinness-mission-audit]

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

[I-D.draft-mcguinness-mission-authority-server]

McGuinness, K., "Mission Authority Server", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.html>.

[I-D.draft-mcguinness-mission-authzen]

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-capability-binding]

McGuinness, K., "Mission Capability Binding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-capability-binding.html>.

[I-D.draft-mcguinness-mission-discovery]

McGuinness, K., "Mission Open-World Discovery", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-discovery.html>.

[I-D.draft-mcguinness-mission-gnap]

McGuinness, K., "Mission-Bound Authorization for the Grant Negotiation and Authorization Protocol (GNAP)", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-gnap.html>.

[I-D.draft-mcguinness-mission-harness]

McGuinness, K., "Mission-Aware Agent Harnesses", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-harness.html>.

[I-D.draft-mcguinness-mission-mandate]

McGuinness, K., "Mission Mandate", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.html>.

[I-D.draft-mcguinness-mission-metering]

McGuinness, K., "Mission Consumption Metering", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-metering.html>.

[I-D.draft-mcguinness-mission-orchestration]

McGuinness, K., "Mission Orchestration and Unwinding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-orchestration.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-mission-runtime-evidence]

McGuinness, K., "Mission Runtime Evidence", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime-evidence.html>.

[I-D.draft-mcguinness-mission-security-model]

McGuinness, K., "Mission Security Model", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-security-model.html>.

[I-D.draft-mcguinness-mission-shaping]

McGuinness, K., "Mission Intent Shaping", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-shaping.html>.

[I-D.draft-mcguinness-mission-substrate]

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.html>.

[I-D.draft-mcguinness-mission-uma]

McGuinness, K., "Mission-Bound Authorization for User-Managed Access (UMA) 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-uma.html>.

[I-D.draft-mcguinness-oauth-client-attesters]

McGuinness, K., "OAuth 2.0 Client Attester Endorsement", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-attesters-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-attesters-00>.

[I-D.draft-mcguinness-oauth-client-instance-id]

McGuinness, K., "Client Instance Identification for Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-id-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-00>.

[I-D.draft-mcguinness-oauth-id-continuation-assertion]

McGuinness, K. and A. Parecki, "Identity Continuation Assertion for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft-mcguinness-oauth-id-continuation-assertion-02, 8 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-id-continuation-assertion-02>.

[I-D.draft-mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

[I-D.draft-mcguinness-oauth-mission-approval]

McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html>.

[I-D.draft-mcguinness-oauth-mission-approved-set-verification]

McGuinness, K., "Mission Approved-Set Verification for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approved-set-verification.html>.

[I-D.draft-mcguinness-oauth-mission-attenuation]

McGuinness, K., "Mission Offline Attenuation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-attenuation.html>.

[I-D.draft-mcguinness-oauth-mission-child-delegation]

McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.

[I-D.draft-mcguinness-oauth-mission-consent-evidence]

McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-consent-evidence.html>.

[I-D.draft-mcguinness-oauth-mission-containment]

McGuinness, K., "Mission Containment for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-containment.html>.

[I-D.draft-mcguinness-oauth-mission-continuation]

McGuinness, K., "Mission Continuation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-continuation.html>.

[I-D.draft-mcguinness-oauth-mission-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

[I-D.draft-mcguinness-oauth-mission-derivation-limits]

McGuinness, K., "Mission Derivation Limits for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-derivation-limits.html>.

[I-D.draft-mcguinness-oauth-mission-discharge]

McGuinness, K., "Mission Entry Discharge for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-discharge.html>.

[I-D.draft-mcguinness-oauth-mission-expansion]

McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.

[I-D.draft-mcguinness-oauth-mission-issuance-grant]

McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-issuance-grant.html>.

[I-D.draft-mcguinness-oauth-mission-management]

McGuinness, K., "Mission Management for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-management.html>.

[I-D.draft-mcguinness-oauth-mission-progressive]

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.html>.

[I-D.draft-mcguinness-oauth-mission-resource-access]

McGuinness, K., "Mission Resource Access Profile for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-resource-access.html>.

[I-D.draft-mcguinness-oauth-mission-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

[I-D.draft-mcguinness-oauth-mission-status-list]

McGuinness, K., "Mission Status List for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status-list.html>.

[I-D.draft-mcguinness-oauth-mission-submission-evidence]

McGuinness, K., "Mission Intent Submission Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-submission-evidence.html>.

[I-D.draft-mcguinness-oauth-mission-transaction-authorization]

McGuinness, K., "Mission Transaction Authorization Profile for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-transaction-authorization.html>.

[I-D.draft-mcguinness-oauth-mission-work-products]

McGuinness, K., "Mission Work Products for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-work-products.html>.

[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, <https://datatracker.ietf.org/doc/html/draft-zhu-oauth-async-delegation-05>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[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, <https://www.rfc-editor.org/rfc/rfc8693>.

[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, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

[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, <https://www.rfc-editor.org/rfc/rfc9943>.

Appendix A. Mission Requirements

The requirements the family answers are stated implementation-neutrally; each names its answering documents by short form (Appendix G). 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.¶

Two further properties are separately claimable capabilities, not one bundle: the second requires the first, and a design can hold the first alone ([I-D.draft-mcguinness-mission-substrate]):¶

1. Structured Authority: credentials or decisions carry authority that an identified enforcement point can evaluate.¶

2. Monotonic Derivation, available only where Structured Authority holds: 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, over a State-Observable source with a stated staleness bound, two further properties hold:¶

1. Per-action runtime enforcement: consequential actions are checkable against the object at the point of use.¶

2. Decision accountability, growing to a joined record: every gated action yields Decision Evidence joined on the object's identity. What was shown requires Consent Evidence and what was done requires Execution Evidence for the covered classes; with those adopted, what was approved, shown, decided, and done is reconstructible from the join.¶

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 both authority capabilities as well. Runtime and portable evidence remain separately claimed capabilities; the requirements below unpack the family mechanisms without implying every binding implements every one.¶

Appendix B. 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.¶

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.4). 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:¶

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.¶

Appendix C. A Worked Composition

This non-normative example composes a deployment that enforces at action time 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:¶

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 12.6), and the declaration is ordinary deployment documentation.¶

The deployment runs PS authorization (three-party) access. Every auth token the gateway accepts is PS-issued and carries the signed mission_s256 reference copied from the resource token, the protected propagation path; agent identity, person identity, resource-managed, and federated access are out of scope here.¶

Before joining the PS evidence, the Actor proof, the request, and the adapter's output, 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. 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:¶

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 the state source is disabled with no equivalent fresh local read, or when the state source's staleness exceeds the declared maximum. It fails when the adapter publishes descriptive strings rather than machine-evaluable semantics, or when the payment-vocabulary claim is generalized to another resource's vocabulary. It fails when a direct route bypasses the gateway, when the gateway accepts a Mission reference from the agent without validated provenance (context splicing), or when the gateway accepts the reference on an agent identity or resource-managed request.¶

Appendix D. 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 differs 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.¶

Appendix E. Illustrative Verification Guidance

These scenarios illustrate how a Baseline Issuance deployment can be checked. Each checks a rule its home document states normatively; this document owns none of them and confers no conformance class.¶

Coverage is scoped by the capabilities a binding's Mission Substrate Statement claims (the OAuth binding, which publishes no Statement, is covered through its own Conformance gates). A standalone MAS is therefore never asked to verify a credential behavior it does not claim. The family's conformance manifest carries the profile-owned rows.¶

Kernel, every Baseline deployment (the substrate contract's approval event, governance gate, and bounded reliance, [I-D.draft-mcguinness-mission-substrate]):¶

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.¶

Expiry ceiling, where the binding imposes one (the OAuth binding's Mission-Bound Access Tokens section, [I-D.draft-mcguinness-oauth-mission]; the UMA and GNAP bindings, [I-D.draft-mcguinness-mission-uma], [I-D.draft-mcguinness-mission-gnap]; for AAuth, the expiry profile, [I-D.draft-mcguinness-aauth-mission-expiry]; and for the standalone MAS, the issuance grant's Lifetime rule, [I-D.draft-mcguinness-oauth-mission-issuance-grant]):¶

1. no credential outlives the Mission's effective expiry.¶

Credential-Bound, where claimed (the substrate contract's Credential-Bound capability):¶

1. 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 (the substrate contract's Lifecycle-Gated Authorization capability):¶

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).¶

For the OAuth binding, the same coverage includes (the OAuth binding's Mission Lifecycle and Gating and grant-binding rules, [I-D.draft-mcguinness-oauth-mission]):¶

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.¶

Appendix F. Deployment Profile Example Shapes

These shapes are illustrative. This document fixes no serialization, and each fact's owning profile governs its meaning (Section 12.6).¶

The first shape is for a deployment that runs mediated credential custody but makes neither High-Assurance claim. The agent-compromise-resistant claim requires the runtime profile's per-condition evidence bindings (EAT profile and claim identifiers, measurements, appraisal policy, attester identity, freshness, signed approval configuration, rendering evidence, and a path-completeness audit); this shape's generic attestation reference is declaration input, not that proof. Its key_custody entries are declarations under the same rule: a custody statement made legible, not a checked assurance grade (the member's definition in Section 12.6 states the open verifier gap):¶

{
  "profile": "mission-governed-agent-runtime",
  "assurance_claims": [
    "action-time enforcement", "parameter-bound enforcement",
    "bounded revocation latency"
  ],
  "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",
      "privileged_administration"
    ],
    "action_bound_approval_classes": [
      "irreversible_action", "external_commitment",
      "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"
  },
  "execution_environment": {
    "attestation_ref": "https://attest.example.com/runtime/2026"
  },
  "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,
    "egress_mediated": 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": [
    "mediated custody is declared, not evidenced: no High-Assurance claim is made",
    "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"
  ]
}

An issuance-only deployment (Section 12.2) publishes a smaller shape: no runtime, credential_custody, or harness member, its token lifetime stated as the revocation bound where a Resource Server does not introspect, and residuals that name the per-action check it does not run:¶

{
  "profile": "mission-issuance-only",
  "assurance_claims": [
    "approved-record integrity", "bounded revocation latency"
  ],
  "mission_issuer": "https://as.example.com",
  "state_sources": [
    { "type": "introspection", "max_staleness_seconds": 0 }
  ],
  "issuance": {
    "binding": "oauth-core",
    "refresh_gated_on_active_state": true,
    "max_access_token_lifetime_seconds": 300
  },
  "resource_servers": {
    "authorization_details_enforcing": ["https://erp.example.com"],
    "scope_projection_only": ["https://mail.example.com"],
    "constraint_enforcement_for_scope_only": "refuse_issuance"
  },
  "residual_risks": [
    "no per-action check within a token lifetime",
    "revocation up to 300 seconds where no introspection",
    "scope-only constraints not projectable are refused",
    "delegated tokens reach Mission-aware resources only"
  ]
}

Appendix G. 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.¶

Maturity is a dependency boundary. A Standards-Track profile never depends normatively on an experimental one, and a Standards-Track document cites an experimental profile informatively at most. The experimental profiles extend the stable interface only through its declared seams: the Mission Intent extension seam of the OAuth binding (a named, companion-defined top-level member) and the coordinated-extension rules of the evidence objects. 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:¶

The substrate and the bindings:¶

Approval time:¶

Lifecycle:¶

Cross-domain projection and continuity:¶

Runtime enforcement:¶

Agent runtime:¶

Sub-agents:¶

Proof and portability:¶

Security model:¶

Appendix H. Document History

[[ To be removed from the final specification ]]¶

• The derivation-modes table follows the OAuth binding: a model's output in derivation is a recorded input that can refuse or narrow, never supply or widen, with no change to any profile's requirements.¶

• The authority path, with no change to any profile's requirements. The Mission adds a figure from approval basis to action, with the lifecycle gate beside the path, child creation as a new approval event, and the current Effective Authority Set as a separate runtime input; the Mission Verbs adds a table placing each mechanism on the transition it acts on; and Binding Security Architectures states that one Mission can span authorization servers whose client identifiers differ, related through the owning Mission Issuer's recorded mappings.¶

• The RAR metadata citation names the working-group successor draft-ietf-oauth-rar-metadata-remediation and separates an authorization server's type metadata from a protected resource's RFC 9728 authorization_details_types_supported.¶

• Approve and Record names the three approval roles (derivation, adjudication, accountability) and summarizes the OAuth binding's rule that a model's judgment enters adjudication only as a recorded input to a deterministic policy, an input that can refuse or narrow and never grant or widen; the prose members stay the human Approver's check.¶

• Composition states the per-Mission bound model once, with no change to any profile's requirements: an approval bounds the authority each derivation carries; concurrent children, generations, and per-Mission derivations do not multiply into a lifetime total; and an aggregate bound holds only where a deployment enforces one.¶

• Derivation and narrowing, with no change to any profile's requirements. The derivation boundary states the derivation procedure the authority-bearing bindings share (narrowing or a configured mapping, with prose members as disclosure) and that only derivation policy stays local; Authority only narrows covers the Effective Authority Set and the per-type transformation capabilities.¶

• The issuance-join row of the composed kill-switch table and its note follow the Mission Issuance Grant's two consuming-AS modes: with a Mission-state integration, redemption and refresh are projected through the Effective Authority Set; without one, nothing is checked at redemption and no refresh tokens are issued. The earlier "active-only" redemption check no longer exists there.¶

• AAuth alignment, with no change to any profile's requirements. The AAuth and R3 references cite the published revisions -11 and -00; the Mission Reference is the approving PS and s256; the access modes carry AAuth's names; and the gateway walkthrough names the issuers of the auth tokens it accepts.¶

• Density, with no change to any profile's requirements. Long paragraphs are split to one idea each and long sentences shortened; Continue lists the three continuities and keeps the residual for authority already issued under a continued grant; the binding properties' mechanism mapping is a table; the kill-switch composition table has short cells with numbered notes; and meta-commentary about the document is removed. OAuth-specific statements the pass found unlabeled now say so.¶

• Reading order and section ownership, with no change to any profile's requirements. A Mission's Life leads the model; Meaning and Derivation gathers the ontology contract, the derivation boundary, and approval fidelity; the binding comparison, now with GNAP, sits with the substrate; Assurance opens with a table of the frames it uses and folds the reference stacks into the levels; and each deployment pattern has its own subsection. Requirements, the conventional-stack comparison, the worked composition, error surfaces, illustrative verification guidance, the Deployment Profile shapes, and the trimmed document map are appendices. The verb spine carries an overlay of owning documents and packages. Repeated explanations have one home, and a repetition that qualifies a guarantee keeps a short local summary. The model is stated binding-neutrally, with each realization labeled, and the Runtime-Enforced bundle's dependencies are described by intended category, not maturity.¶

• Editorial corrections, with no change to any profile's requirements. The capability-kill property is stated per action class and consumer rather than per assurance level, matching the composition section and the containment profile. The four Mission Issuer bindings are named, and GNAP joins the Mission Issuer roles, the control-point peer row, and the credential-carried pattern. The worked composition names no level. The AAuth protocol and R3 are cited, and AAuth terms are expanded on first use. Terms owned elsewhere point to their owners. "Mission-bound" names one definition. Keywords describing other documents' rules are lowercased, and temporal phrasing is removed. The agent-identity section is retitled, the binding-property summary covers the whole vector, and the AuthZEN companion is called the AuthZEN profile. The Stop step of A Mission's Life separates what ends at once from what ends within a staleness bound or at a token's own expiry.¶

• The issuance-only deployment is named under Entry Ramps by Estate with its invariants, introspection cutoff, claims, and runtime triggers; the adoption-ladder table grants Baseline Issuance the reads and writes whose bounds the receiving Resource Server enforces; and the Deployment Profile gains an issuance-only example shape.¶

• Client-instance references follow their successors: draft-mcguinness-oauth-client-instance-assertion is replaced by {I-D.draft-mcguinness-oauth-client-instance-id} and [I-D.draft-mcguinness-oauth-client-attesters], and the deprecated draft-mcguinness-oauth-ai-agent-instance is no longer cited. Instance identity is a client-instance attestation and validated Instance Context, attribution needs an instance-unique key, and instance evidence identifies no actor. No requirement changed.¶

• Linked the OAuth binding's informative derivation-policy appendix from the authority derivation boundary (#309).¶

• Added the optional Control-Plane Consistency companion to the document map (#250).¶

• Controls taxonomy retirement (#636): the swarm-execution discussion no longer claims derivation_limit (renamed from max_derivations) is a fan-out or concurrency ceiling; it counts issuance events, not instances, and one instance refreshing repeatedly exhausts it exactly as N instances deriving once each would. The Agent Deployment pin is now described as a named architectural pattern with no wire member the OAuth binding currently defines, pointing to a forward-referenced Agent Deployment Binding profile instead of the retired controls.agent_deployment. References to the OAuth binding's retired controls extension seam updated to the Mission Intent's own (open, named-member) extension seam.¶

• PR #717 review fix: precised the "Mission-bound" definition text (Section 10.2 and Section 11.3) so it no longer requires a Mission Substrate Statement of a binding that deliberately publishes none. A binding that claims substrate conformance evidences credential-mission-bound through its own Statement; the OAuth binding, which claims no substrate conformance and publishes no Statement, is instead assessed through its own informative Mapping Assessment and discharges the definition directly through its own Conformance gates. No normative content changed.¶

• Reworded the blanket "the bindings are peers of one another" sentence in the Introduction to name two independent axes, deployment topology and data-model independence, and to classify the Mission Authority Server as a normative standalone-controller protocol binding over the OAuth Mission data model: a peer deployment topology, but not an independent substrate model (#704). Cross-referenced the three previously uncross-referenced accounts of what earns "Mission-bound" (Section 10.2 and Section 11.3, and the OAuth binding's Conformance gates): Section 11.3's credential-mission-bound equivalence is now the stated definition, a binding's Mission Substrate Statement is how it evidences the properties, and the OAuth binding's gates are its discharge of the definition (#663). No normative content, anchor, or table row changed.¶

• Cross-referenced the three previously separate accounts of what earns the "Mission-bound" term: Section 10.2 now names the Mission Binding Properties vector's credential-mission-bound property (Section 11.3) as the definition. Its six conditions are each mapped to the Statement capability or OAuth binding surface that discharges it, condition 2 (Mission identity) no longer names a token-carried authority_hash, aligning with the ruled minimal-claim direction of #702, and condition 6 (the auditable derivation link) names the OAuth binding's retained Mission Record explicitly rather than asserting an unspecified discharge (#663).¶

• Non-goal reworded (#637): "a new authority format, or a new grant protocol" narrowed to "a new grant protocol," naming the OAuth binding's Mission Resource Access Profile as the family's one cross-resource authorization_details type, since RFC 9396 leaves type semantics to the type and the family now defines one. Document Map gains the profile's row under "The substrate and the bindings."¶

• Editorial density pass on this Informational document: the aggregate-ceiling and artifact-plane (non-transitive work-product) composition readings under Section 8 tightened to a summary sentence plus citation each, with their "not this summary, is the normative text this passage tracks" deferral kept; several over-long paragraphs in Section 4.1, Section 10.4, Section 11, and Section 11.4 split for one idea per paragraph and front-loaded openers. No normative content, anchor, or table row changed.¶

Acknowledgments

This document is part of the Mission-Bound Authorization work and maps the structure that its profiles establish individually.¶

Author's Address