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 of the approving PS and s256 is this binding's Mission Reference (Section 3.2), with s256 compared within the approving PS's namespace. No additional mission_id is needed or defined.¶

Controlling authority:

The approving PS is responsible for approval and governance. No separate Mission issuer field names it.¶

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 the person tokens and auth tokens the PS issues at it (Section 4.8); the PS still establishes active at decision time, including when it acts on a resource token, whose lifetime is independent of expires_at.¶

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 pair of the approving PS and s256 is this binding's Mission Reference: AAuth's mission identity (Section 8.2.1 of [I-D.draft-hardt-oauth-aauth-protocol]). The approving PS is named by the iss of a person token, the ps claim of a resource or auth token, or the PS a request is made to; the blob carries no member naming it. On the wire the reference is the mission_s256 claim or parameter.¶

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

The reference is an integrity commitment, not a secret. It is a deterministic digest of the blob bytes, so a party that can predict the blob's content can confirm a guess; the digest's length says nothing about the entropy of its input. This binding confines the reference instead: every PS surface keyed by it authenticates the caller and does not disclose whether a mission exists. The mission endpoint does so natively (Section 8.7 of [I-D.draft-hardt-oauth-aauth-protocol]), the management control plane by its anti-oracle rules ([I-D.draft-mcguinness-mission-aauth-management]), and the auth token endpoint because a resource token's reference is checked against the agent's own presented token before any state check (Section 6.7.2 of [I-D.draft-hardt-oauth-aauth-protocol]). AAuth's mission status error carries no ownership condition (Section 8.8 of [I-D.draft-hardt-oauth-aauth-protocol]), so at a PS endpoint that takes a mission_s256 parameter, a PS MUST establish that the mission belongs to the requesting agent before reporting its state. For an absent mission and a mission belonging to another agent, the PS MUST return the same status, error, body, and header set, with observably equivalent timing.¶

Possession of the reference, or a correct guess, conveys no authority over status, logs, or management. A deployment that claims stronger unpredictability documents its added entropy construction and its retention consequences; this binding defines no member for it.¶

3.3. Mission Blob

The approved mission blob uses the members defined by AAuth, including agent, approved_at, and description, and optionally approved_tools and approved_resources (Section 8.2 of [I-D.draft-hardt-oauth-aauth-protocol]). 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 agent member identifies the requesting agent, and record as the approving PS the PS whose mission_endpoint received the proposal; 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 PS the reference names;¶

• 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 control-plane 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, accepted updates, permission decisions, audit records, interaction requests, clarification chats, and the supervision decisions made (Section 8.3 of [I-D.draft-hardt-oauth-aauth-protocol]). 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. An accepted update at the mission's own URL is one such entry, digested by its own s256; it changes neither the blob nor mission_s256 (Section 8.4 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

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 own policy in agent identity access;¶

• the resource-managed authorization result;¶

• scopes in resource and auth tokens;¶

• resource policy in PS authorization 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 agent identity 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 presented token it verified carried one; AAuth makes a missing claim a protocol violation rather than permitted ignorance (Section 6.7.1 of [I-D.draft-hardt-oauth-aauth-protocol]). 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. R3 supplies per-call authorization in its own terms ([I-D.draft-hardt-aauth-r3]); the gap is to the family's stronger transaction profile. The table classifies each slot as supplied, supplied conditionally, unproven equivalence, or absent, and names the signed native field and verifier step that supply it. Its section numbers refer to [I-D.draft-hardt-oauth-aauth-protocol], or to [I-D.draft-hardt-aauth-r3] where marked R3; the management status operation is that of [I-D.draft-mcguinness-mission-aauth-management]. Consistent with this document's rule that it adds no new AAuth wire members, it defines no extensions to close a gap.¶

The R3 parameter commitment is not shown to be equivalent to parameter_digest ([I-D.draft-mcguinness-mission-runtime]). R3 commits to the parameters exactly as the resource serialized them in the proposal, and under 401 compares the retried call to them by JSON value equality or by the digest of a presented value. parameter_digest is a digest of a normalized parameter object: an Operation Profile fixes default insertion, omitted optional fields, and set-like arrays, and every parameter that influences the action's external effect enters it. The two coincide for one resource operation only when the resource's proposal carries every effect-bearing parameter in that normalized form, which neither R3 nor this binding requires. Under 202 the held call itself is executed, so no parameter can be substituted, but no digest exists for another verifier to recompute. This binding defines no second canonicalization to close the gap.¶

R3 also lets a resource seek approval to release a result it has already computed, rather than approval to execute (Section 10.4 of [I-D.draft-hardt-aauth-r3]). That approval gates disclosure, not execution. The floor's invariants concern pre-execution approval, so a release-gated call is outside this mapping, and approving release is never treated as approving execution.¶

