Mission Context Binding for AAuth

1.1. Contextual Governance, Not Portable Authority

AAuth missions are not a machine-evaluable policy language. The PS has the approved mission description, the person's context, the agent's justifications, prior decisions and actions, and a channel to the person for clarification. It uses that context to govern whether the agent's next action is appropriate.¶

Deterministic authorization is separate. A resource describes and enforces its permissions through scopes, resource tokens, its own policy, and, in federated deployments, Access Server policy. An AAuth deployment can additionally use R3 [I-D.draft-hardt-aauth-r3] for structured, resource-owned authorization semantics.¶

Consequently, this binding does not define an Authority Set, translate mission tools into authorization details, or require one resource's authorization to be a subset of another's. Each resource decision is made in that resource's vocabulary and at its own policy decision point. The PS applies the further contextual governance constraint when it is on the authorization path.¶

1.2. Scope

This document specifies:¶

• how an AAuth mission is identified and bound to an agent;¶

• which AAuth approval and lifecycle events form the Mission Context;¶

• how a PS applies the active-state gate to its own endpoints and to authorizations that it brokers;¶

• how the native mission reference propagates without exposing the mission blob; and¶

• the resulting security, privacy, audit, and compromise properties.¶

This document does not specify general-purpose mission management, administrative termination, delegation-tree queries, portable evidence, or deterministic cross-resource permission semantics. Those are possible AAuth companion specifications rather than requirements of this binding.¶

3.1. Capability Model

An AAuth mission, as this binding profiles it with AAuth Mission Expiry, supplies every element of the contextual-governance kernel of [I-D.draft-mcguinness-mission-substrate]; base AAuth alone supplies all but the reliance bound. The element-by-element mapping and the formal capability claims are this binding's Mission Substrate Statement (Section 9). In AAuth's own terms:¶

Stable native reference:

The pair {approver, s256} remains this binding's Mission Reference, with s256 compared within the approver's namespace. On the wire it travels as the flat mission_s256 claim, with that namespace carried by the person token's iss and the resource token's ps. No additional mission_id is needed or defined.¶

Controlling authority:

approver identifies the PS responsible for approval and governance. It is not replaced by a separate Mission issuer field.¶

Agent binding:

The approved mission blob contains the AAuth agent identifier in its agent member. The PS MUST ensure that requests using the reference are made by that agent, except where AAuth expressly defines a parent-mediated or call-chaining relationship.¶

Immutable approved context:

s256 commits to the exact decoded bytes of the base64url mission member. The blob is stored by the agent and PS rather than distributed to resources.¶

Explicit approval:

The AAuth propose, clarify, and approve interaction produces the approved blob and reference.¶

Lifecycle gate:

Only an active mission can support new governed requests. A terminated mission is permanently non-active.¶

Bounded reliance:

AAuth enforces expires_at on every PS decision path and caps every token carrying mission_s256 to it (Section 4.8); the PS still establishes active at decision time.¶

Context propagation:

The signed mission_s256 claim, carried by person, resource, and auth tokens, carries only the reference. Support varies by resource access mode as described in Section 4.5.¶

Ordered governance record:

The PS maintains the mission log and evaluates new governed requests in the context of that history.¶

Structured Authority, Monotonic Derivation, Independently Verifiable, and Portable Evidence are not baseline properties of this binding; Section 9 records the formal claims. A companion protocol can supply one or more of those capabilities without changing the meaning of the AAuth mission blob.¶

3.2. Native Reference and Exact-Byte Commitment

The mission reference is exactly the AAuth pair:¶

