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 provides the following Mission Context capabilities:¶

Stable native reference:

The pair {approver, s256} identifies the approved context. 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 response-body bytes of the approved mission blob. 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.¶

Context propagation:

AAuth's AAuth-Mission header and native mission claims carry 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 policy semantics, and portable evidence are not baseline properties of this binding. 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 s256 value is the unpadded base64url encoding of the SHA-256 digest of the exact mission-blob response-body bytes. The agent MUST verify the digest and preserve the bytes exactly as received, as required by AAuth. 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, 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 capabilities. This binding defines no additional members.¶

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 approved mission blob and the matching AAuth-Mission header. Before using the context, the agent MUST:¶

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

2. compute SHA-256 over the exact response-body bytes;¶

3. verify that the result equals the header'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 blob 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 carrying 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.¶

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 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. 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 that does not support missions ignores AAuth-Mission. An implementation MUST NOT infer that a resource evaluated mission context merely because the agent sent the header. 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. Reference Propagation

An agent operating in a Mission Context carries the native reference in the AAuth-Mission request header as specified by AAuth and covers that header with its HTTP Message Signature. A mission-aware resource copies the reference unchanged into the resource token. When an auth token is issued in the mission context, its native mission claim contains only approver and s256.¶

This binding adds no members to that claim. Receivers MUST NOT require mission_id, issuer, policy_version, intent_hash, authority_hash, or embedded authorization details for conformance to this binding.¶

Each copying party MUST preserve approver and s256 exactly. A PS receiving a resource token with a mission reference MUST verify that the approver value 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.¶

4.7. 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 requests that reference it with AAuth's mission_terminated error, and the agent MUST stop acting under it.¶

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

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 exact-byte digest check, signed AAuth-Mission header, 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 its exact body 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 complete 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", Work in Progress, Internet-Draft, draft-hardt-oauth-aauth-protocol-10, 2026, <https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/10/>.

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-mission-substrate]

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