The slots without a native home are operation supersession, parameter equivalence, a declared pending-workflow lifetime, the 401 workflow handle and admission idempotency, a distinguishable result class, an issuance guard giving one result per transaction instance, and an unconditional current-state source. A deployment could claim the capability only after those exist upstream and this binding additionally claims State-Observable unconditionally on the execution path (it is claimed conditionally), and either Structured Authority or an equivalent resource-owned evaluation of the operation commitment (not supplied). 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 (Section 7.1 of [I-D.draft-hardt-oauth-aauth-protocol]). A resource that verifies a presented token (a person token or an auth token) carrying mission_s256 MUST copy it into the resource token it issues, which names that presented token in presented_jti (Section 6.7.1 of [I-D.draft-hardt-oauth-aauth-protocol]). When an auth token is issued in the mission context, its issuer (the PS, or the AS in four-party access) copies the same flat mission_s256 claim onward from the resource token (Section 9.4.1 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

This binding adds no member alongside that claim. The approving PS that scopes it is named as Section 3.2 describes. 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 does not treat a stripped mission as permitted downgrade: a resource MUST NOT omit mission_s256 from a resource token when the presented token it verified carried one, and a PS MUST verify the presented_token the agent forwards against the resource token, its jti against presented_jti and its mission_s256 against the resource token's, and reject any mismatch or omission (Sections 6.7.2 and 7.2.1 of [I-D.draft-hardt-oauth-aauth-protocol]). In four-party access the AS performs the same verification (Section 9.1.1 of [I-D.draft-hardt-oauth-aauth-protocol]). 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 presented token identifies one. The check uses no retained record on the request path; the PS's record of the person tokens it issues serves revocation (Section 7.1 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

This binding keeps 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.¶

AAuth lists an AS-issued auth token's mission_s256 among its optional claims, and the PS's delivery checks do not include it (Sections 9.4.1 and 9.1.3 of [I-D.draft-hardt-oauth-aauth-protocol]). In four-party access, before returning an AS-issued auth token to the agent, a PS MUST verify that the token carries the resource token's mission_s256 exactly whenever the resource token carried one. A token that fails this check fails the PS's delivery verification, and the PS answers as_unreachable (Section 9.1.3 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

A request's Mission association is required when that policy applies or when the request derives from a presented token or upstream token that carries mission_s256. A required association that is missing, malformed, invalid, unresolvable, or mismatched fails the request under AAuth's own rules, in AAuth's order of checks:¶

• a malformed mission_s256 in a person token request receives invalid_request, and one naming a mission that does not exist or belongs to another agent is rejected (Section 7.1 of [I-D.draft-hardt-oauth-aauth-protocol]);¶

• a presented token that fails verification receives invalid_presented_token, or expired_presented_token when only its exp fails, which is how a Mission-bound token fails once expires_at passes (Sections 6.7.2 and 7.1.2 of [I-D.draft-hardt-oauth-aauth-protocol]);¶

• a resource token that omits or mismatches its presented token's mission_s256 receives invalid_resource_token (Section 6.7.2 of [I-D.draft-hardt-oauth-aauth-protocol]); and¶

• a request that reaches the mission-state check under a mission that is no longer active receives mission_terminated (Section 8.8 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

The PS, or the AS in four-party access, MUST NOT evaluate a failed request as missionless authorization, and the agent MUST NOT retry it without the reference.¶

Intentionally missionless authorization is a separate path, admitted by explicit deployment policy from the outset for requests with no required or inherited Mission association. It is never a fallback after Mission validation fails. It is outside the Lifecycle-Gated Authorization and Credential-Bound claims. Each claim's scope and activation conditions are stated in Section 9.¶

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 uses the completion action at {mission_endpoint}/{mission_s256}: the agent proposes completion with a summary, the PS presents it to the person, and the mission terminates with reason completed only if the person accepts (Section 8.5 of [I-D.draft-hardt-oauth-aauth-protocol]). The PS records why a mission terminated alongside the mission, from AAuth's open reason set of completed, revoked, expired, superseded, and administrative; a reason is never a protocol state (Section 8.6 of [I-D.draft-hardt-oauth-aauth-protocol]). A mission reaches terminated by accepted completion, by its expires_at, by PS revocation of the mission (Section 11.12.4 of [I-D.draft-hardt-oauth-aauth-protocol]), or by a control-plane operation at the mission_control_endpoint, which AAuth Mission Management [I-D.draft-mcguinness-mission-aauth-management] defines.¶

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. A proposal can request an expiry under AAuth Mission Expiry [I-D.draft-mcguinness-aauth-mission-expiry]; when it requests none, 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. The PS caps the person tokens and auth tokens it issues at expires_at (Sections 7.1.2 and 9.4.1 of [I-D.draft-hardt-oauth-aauth-protocol]), and the presented token carries that bound to an AS (Section 9.1.1 of [I-D.draft-hardt-oauth-aauth-protocol]). A resource token is a short-lived request artifact whose lifetime is independent of expires_at; the PS verifies that the mission is active and unexpired whenever it acts on one (Sections 6.7.1 and 6.7.2 of [I-D.draft-hardt-oauth-aauth-protocol]). AAuth distinguishes an expiry-caused termination with a termination_reason of expired in the mission_terminated error (Section 8.8 of [I-D.draft-hardt-oauth-aauth-protocol]), rather than with a separate error status. An early completion, revocation, or administrative termination prevents new governed issuance; an outstanding person token or auth token remains usable until revocation or its own expiry, inside that 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. In the modes that present a person token, short token lifetimes bound this residual window: a party that no revocation reaches is bounded by token lifetime alone, at most one hour for a person token or an auth token (Section 11.12.5 of [I-D.draft-hardt-oauth-aauth-protocol]). AAuth token revocation shortens the window where the token's recipient supports it (Section 11.12 of [I-D.draft-hardt-oauth-aauth-protocol]); a resource needing stronger termination latency requires an additional event mechanism.¶

6.1. Reference Substitution and Blob Integrity

An attacker can attempt to substitute the approving PS 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, the presented_jti binding of each resource token to one presented token whose mission_s256 it matches exactly (Section 6.7.2 of [I-D.draft-hardt-oauth-aauth-protocol]), 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 a location derived from the reference, such as one under the approving PS's identifier.¶

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 agent identity 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 auth tokens in PS authorization access, 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 person tokens and new PS authorization and federated authorization grants; it does not necessarily stop agent identity or resource-managed access, or person identity access on a person token already issued, which lives at most one hour (Section 7.1.1 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

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. On a consent surface, AAuth also requires the PS to distinguish resource-asserted from agent-asserted content and to attribute the latter to the agent (Section 7.4 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

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-11, 25 September 2026, <https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11>.

[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)", 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-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-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-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>.