{
  "approver": "https://ps.example",
  "s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}

The PS's approval envelope carries s256 alongside a mission member that is the base64url encoding, without padding, of the exact bytes it persists as the mission blob. The agent decodes mission to recover those bytes. AAuth makes verifying s256 against the decoded bytes a SHOULD before first use; a Mission Context Agent MUST verify it before any governed use, and MUST preserve the decoded bytes exactly. Parsing and reserializing the JSON can change the bytes and therefore MUST NOT be used to reproduce the committed blob.¶

The reference simultaneously provides stable identification and an integrity commitment. This binding does not add intent_hash, authority_hash, proposal_hash, or a second semantic projection. Such parallel commitments would create ambiguity about which object was approved and would require implementations to keep multiple canonicalizations in lockstep.¶

The reference does not authenticate itself when copied outside a protected AAuth message. It gains protocol integrity from the AAuth message signature or signed token that carries it. Implementations MUST apply all AAuth signature, issuer, audience, proof-of-possession, and request-context checks before relying on a received reference.¶

3.3. Mission Blob

The approved mission blob uses the members defined by AAuth, including approver, agent, approved_at, and description, and optionally approved_tools and approved_resources. The blob carries AAuth's expires_at member, which this binding requires on every mission (Section 4.8). This binding itself defines no additional members. AAuth states that these member lists are a floor, not a closed set; a reader MUST ignore a member it does not recognize.¶

The blob's agent value is an AAuth agent identifier. It MUST NOT be described or processed as an OAuth client_id. The two identifiers have different namespaces, discovery mechanisms, and key-binding properties.¶

The approved description expresses human intent and governance context. It is not a deterministic access-control policy. The PS or person can refine, constrain, or expand the proposed description during review; the approved blob returned by the PS is the authoritative result.¶

4.1. Roles

The AAuth roles map to the Mission Context model as follows:¶

No AAuth party becomes an OAuth client, Authorization Server, or Resource Server merely by implementing this binding.¶

4.2. Proposal, Clarification, and Approval

The agent creates the Mission Context by sending an AAuth mission proposal to the PS mission_endpoint. The proposal contains the natural-language description and can contain requested tools as defined by AAuth.¶

The PS MAY defer the response while the person or another appropriate decision-maker reviews the proposal. AAuth clarification messages can ask the agent for missing context or negotiate changes. The agent MUST NOT treat the proposal, a pending response, or a clarification exchange as approval.¶

Approval occurs only when the PS returns the approval envelope: s256 and the approved mission blob as the base64url-encoded mission member. Before using the context, the agent MUST:¶

1. verify the AAuth response according to the base protocol;¶

2. decode mission and compute SHA-256 over the exact decoded bytes;¶

3. verify that the result equals the envelope's s256 value;¶

4. verify that the blob's approver and agent members identify the approving PS and requesting agent; and¶

5. store the exact decoded bytes and native reference.¶

A failed check invalidates the approval response. The agent MUST NOT operate under the resulting reference.¶

4.3. Governed Requests and Mission Log

For every PS request seeking a positive governance decision under a mission reference, the PS MUST verify that:¶

• it is the identified approver;¶

• the s256 identifies a mission blob it approved;¶

• the authenticated agent is entitled to act in the referenced context; and¶

• the mission is active.¶

If any of these checks cannot be completed, including establishing the mission's current state, the PS MUST fail closed and reject the request.¶

Authenticated status, termination, denial, cleanup, and audit operations defined by this binding's companions are not positive governance decisions; they answer on a non-active mission as their specifications define.¶

The PS then evaluates the request using the approved description, the request's justification and other inputs, applicable person or organization policy, and relevant prior entries in the mission log. A valid reference means that the context is identified and intact; it does not require the PS to approve the request.¶

The PS MUST maintain the mission log as an ordered record of the AAuth interactions defined to belong to the mission, including token requests, permission decisions, audit records, interaction requests, and clarification chats. Log records SHOULD preserve sufficient correlation data to associate each decision with its authenticated request and any issued token without recording raw credentials.¶

The PS MUST protect the mission log's integrity, MUST restrict read access to the person, the PS itself, and parties authorized under its administrative policy, and MUST retain the log for a declared period that extends beyond termination.¶

The mission log is complete only for PS-observed operations. approved_tools activity the agent performs without a per-call PS decision, and any other agent-side action, enters the log only as agent-reported audit records; the PS MUST distinguish agent-reported entries from PS-observed ones and MUST NOT represent the former as the latter. A counter or hash chain alone does not prove completeness for activity that can occur without consuming it; a deployment needing stronger completeness for local activity requires a non-bypassable observation point.¶

The approved blob is immutable. New facts, decisions, and actions are appended to the log; they do not mutate or replace the committed blob.¶

4.4. Deterministic Resource Authorization

A mission approval does not pre-authorize a portable set of remote resource operations. Deterministic resource authorization continues to use the AAuth mechanisms appropriate to the access mode:¶

• the resource's identity-based policy;¶

• the resource-managed authorization result;¶

• scopes in resource and auth tokens;¶

• resource policy in PS-asserted access;¶

• Access Server policy in federated access; and¶

• optionally, resource-owned R3 vocabularies and requests.¶

The PS's governance decision is an additional contextual decision where the PS is on the path. It neither replaces the resource's deterministic authorization nor proves that every resource independently enforces the mission description.¶

No general subset relation is defined between successive or downstream resource scopes. In a call chain, a downstream resource can require an operation that has no equivalent in the upstream resource's vocabulary. The PS evaluates each governed hop against the mission context, while each Resource or Access Server applies its own policy.¶

4.5. Resource Access Modes

Mission governance and resource access mode are independent. The security effect of a mission therefore depends on whether the PS is on the authorization path.¶

In every mode, the PS MUST apply the active-state gate to its own permission, audit, interaction, mission, and token operations when they reference a mission, as required by AAuth, except that an authenticated status or termination operation defined by a companion returns terminal state instead. In identity-based and resource-managed access, that PS-local gate does not stop an agent from making requests directly to a resource. Deployments MUST NOT claim PS issuance gating for those direct resource decisions.¶

A resource MUST NOT omit mission_s256 from a resource token it issues when the person token it verified carried one; AAuth makes a missing claim a protocol violation rather than permitted ignorance. An implementation MUST NOT infer that a resource evaluated mission context merely because a token carried the claim. Even a mission-aware Resource or Access Server receives only the reference and MUST NOT dereference it to obtain the private mission blob.¶

4.6. Transaction Authorization

This binding does not claim the transaction authorization capability. The Carrier Binding Floor of [I-D.draft-mcguinness-oauth-mission-transaction-authorization] names the slots a binding must provide to host action-bound transaction authorization, and several have no native home in AAuth or R3 today. Consistent with this document's rule that it adds no new AAuth wire members, it defines no extensions to close them; this section records the status informatively, so the gap is legible rather than implied.¶

A deployment could claim the capability only after the missing homes exist upstream and this binding additionally claims State-Observable unconditionally on the execution path (today conditional), and either Structured Authority or an equivalent resource-owned evaluation of the operation commitment (today not supported). Until then the execution gate and the authority evaluation the transaction invariants require have no source in this binding, and hosting the flow is unsupported.¶

4.7. Reference Propagation

An agent operating in a Mission Context names the mission when it requests a person token from its PS, and the PS stamps mission_s256 into the issued person token. A resource that verifies that person token MUST copy mission_s256 into the resource token it issues. When an auth token is issued in the mission context, it carries the same flat mission_s256 claim, copied onward from the resource token.¶

This binding adds no member alongside that claim. The namespace once carried by approver is carried by the person token's iss and the resource token's ps. Receivers MUST NOT require mission_id, issuer, policy_version, intent_hash, authority_hash, proposal_hash, or embedded authorization details for conformance to this binding.¶

Each copying party MUST preserve mission_s256 exactly. A PS receiving a resource token with a mission reference MUST verify that ps identifies itself before using local mission state. Token verifiers MUST perform the AAuth issuer, audience, agent, key, and request-binding checks in addition to comparing the reference.¶

The presence of a reference establishes correlation, not authorization. Authorization still depends on the issuer's decision, the token's scopes and other claims, proof of possession, resource policy, and, where the PS is on path, the PS's current contextual governance decision.¶

AAuth no longer treats a stripped mission as permitted downgrade: a resource MUST NOT omit mission_s256 from a resource token when the person token it verified carried one, and a PS MUST resolve the resource token's identified person token by person_token_jti and reject any mismatch or omission against that person token's mission_s256. That base rule is what makes stripping detectable; comparing claims by agent and resource alone cannot, because an agent running concurrent missions holds more than one person token for the same resource, and only the named person token resolves to one. This binding keeps two further local rules on top of it. An agent operating under a mission MUST verify that a returned resource token carries the exact mission_s256, and MUST NOT continue that authorization under the mission when it is absent or different. A PS whose policy places an agent under mission governance MUST reject a missionless token request from that agent. The Lifecycle-Gated Authorization and Credential-Bound claims of Section 9 cover only requests whose resource token carries the protected mission_s256 claim.¶

4.8. Lifecycle

An AAuth Mission Context has exactly the two native states:¶

active:

The agent can submit governed requests under the mission. Each request remains subject to a fresh PS decision and any resource policy.¶

terminated:

The mission is permanently ended. The PS MUST reject governed requests that reference it with AAuth's mission_terminated error, and the agent MUST stop acting under it. An authenticated status or termination operation defined by a companion returns terminal state instead (Section 4.3).¶

Completion follows AAuth's interaction flow: the agent proposes completion with a summary, the PS presents it to the person, and the mission terminates only if the person accepts. Other termination causes and administrative mechanisms are left to AAuth mission-management work. A deployment can record a termination reason in its private log without creating another protocol state.¶

Every mission approved under this binding MUST carry AAuth's expires_at member, and the PS MUST enforce it on every decision path as AAuth requires. When a proposal omits an expiry, the PS MUST set one at approval under deployment policy, and that policy SHOULD prefer the shortest expiry consistent with the mission's purpose. Expiry transitions the mission to terminated; it adds no third state, and no token carrying mission_s256 outlives the mission's approved expires_at. AAuth distinguishes an expiry-caused termination with a termination_reason of expired, surfaced where a management companion exposes it, rather than with a separate error status. An early completion, revocation, or administrative termination prevents new governed issuance; an outstanding token remains usable until revocation or its own expiry, inside that approved bound.¶

There is no suspended state in this binding. A short wait uses AAuth's deferred-response mechanism. A long or materially changed pause is handled by terminating the old mission and approving a new, appropriately scoped mission while retaining the old log for audit.¶

Termination prevents new governed issuance and PS operations. It does not retroactively erase a previously issued credential or guarantee that all independently authorizing resources learn the state immediately. Short token lifetimes bound this residual window in PS-asserted and federated modes. A resource needing stronger termination latency requires an additional revocation or event mechanism.¶

6.1. Reference Substitution and Blob Integrity

An attacker can attempt to replace either approver or s256, attach a valid reference to a different agent, or present uncommitted JSON as the approved blob. The decoded-bytes digest check, signed person-token carriage of mission_s256, signed resource and auth tokens, agent-token verification, and proof-of-possession binding are all necessary defenses.¶

The agent MUST reject an approval response when the digest of the decoded mission bytes differs from s256. The PS MUST resolve a reference only in its own approved-mission store and MUST verify the authenticated agent's right to use it. Resources and Access Servers MUST NOT fetch a blob from an attacker-selected approver URL; AAuth forbids dereferencing the reference.¶

6.2. Confused-Deputy and Audience Checks

A reference is not a bearer capability. Accepting it without verifying the surrounding AAuth request or token can let an attacker borrow another mission's context or cause a decision to be logged against the wrong mission. Parties MUST perform all AAuth audience, issuer, signing-key, agent, confirmation-key, and request-context checks before associating a request with a Mission Context.¶

In federated access, the PS and Access Server retain distinct policy roles. The PS MUST validate the resource token and govern the request before federation. The Access Server MUST validate its inputs and apply resource policy; it cannot assume that a valid mission reference defines the requested resource authority.¶

6.3. Agent Compromise

Compromise of an agent and its signing key enables the attacker to make requests that appear to come from that agent while its tokens and missions remain usable. Mission governance can reduce the effect where the PS sees the request: the PS can compare justifications and behavior with the approved context and log, request clarification, or deny new issuance. It does not make the compromised agent trustworthy.¶

In identity-based or resource-managed access, the attacker can contact a resource without passing through the PS. Mission termination alone cannot stop such access. Agent-token revocation, key rotation, resource policy, resource-managed credential invalidation, and incident response remain necessary.¶

PSes SHOULD support anomaly detection over the mission log, minimize credential lifetimes, and make termination available to the person and authorized administrators through applicable AAuth mechanisms.¶

6.4. Person Server Compromise

The PS is the controlling authority and holds the private mission blob, the person relationship, and the PS-observed governance log. A compromised PS can approve false missions, misrepresent state, disclose sensitive context, issue PS-asserted auth tokens, or broker requests to Access Servers. AAuth signature verification does not protect against a malicious legitimate PS signing key.¶

Deployments SHOULD protect PS signing keys and mission stores with appropriate isolation, access control, backup, monitoring, and recovery procedures. Log integrity controls SHOULD make deletion, reordering, or alteration detectable. Separating administrative access from online token-issuance privileges reduces the compromise blast radius.¶

6.5. Log Integrity and Availability

The mission log is an input to future governance decisions and an audit record. Missing, reordered, or injected entries can change a PS decision or hide misuse. The PS SHOULD assign stable ordering information, authenticate the source of entries, retain decision outcomes and relevant token identifiers, and make retention behavior clear to the person.¶

The log can also be used for denial of service. PSes SHOULD bound entry size, clarification rounds, request rates, and retention while preserving the records needed for active governance and incident investigation. Availability loss at the PS prevents new PS-asserted and federated authorizations; it does not necessarily stop identity-based or resource-managed access.¶

6.6. Prompt Injection and Untrusted Text

Mission descriptions, tool descriptions, justifications, clarification messages, and audit content are untrusted input. A PS that presents them to a person or an AI decision-maker MUST sanitize rendered Markdown and SHOULD clearly separate agent-supplied content from trusted policy and system instructions.¶

An AI-assisted decision-maker MUST NOT treat text in a mission or log as authority to alter verification rules, reveal secrets, bypass policy, or invoke tools. Deterministic checks on tokens, signatures, identities, scopes, and state remain outside the natural-language decision context.¶

11.1. Normative References

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

Hardt, D., "AAuth Protocol", 2026, <https://dickhardt.github.io/AAuth/draft-hardt-oauth-aauth-protocol.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>.

11.2. Informative References

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

Hardt, D., "AAuth Rich Resource Requests (R3)", 2026, <https://dickhardt.github.io/AAuth/draft-hardt-aauth-r3.html>.

[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-management]

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