Network Working Group K. McGuinness
Internet-Draft Independent
Intended status: Standards Track 10 August 2026
Expires: 11 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 11 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. Relationship to Mission Substrate Work
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. 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 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.
3.3.1. Approved Tools
approved_tools identifies local actions that the agent can take
without calling the PS permission endpoint for every invocation.
Examples include a local tool call, a file write, or sending a
message. The PS still uses the mission context and mission log for
governance.
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 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.
+==================+===============================================+
| 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. 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; 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. 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.
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; 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 PS operation that
references a mission;
* 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 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.
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.
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. Relationship to Mission Substrate Work
This section is informative.
The Mission substrate work [I-D.draft-mcguinness-mission-substrate]
describes concepts intended to span authorization systems. This
binding is self-contained and does not depend on a particular
revision of that document.
For cross-system comparison, AAuth supplies a stable reference,
controlling authority, agent binding, immutable approved context,
approval event, active-state gate, reference propagation, and ordered
governance history. It does not natively supply portable structured
authority or universal monotonic derivation. Those capabilities are
orthogonal rather than prerequisites for calling the approved AAuth
context a mission.
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,
.
11.2. Informative References
[I-D.draft-hardt-aauth-r3]
Hardt, D., "AAuth Rich Resource Requests (R3)", 2026,
.
[I-D.draft-mcguinness-mission-substrate]
McGuinness, K., "Mission Substrate Requirements", 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