Network Working Group K. McGuinness
Internet-Draft Independent
Intended status: Standards Track 12 August 2026
Expires: 13 February 2027
Mission Context Binding for AAuth
draft-mcguinness-mission-aauth-latest
Abstract
AAuth defines missions as optional, immutable authorization contexts
for agent governance at a Person Server. A mission is approved
through AAuth's native propose, clarify, and approve interaction, is
identified by the native approver and s256 reference, and accumulates
an ordered mission log. This document describes how those native
facilities realize a Mission Context binding without adding a second
mission identifier, a portable authority language, or new AAuth wire
members.
This binding preserves AAuth's separation between contextual
governance at the Person Server and deterministic resource
authorization through scopes, resource tokens, resource and Access
Server policy, and optionally R3. It also identifies where active-
state issuance gating is structural and where a mission reference is
only advisory context.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://mcguinness.github.io/mission-bound-authorization/draft-
mcguinness-mission-aauth.html. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-mcguinness-
mission-aauth/.
Source for this draft and an issue tracker can be found at
https://github.com/mcguinness/mission-bound-authorization.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Contextual Governance, Not Portable Authority
1.2. Scope
2. Conventions and Terminology
3. AAuth Mission Context Model
3.1. Capability Model
3.2. Native Reference and Exact-Byte Commitment
3.3. Mission Blob
3.3.1. Approved Tools
4. Protocol Binding
4.1. Roles
4.2. Proposal, Clarification, and Approval
4.3. Governed Requests and Mission Log
4.4. Deterministic Resource Authorization
4.5. Resource Access Modes
4.6. Reference Propagation
4.7. Lifecycle
5. Conformance
6. Security Considerations
6.1. Reference Substitution and Blob Integrity
6.2. Confused-Deputy and Audience Checks
6.3. Agent Compromise
6.4. Person Server Compromise
6.5. Log Integrity and Availability
6.6. Prompt Injection and Untrusted Text
7. Privacy Considerations
8. Operational Considerations
9. Mission Substrate Statement
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Acknowledgments
Author's Address
1. Introduction
The AAuth protocol [I-D.draft-hardt-oauth-aauth-protocol] gives
agents independent cryptographic identities and supports four
resource access modes: identity-based, resource-managed, Person
Server (PS)-asserted, and federated. Agent governance is orthogonal
to those modes.
AAuth already defines the protocol elements needed for a durable
Mission Context:
* the agent proposes a natural-language mission to its PS;
* the PS and person can clarify and refine the proposal before
approval;
* the approved mission blob is immutable and identified by the
native pair of approver and s256;
* signed resource requests and AAuth tokens can carry that
reference;
* the PS evaluates requests using the approved context and the
ordered mission log; and
* a mission is either active or permanently terminated.
This document is a thin binding over those facilities. Beyond
requiring the expires_at member of AAuth Mission Expiry
([I-D.draft-mcguinness-aauth-mission-expiry]), it defines no new
AAuth endpoint, header field, token claim, mission-blob member, or
lifecycle state. Its purpose is to make the security and composition
properties of AAuth missions explicit and to prevent an OAuth-
specific authority model from being imposed on them.
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.
2. Conventions and Terminology
The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*,
*SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *NOT RECOMMENDED*, *MAY*, and
*OPTIONAL* in this document are to be interpreted as described in BCP
14 when, and only when, they appear in all capitals as shown here.
This document uses the AAuth terms _agent identifier_, _Person
Server_, _mission blob_, _mission reference_, _resource token_, _auth
token_, _approved tools_, and _mission log_ as defined by
[I-D.draft-hardt-oauth-aauth-protocol].
For this binding:
Mission Context: The immutable approved mission blob, its native
mission reference, its current active or terminated state, and the
ordered mission log used by the PS when governing an agent's work.
Controlling authority: The PS identified by the mission reference's
approver value. The PS performs approval, stores the mission
context, evaluates governed requests, and controls the mission's
active state.
Context propagation: Carrying the native mission reference across an
AAuth interaction. It does not by itself grant resource authority
or prove that the receiving party evaluated the mission contents.
Issuance gating: Refusing to issue or broker a fresh credential when
the referenced mission is not active.
3. AAuth Mission Context Model
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} 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.
Bounded reliance: Every mission carries expires_at (Section 4.7),
the PS establishes active at decision time, and no auth token's
exp exceeds the mission's expires_at.
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,
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 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. Under this binding the
blob also carries the expires_at member, defined by AAuth Mission
Expiry [I-D.draft-mcguinness-aauth-mission-expiry] and required by
Section 4.7. This binding itself 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.
3.3.1. Approved Tools
approved_tools identifies agent tool invocations that do not require
a per-call decision at the PS permission endpoint. Examples include
a tool call, a file write, or sending a message; a tool can invoke
remote infrastructure, so the exemption is from the per-call
permission request, not a locality claim. The PS still uses the
mission context and mission log for governance: approved_tools is
structured PS-governance input, not portable resource authority.
An approved tool is not, by that fact alone, authority at a remote
resource. This binding therefore does not map an approved tool name
or description to a resource identifier, scope, authorization detail,
or R3 operation. Remote resource access follows AAuth's resource
access protocol and the resource's own authorization semantics.
4. Protocol Binding
4.1. Roles
The AAuth roles map to the Mission Context model as follows:
+==========+========================================================+
| AAuth | Mission Context responsibility |
| role | |
+==========+========================================================+
| Agent | Proposes work, verifies and stores the |
| | approved blob, carries the native |
| | reference, supplies justifications, |
| | and records actions as AAuth requires. |
+----------+--------------------------------------------------------+
| Person | Acts as controlling authority, |
| Server | conducts approval and clarification, |
| | stores state and the mission log, and |
| | governs requests on PS endpoints. |
+----------+--------------------------------------------------------+
| Person | Reviews, clarifies, approves, and |
| | accepts completion through the PS. |
+----------+--------------------------------------------------------+
| Resource | Defines and enforces its resource |
| | authorization; when mission-aware, |
| | preserves the native reference as |
| | AAuth specifies. |
+----------+--------------------------------------------------------+
| Access | Evaluates resource policy and issues |
| Server | auth tokens in federated access; it |
| | does not evaluate the private mission |
| | blob. |
+----------+--------------------------------------------------------+
Table 1
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 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.
+==================+==============================================+
| Resource access | Mission Context behavior |
| mode | |
+==================+==============================================+
| Identity-based | The resource authorizes the signed agent |
| | identity directly. A mission reference can |
| | be sent to a mission-aware resource, but the |
| | PS does not gate that resource decision and |
| | the resource can ignore the reference. |
+------------------+----------------------------------------------+
| Resource-managed | The resource manages authorization directly. |
| | A mission reference can provide context, but |
| | the PS does not gate the resource's issuance |
| | or decision and the resource can ignore the |
| | reference. |
+------------------+----------------------------------------------+
| PS-asserted | The resource token is presented to the PS, |
| | which evaluates the active Mission Context |
| | before it issues an auth token. PS issuance |
| | gating is structural for a request whose |
| | resource token carries the validated Mission |
| | Reference (Section 4.6). The resource still |
| | applies its own resource policy. |
+------------------+----------------------------------------------+
| Federated | The PS evaluates the active Mission Context |
| | before it federates the request to the |
| | resource's Access Server and before |
| | returning the resulting auth token. PS |
| | broker gating is structural under the same |
| | condition; the Access Server independently |
| | applies resource policy. |
+------------------+----------------------------------------------+
Table 2
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 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.
Mission propagation is downgradable by an intermediate that does not
echo the reference: AAuth's token request carries the mission only
inside the presented resource token, so a resource that ignores
AAuth-Mission yields a missionless token request at the PS. Three
rules bound that downgrade. An agent that sent AAuth-Mission MUST
verify that the returned resource token carries the exact reference;
if it is absent or different, the agent MUST NOT continue that
authorization as part of the mission. A PS whose policy places an
agent under mission governance MUST reject a token request from that
agent that carries no mission reference. The Lifecycle-Gated
Authorization and Credential-Bound claims of Section 9 cover only
requests whose resource token carries the protected, validated
reference.
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
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 the expires_at
member defined by AAuth Mission Expiry
[I-D.draft-mcguinness-aauth-mission-expiry], and the PS MUST enforce
it as that extension specifies. 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 auth token's exp exceeds the mission's approved
expires_at. 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.
5. Conformance
An implementation conforms as an *AAuth Mission Context Agent* if it:
* implements AAuth mission proposal and approval;
* verifies and preserves the exact approved blob bytes;
* uses only the native {approver, s256} reference;
* carries and signs that reference as AAuth requires;
* stops using a mission after mission_terminated;
* initiates no new governed work at or after the mission's
expires_at; and
* does not treat mission approval or approved_tools as remote
resource authority.
An implementation conforms as an *AAuth Mission Context Person
Server* if it:
* implements AAuth proposal, clarification, approval, and
completion;
* binds the approved blob to the authenticated agent identifier;
* maintains the native active or terminated state and ordered
mission log;
* applies the active-state gate to every governed PS operation that
references a mission, while an authenticated status or termination
surface defined by a companion returns terminal state instead;
* approves no mission without expires_at and enforces it as AAuth
Mission Expiry [I-D.draft-mcguinness-aauth-mission-expiry]
specifies;
* evaluates resource-token requests in mission context when it
issues or brokers auth tokens; and
* does not expose the private mission blob to Resources or Access
Servers.
An implementation conforms as a *mission-aware Resource or Access
Server* if it preserves and validates the native reference as
required by AAuth and does not claim to have evaluated the private
mission description. Support by a Resource or Access Server is not
required for agent-and-PS conformance.
This document intentionally makes no "full" or "partial" provision
claim. Conformance states which capabilities are present; it does
not rank AAuth by similarity to an OAuth authorization model.
6. Security Considerations
The security considerations of AAuth apply. This section highlights
properties specific to treating an AAuth mission as a Mission
Context.
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 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.
7. Privacy Considerations
The exact mission blob can contain sensitive intent, planned actions,
tool use, organizational context, and person interactions. AAuth's
reference-only design keeps the blob between the agent and PS.
Resources and Access Servers receive the opaque {approver, s256}
reference and MUST NOT dereference it.
The stable reference is nevertheless a correlation handle. Reusing
it across resources reveals that requests belong to the same mission
and reveals the PS hostname. Agents SHOULD attach a Mission Context
only when its governance and correlation benefits justify that
disclosure. Resources, Access Servers, and logs SHOULD retain the
reference only as long as needed for authorization, security, dispute
resolution, or legal obligations.
The mission log centralizes a detailed history at the PS. PS
operators SHOULD minimize recorded personal data, separate token
identifiers from raw token material, define retention and deletion
policies, protect log access, and give the person meaningful
visibility into the retained history. Termination does not itself
require erasure because the log can be needed for audit and incident
response.
Pairwise subject identifiers and other AAuth privacy mechanisms
remain applicable. This binding does not replace them with the agent
identifier or mission reference. Where the deployment uses pairwise
or directed person identifiers, the PS MUST maintain the mapping from
each directed identifier to the mission's person, so accountability
and the person's visibility into the retained history survive the
pairwise boundary.
8. Operational Considerations
PS-asserted and federated deployments SHOULD use short-lived auth
tokens so that a terminated mission stops supporting fresh
authorization within a bounded period. Operators SHOULD document
that bound and distinguish it from immediate revocation.
Agents SHOULD retain the exact mission blob and log enough local
correlation data to diagnose mismatched references, but SHOULD NOT
copy the private blob into resource requests, telemetry, exception
messages, or general application logs.
Implementations SHOULD expose the native mission state and completion
flow consistently with AAuth. Additional administrative APIs, event
delivery, signed evidence, or R3 decision bindings require separately
specified capabilities and trust relationships; their absence does
not change conformance to this binding.
9. Mission Substrate Statement
This section is this binding's Mission Substrate Statement and
declares conformance to [I-D.draft-mcguinness-mission-substrate]. It
applies to this revision of the binding in every resource access mode
of Section 4.5; mode-specific limits appear in the capability table.
The contextual-governance kernel maps as follows:
1. *Mission Reference*: the native pair {approver, s256}. approver
is the uniqueness namespace, s256 is compared as the exact
unpadded base64url digest of the approved bytes, a changed blob
is a different mission, a reference is never reassigned,
retention follows the mission log's declared period, and the
reference is unguessable to parties that do not hold the private
blob (Section 3.2, Section 4.3).
2. *Controller*: the PS identified by approver controls approval,
governance state, and the mission log (Section 4.1). Consumers
establish its identity and keys from AAuth's published PS
metadata and key set ([I-D.draft-hardt-oauth-aauth-protocol]).
3. *Actor binding*: the blob's agent member names the AAuth agent
identifier, authenticated by its agent token and HTTP message
signatures; parent-mediated and call-chaining relationships are
the only delegations, and the identifier maps to no OAuth
client_id (Section 3.3, Section 4.1).
4. *Approved Context*: the private approved mission blob, immutable
under the exact-byte s256 commitment; it is never disclosed to
Resources or Access Servers. Both governance parties retain the
blob, satisfying the kernel's maintained-value branch; s256 is
verification material for holders, and algorithm migration
follows AAuth (Section 3.3, Section 3.2).
5. *Approval ceremony*: the AAuth propose, clarify, and approve
interaction creates the approved blob and the active mission
atomically (Section 4.2).
6. *Governance gate*: only active permits governed PS processing;
terminated is permanent, and an unrecognized state is not active.
Person-accepted completion and the mission's expires_at are the
base transitions; administrative termination is supplied by AAuth
Mission Management where deployed (Section 4.7).
7. *Reliance bound*: every mission carries expires_at (Section 4.7,
[I-D.draft-mcguinness-aauth-mission-expiry]); PS decisions
establish active at decision time, no auth token's exp exceeds
the mission's expires_at, and the residual after a transition is
bounded by outstanding token lifetime.
8. *Context propagation*: the signed native reference in AAuth
headers and claims carries governance context; the blob itself
never propagates; coverage varies by access mode (Section 4.6,
Section 4.5).
9. *Governance record*: the PS mission log is the ordered governance
record, scoped to PS-observed operations with agent-reported
local activity distinguished, and with the coverage, ordering,
integrity, access, and retention requirements of Section 4.3.
The binding declares these optional capabilities:
+=============+===========+=================================================+=============+
|Capability |Claim |Scope and defining sections |Limitations |
+=============+===========+=================================================+=============+
|Lifecycle- |supported |Mission approval and other positive governance |Independently|
|Gated | |decisions at the mission endpoint, permission |issued |
|Authorization| |decisions, and auth-token issuance the PS |resource |
| | |performs or brokers for requests carrying the |credentials |
| | |validated Mission Reference; decisions fail |and |
| | |closed when current state cannot be established |missionless |
| | |(Section 4.7, Section 4.5, Section 4.3) |token |
| | | |requests are |
| | | |outside the |
| | | |claim |
| | | |(Section |
| | | |4.6); the |
| | | |post- |
| | | |transition |
| | | |residual is |
| | | |bounded by |
| | | |auth-token |
| | | |lifetime and |
| | | |expires_at |
+-------------+-----------+-------------------------------------------------+-------------+
|State- |conditional|The AAuth Mission Management status operation |The base |
|Observable | |where deployed: authenticated per-role callers, |binding |
| | |the active and terminated vocabulary, responses |exposes no |
| | |stamped observed_at with a declared fresh_until |consumer- |
| | |reliance bound, failing closed on failed, |facing state |
| | |unrecognized, or stale responses, absent and |source; token|
| | |unauthorized references indistinguishable |acceptance is|
| | |([I-D.draft-mcguinness-mission-aauth-management])|not |
| | | |observation |
+-------------+-----------+-------------------------------------------------+-------------+
|Structured |not |The mission description is private prose; |Scopes or a |
|Authority |supported |approved_tools is PS-governance input |resource- |
| | | |owned policy |
| | | |language can |
| | | |supply |
| | | |structure |
| | | |inside its |
| | | |own boundary |
+-------------+-----------+-------------------------------------------------+-------------+
|Monotonic |not |No cross-boundary subset relation is defined |A resource |
|Derivation |supported | |policy |
| | | |language can |
| | | |define |
| | | |monotonicity |
| | | |within its |
| | | |own |
| | | |vocabulary |
+-------------+-----------+-------------------------------------------------+-------------+
|Credential- |conditional|PS-asserted and federated modes carry and |Identity- |
|Bound | |validate the signed native reference in PS-issued|based and |
| | |or PS-brokered artifacts, a binding established |resource- |
| | |at issuance rather than by an external join, for |managed modes|
| | |requests whose resource token carries the |convey no |
| | |validated reference (Section 4.5, Section 4.6) |mission |
| | | |binding; |
| | | |federated |
| | | |artifacts are|
| | | |AS-issued |
| | | |under the |
| | | |PS's |
| | | |brokering |
+-------------+-----------+-------------------------------------------------+-------------+
|Independently|not |s256 proves byte identity to parties holding the |It does not |
|Verifiable |supported |blob |prove record |
| | | |properties or|
| | | |current state|
| | | |to third |
| | | |parties |
+-------------+-----------+-------------------------------------------------+-------------+
|Portable |not |The mission log is PS-local |Signed |
|Evidence |supported | |receipts or |
| | | |checkpoints |
| | | |would be an |
| | | |extension |
+-------------+-----------+-------------------------------------------------+-------------+
Table 3: AAuth Mission substrate capabilities
10. IANA Considerations
This document requests no IANA actions. It uses only protocol
elements defined by [I-D.draft-hardt-oauth-aauth-protocol] and
defines no new header field, structured-field parameter, JWT claim,
token member, metadata member, error code, capability value, or
registry value.
11. References
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,
.
[I-D.draft-mcguinness-aauth-mission-expiry]
McGuinness, K., "AAuth Mission Expiry", 2026,
.
[I-D.draft-mcguinness-mission-substrate]
McGuinness, K., "Mission Substrate Requirements", 2026,
.
11.2. Informative References
[I-D.draft-hardt-aauth-r3]
Hardt, D., "AAuth Rich Resource Requests (R3)", 2026,
.
[I-D.draft-mcguinness-mission-aauth-management]
McGuinness, K., "AAuth Mission Management", 2026,
.
Appendix A. Acknowledgments
The author thanks the AAuth community for defining a mission model in
which contextual governance, deterministic resource authorization,
and incremental deployment remain distinct concerns.
Author's Address
Karl McGuinness
Independent
Email: public@karlmcguinness.com