---
title: "Mission-Bound AAuth Composition Profile"
date: "2026-06-06T13:00:00-07:00"
lastmod: "2026-06-06T13:00:00-07:00"
description: "A composition profile between AAuth's native Mission model and Mission-Bound governance. It preserves AAuth's protocol while adding the mappings, authority commitment, lifecycle projection, status, and audit contracts needed for shared governance."
summary: "AAuth already has a native Mission: a Person Server approves an immutable mission blob, returns its approver and hash through AAuth-Mission, and evaluates later requests in that context. This profile defines only the composition delta: mapping the native reference to a governance Mission, committing typed authority, projecting richer lifecycle state, exposing Mission Status, and optionally sharing one Mission Authority Server with OAuth."
slug: "mission-bound-aauth"
tags:
- "AAuth"
- "OAuth"
- "Authorization"
- "Agentic Identity"
- "Mission-Bound Authorization"
- "Internet-Draft"
series:
- "mission-bound-authorization"
---
# Abstract
**On the spine:** Part 4 maps the **Mission** and **Authority** steps onto AAuth. Intent shaping remains generic ([Part 2](/notes/mission-shaper-profile/)); runtime enforcement remains substrate-independent ([Part 6](/notes/mission-bound-runtime-enforcement-profile/)).
[AAuth](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/01/) already defines a native Mission model. An agent submits a proposal to the Person Server's mission endpoint. On approval, the Person Server returns an immutable mission blob and an `AAuth-Mission` header containing the approver and a SHA-256 digest of the exact response body. Later resource, permission, interaction, audit, and call-chaining requests carry or transcribe that Mission context.
The series argues that the task the user approved should be a first-class governance object. AAuth already reaches that conclusion in its own protocol. The composition problem is therefore not how to add a Mission, but how to relate AAuth's native Mission to the typed, cross-substrate governance model used elsewhere in the series.
The profile preserves AAuth's wire protocol and defines:
- how AAuth's `approver` and `s256` identify the native Mission;
- how the native mission blob maps to Mission Intent and approval evidence;
- how AAuth resource and auth tokens preserve the native Mission reference;
- how richer governance state projects into AAuth's deliberate two-state lifecycle;
- how AAuth authority is committed without pretending it is OAuth `authorization_details`;
- how an optional [Mission Authority Server](/notes/mission-authority-server-profile/) lets OAuth and AAuth consume one governance record without erasing either substrate's native protocol.
# Scope
This is a delta profile. It assumes these AAuth-native surfaces:
- mission endpoint and proposal flow;
- approved mission blob;
- `AAuth-Mission` request and response header;
- Person Server approval and clarification;
- resource tokens and auth tokens;
- signed HTTP requests and proof-of-possession binding;
- Agent Provider-issued agent tokens;
- permission, interaction, and audit endpoints;
- call chaining and `upstream_token`;
- `active` and `terminated` Mission states.
It adds only the contracts needed for Mission-Bound governance:
1. a stable mapping between the AAuth Mission reference and a governance Mission reference;
2. a generic authority commitment with substrate-specific projections;
3. an explicit projection from richer governance state into AAuth's two native states, plus Mission Status where required;
4. audit and cross-substrate correlation rules;
5. the MAS topology, optional for AAuth-only use and required by this series for one canonical OAuth/AAuth Mission.
It does not define a universal operation vocabulary, a new AAuth credential, or a replacement Mission submission flow.
## Reused Substrate-Neutral Mechanics
This profile is a composition delta. Substrate-neutral mechanics defined elsewhere in the series apply unchanged when AAuth is the credential substrate; this post does not restate them.
- **Mission lifecycle and litmus test.** The seven-state machine, invariants, and Mission Expansion are defined in [Part 1](/notes/the-mission-is-the-missing-abstraction/#mission-lifecycle); the [litmus test](/notes/the-mission-is-the-missing-abstraction/#what-makes-something-a-mission) for "what makes something a Mission" applies to AAuth-substrate Missions that satisfy this composition profile. The [Lifecycle Composition](#lifecycle-composition) section below specifies only how those states project onto AAuth's native two-state model.
- **Lethal Trifecta Boundary.** [Part 3](/notes/mission-bound-oauth-profile/#lethal-trifecta-boundary) and [Part 6](/notes/mission-bound-runtime-enforcement-profile/#lethal-trifecta-control) define the derivation-time and execution-time controls. The arguments apply unchanged on AAuth; only the credential and policy surfaces differ.
- **Validation Layers, Architectural Challenges, State Synchronization Scale.** [Part 3's Architectural Challenges](/notes/mission-bound-oauth-profile/#architectural-challenges) covers state freshness, unknown-constraint brittleness, and stale-Mission concerns that transcend the credential format.
- **Runtime enforcement contract.** [Part 6](/notes/mission-bound-runtime-enforcement-profile/) defines the PDP contract substrate-independently. The [Runtime Enforcement](#runtime-enforcement) section below specifies only what an AAuth adapter supplies; PDP semantics, evidence shape, policy freshness, and parameter binding rules apply unchanged.
- **Conformance contracts.** [Part 8](/notes/mission-bound-authorization-conformance/) defines the Conformance Ladder, Resource Server Tiers, and Compliance Tiers substrate-neutrally. The [AAuth and the Conformance Ladder](#aauth-and-the-conformance-ladder) section below maps the substrate-specific projection.
The board-packet [Worked Example in Part 3](/notes/mission-bound-oauth-profile/#worked-example) and the [MCP application in Part 7](/notes/least-privilege-mcp-tool-calls/) walk OAuth-substrate scenarios; the same governance reasoning carries over to AAuth. An AAuth-specific worked example and adoption migration story are out of scope for this composition profile.
## Protocol Status
[AAuth `-01`](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/01/) is an active individual Internet-Draft. This post defines a proposed composition profile. Native AAuth behavior is identified explicitly; governance claims, status fields, lifecycle extensions, and MAS mappings remain proposal-level until standardized.
# Native AAuth Baseline
The AAuth Mission is an immutable approved context, not an OAuth authorization grant.
AAuth `-01` defines four resource-access modes that share agent identity but place policy at different parties:
- **Identity-based access.** The resource validates the Agent Provider-issued agent token and applies identity-based policy.
- **Resource-managed access.** The resource manages authorization itself and may return an `AAuth-Access` value bound to the agent's signed requests.
- **PS-asserted access.** The resource accepts identity claims and evidence of consent from the agent's Person Server, then applies its own resource policy. The Person Server does not dictate the resource's authorization result.
- **Federated access.** The resource has an Access Server. The resource issues a resource token for that Access Server, and the Person Server federates with it to obtain an auth token.
Agent governance is orthogonal to these modes. Missions, permissions, audit, and interaction provide context and user control, while the Resource or its Access Server remains authoritative for resource policy.
The Person Server returns an approved mission blob containing at least:
- `approver`;
- `agent`;
- `approved_at`;
- `description`.
It may also contain `approved_tools` and `capabilities`. The response carries the native Mission reference:
```http
AAuth-Mission: approver="https://ps.example";
s256="dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
```
`s256` is the base64url-encoded SHA-256 digest of the exact mission response-body bytes. The agent stores those bytes unchanged and sends `approver` and `s256` in later `AAuth-Mission` headers. Mission-aware resources include the Mission reference in resource tokens, and Access Servers can include it in auth tokens.
AAuth currently defines two Mission states:
- `active`: requests may proceed;
- `terminated`: the Mission is permanently ended.
That baseline is sufficient for AAuth-native governance. The rest of this profile applies only when a deployment also wants typed authority commitments, richer external governance state, runtime-policy integration, or one governance object shared with OAuth.
# Identifier and Hash Mapping
AAuth and Mission-Bound governance identify different things:
- AAuth's native Mission reference is the tuple `(approver, s256)`.
- Mission-Bound governance uses a Mission reference containing `id` and `origin`.
They MUST NOT be treated as interchangeable strings. A composing Person Server or MAS maintains the mapping:
```json
{
"mission": {
"id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
"origin": "https://ps.example"
},
"aauth_mission": {
"approver": "https://ps.example",
"s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}
}
```
The values have distinct integrity semantics:
- AAuth `s256` commits the exact approved mission-blob bytes.
- `proposal_hash` commits the JCS-canonical structured Mission Intent used by Mission-Bound governance.
- `authority_hash` commits the canonical maximum authority set described below.
- `consent_rendering_hash` commits a canonical consent-disclosure object, not arbitrary screen pixels or implementation-specific HTML.
A deployment MAY derive `proposal_hash` from a structured extension in the AAuth mission blob. It MUST NOT equate `s256` with `proposal_hash` unless the exact mission response-body bytes are also the required JCS-canonical Mission Intent bytes. In ordinary deployments they commit different objects.
**Hash domains matter.** An OAuth-only deployment may compute `authority_hash` over its deterministic `authorization_details` array. An AAuth composition or MAS deployment computes it over the canonical Authority Set defined in [Part 5](/notes/mission-authority-server-profile/#authority-set). The hashes are not interchangeable even when they describe equivalent real-world authority.
# Authority Set
Cross-substrate governance needs a neutral authority container. [Part 5](/notes/mission-authority-server-profile/#authority-set) defines the **Authority Set** as the JCS-canonical maximum typed authority committed by `authority_hash`. This example contains both OAuth and AAuth entries:
```json
{
"version": 1,
"entries": [
{
"substrate": "oauth",
"type": "resource_access",
"authority": {
"resource": "https://finance.example.com",
"actions": ["financials.read"],
"constraints": { "period": "2026-Q3" }
}
},
{
"substrate": "aauth",
"type": "aauth_scope",
"authority": {
"resource": "https://workflow.example",
"scope": ["notification.send"],
"constraints": { "group": "audit-committee" }
}
}
]
}
```
The relevant rules are:
- `authority_hash` is the base64url-no-pad SHA-256 digest of the JCS-canonical Authority Set.
- Entries MUST be sorted deterministically by `substrate`, `type`, resource identifier, and canonical entry bytes.
- Each `type` owner defines subset and narrowing semantics.
- A consumer receives only entries relevant to its substrate, tenant, and audience.
- OAuth consumers project applicable entries into `authorization_details`, scopes, audiences, and tokens.
- AAuth consumers project applicable entries into resource-token requests, requested scopes, auth tokens, permission requests, and local policy.
- AAuth consumers preserve `tenant` where the deployment uses the OpenID Connect Enterprise Extensions tenant parameter or claim.
- Unknown entry types MAY be passed through only to a known consumer required to enforce that exact type; otherwise they MUST be refused. They MUST NOT be silently interpreted or dropped.
An AAuth deployment claiming this composition profile uses the generic Authority Set, even if it currently has no OAuth consumer. This keeps the commitment domain stable if another substrate is added later.
# Lifecycle Composition
AAuth deliberately defines only `active` and `terminated`. The richer Mission-Bound lifecycle is external governance state that must project into those native semantics:
| Governance state | AAuth-native behavior |
| --- | --- |
| `pending_approval` | No approved AAuth Mission exists yet; deferred or clarification processing continues |
| `active` | AAuth state is `active` |
| `suspended` | No direct native equivalent; governed requests are temporarily refused by a composition extension |
| `revoked` | AAuth state is permanently `terminated` |
| `expired` | AAuth state is permanently `terminated` |
| `completed` | AAuth state is permanently `terminated` |
| `rejected` | No active AAuth Mission is created |
The same projection visually:
```mermaid
flowchart LR
subgraph G["Governance lifecycle (7 states)"]
direction TB
PA[pending_approval]
A[active]
S[suspended]
C[completed]
R[revoked]
E[expired]
RJ[rejected]
end
subgraph X["AAuth native states (2)"]
direction TB
AX[active]
TX[terminated]
end
PA -.no AAuth Mission
issued yet.-> AX
A ==> AX
S -.composition extension:
temporary denial
+ resume signal.-> AX
C ==> TX
R ==> TX
E ==> TX
RJ -.no AAuth Mission
created.-> TX
```
Solid arrows are direct native projections. Dashed arrows mark states with no native AAuth equivalent: `pending_approval` and `rejected` exist only at the governance layer, and `suspended` requires a composition extension because AAuth treats long-lived non-active states as terminal.
The native AAuth `mission_terminated` error remains the interoperable response for permanent terminal states. A composing implementation MAY add a `mission_status` detail identifying `revoked`, `expired`, or `completed`.
Suspension is not transparent to native AAuth. A deployment that supports resumable suspension MUST define a distinct temporary-denial signal and a bounded way for the agent to learn that the Mission resumed, such as Mission Status polling or lifecycle events. Without that extension, the deployment should terminate the AAuth Mission and create a successor rather than claim resumable suspension. This preserves AAuth's rationale that long-lived suspension is otherwise operationally equivalent to termination.
# Mission Carriage
The `AAuth-Mission` header remains the native Mission reference before an auth token exists. A Mission-aware Resource includes that reference in its resource token. An Access Server issuing an auth token for a Mission-aware request preserves AAuth's native `mission` claim:
```json
{
"mission": {
"approver": "https://ps.example",
"s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}
}
```
Mission-Bound governance does not redefine that claim. The Person Server or MAS maintains the verified mapping from `(approver, s256)` to the governance Mission. Consumers resolve the mapping through authenticated Mission Status. A future registered AAuth extension MAY carry `mission.id` and `mission.origin` directly, but an implementation must not insert an unregistered nested shape into AAuth's native `mission` claim.
The governance identifier returned to a consumer MAY be consumer-pairwise or audience-pairwise. In this post, `msn_` denotes a canonical server-side identifier and `pm_` denotes a projected identifier. Authorized consumers and auditors resolve projections at `mission.origin`.
# Mission Status
AAuth token verification and Mission-state verification are separate operations:
- the token issuer verifies or introspects auth-token validity;
- `mission.origin` answers Mission governance state.
A composing PS, or the MAS in a shared topology, exposes authenticated Mission Status. The request identifies the Mission by a projected `mission.id` or the native `(approver, s256)` tuple and identifies the requesting issuer and audience. The response is audience-filtered and keeps governance state separate from token validity:
```json
{
"active": true,
"projection_issuer_authorized": true,
"projection_issuer": {
"issuer": "https://as.workflow.example",
"substrate": "aauth",
"audience": "https://workflow.example"
},
"mission": {
"id": "pm_8Fc7...",
"origin": "https://ps.example",
"state": "active",
"expiry": "2026-10-15T18:00:00Z",
"proposal_hash": "fS8h4w7Z3Lq...",
"authority_hash": "o2j2...",
"consent_rendering_hash": "e9X2...",
"policy_version": "pv_01J9Z..."
},
"authority": [
{
"substrate": "aauth",
"type": "aauth_scope",
"authority": {
"resource": "https://workflow.example",
"scope": ["notification.send"]
}
}
]
}
```
This is not RFC 7662 token introspection. Here, `active` describes the governance Mission, not any particular auth token. The credential issuer remains responsible for token validity.
# Worked Example on the AAuth Substrate
The board-packet example used throughout the series ([Part 1](/notes/the-mission-is-the-missing-abstraction/#a-concrete-mission-record), [Part 3](/notes/mission-bound-oauth-profile/#worked-example), [Part 7](/notes/least-privilege-mcp-tool-calls/#what-a-mission-fixes)) lands on AAuth as follows.
The user asks: "prepare the Q3 board packet for the audit committee."
1. The agent submits an AAuth-native Mission proposal to the Person Server's mission endpoint. The proposal mirrors the OAuth-side Mission Intent (`goal`, `objects`, `constraints`, `success_criteria`, `mission_expiry`) but uses AAuth's request shape. Composing deployments also include the JCS-canonical Mission Intent as a structured extension so `proposal_hash` can be computed.
2. The Person Server validates the proposal, derives the candidate Authority Set (financial-read, document-create, workflow-notify for the audit-committee group, all scoped to the Example Corp tenant), and renders the disclosure for the user.
3. On approval, the PS returns the native AAuth mission blob with `approver="https://ps.example"` and a SHA-256 `s256` of the response-body bytes. The PS also records the governance mapping:
```json
{
"mission": {
"id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
"origin": "https://ps.example"
},
"aauth_mission": {
"approver": "https://ps.example",
"s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
},
"integrity": {
"proposal_hash": "fS8h4w7Z3Lq_xkN2vYpA8mC4tR1bU6oI9eW0jH3yL2k=",
"authority_hash": "o2j2H8qP3sN4xL7vT9rD1mY6bC0gE5wA2uK8nF4iJ3a=",
"consent_rendering_hash": "e9X2K7mB4nL3hY8sR1pT0jC6vF5dA9wU2gI4oQ7eN0c="
}
}
```
4. The agent presents the `AAuth-Mission: approver, s256` header on signed requests to the finance, document, and workflow Resources. Each Resource selects its AAuth resource-access mode (identity-based, resource-managed, PS-asserted, or federated) per its own policy.
5. In federated mode, the finance Resource issues a resource token for its Access Server, the PS federates with that AS, and the resulting auth token preserves the native `(approver, s256)` Mission reference.
6. Mission-aware Resources query Mission Status at `mission.origin` to confirm the Mission is still `active` and to obtain the audience-relevant Authority Set projection (`financials.read` with `period: Q3 2026`).
7. The agent completes the packet. The user revokes the Mission afterward through the PS lifecycle surface. New derivations fail because the governance state is no longer `active`, and the native `mission_terminated` error is returned with a `mission_status: revoked` detail.
The same canonical Mission identifier `msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1` rides the OAuth-side examples in Parts 3 and 7. Under the [Mission Authority Server topology](/notes/mission-authority-server-profile/), the same governance Mission can be projected to both an OAuth AS and the AAuth PS at the same time; the native `(approver, s256)` reference and the OAuth `mission.id`/`mission.origin` reference both resolve through the MAS to the same canonical Mission.
# Native AAuth Flow with Governance Composition
1. The agent submits a Mission proposal to the Person Server's AAuth mission endpoint.
2. The Person Server performs any required clarification through AAuth's native deferred interaction.
3. The state authority (the PS in a local topology or the MAS in a shared topology) validates the structured Mission Intent, derives the candidate Authority Set, and produces the canonical consent disclosure.
4. The Person Server presents that disclosure or redirects to MAS-hosted consent. After approval, the state authority activates the governance Mission and computes the integrity hashes. The PS stores the native mapping and returns the immutable mission blob plus `AAuth-Mission: approver, s256`.
5. The Agent Provider-issued agent token identifies the agent and its signing key. It MAY also identify the Person Server through the `ps` claim.
6. The agent sends a signed request to the resource, carrying `AAuth-Mission` unless an auth token already conveys the Mission.
7. Depending on the selected AAuth mode, the resource applies identity policy, manages authorization directly, issues a resource token for the Person Server, or issues a resource token for its Access Server.
8. In PS-asserted access, the Person Server returns identity claims and consent context, while the resource remains the final resource-policy decision point.
9. In federated access, the Person Server sends the resource token and agent token to the resource's Access Server. The Access Server applies policy and issues an audience-specific, proof-of-possession auth token.
10. The agent presents the auth token on subsequent authorized requests. Mission-aware Resources additionally obtain governance state through Mission Status or current lifecycle events.
No OAuth token exchange or invented AAuth credential endpoint is required.
The AAuth PS token request may also carry agent-attested `platform` and `device` context. A composing deployment MAY include those values in runtime policy and decision evidence, but they remain agent assertions unless an attestation profile strengthens them.
# MAS Composition
A deployment that needs one canonical governance object across OAuth and AAuth uses the [Mission Authority Server Profile](/notes/mission-authority-server-profile/). Without a MAS, the OAuth and AAuth Missions remain distinct governance records even if an application correlates them.
Under that topology:
- the Person Server remains the AAuth protocol endpoint and the `approver` in AAuth's native Mission reference;
- the MAS is the state authority for the canonical governance Mission, Authority Set, lifecycle, and subject mapping;
- the PS registers as an authorized Mission consumer and projection issuer;
- the PS links the AAuth `(approver, s256)` tuple to a MAS Mission projection;
- OAuth ASes and the AAuth PS receive consumer-specific Mission identifiers;
- AAuth `tenant`, `platform`, and `device` context is retained where relevant to consent, status, or runtime policy;
- each substrate issues its own native credentials;
- token validity remains with the issuing AS or Access Server;
- Mission Status and lifecycle remain with the MAS.
One Mission-level approval can cover both substrates only when the consent disclosure contains the complete candidate Authority Set for both. Adding a resource, scope, audience, or substrate projection beyond that commitment requires Mission Expansion. Local resource policy, contractual consent, authentication, or step-up may still require separate interactions without expanding the Mission.
# Call-Chaining Semantics
AAuth does not require downstream scope to be a subset of upstream scope. When an intermediary Resource acts as an Agent, it sends the downstream resource token, its own agent token, and the upstream auth token to the PS or Access Server. The recipient verifies the upstream token, extends the `act` chain, and evaluates the new request against the Mission context.
Mission-Bound composition preserves that rule:
- downstream scope is not required to be a subset of upstream scope;
- downstream authority MUST fit the downstream audience's entry in the committed Authority Set;
- the PS evaluates the downstream request independently against the Mission and its log;
- the downstream Resource or Access Server applies its own policy;
- adding authority not represented in the Authority Set requires Mission Expansion.
The attenuation comparison is therefore **requested downstream authority versus the Mission's downstream projection**, not **downstream token versus upstream token**. This matters for legitimate chains such as a booking Resource calling a payment Resource: the payment scope may be orthogonal to the booking scope while both were approved as parts of one Mission.
# Cross-Substrate Audit
Cross-substrate audit MUST NOT assume that every consumer sees the same raw Mission identifier.
Audit records carry:
- the consumer-visible Mission projection;
- `mission.origin`;
- `proposal_hash`;
- `authority_hash`;
- `consent_rendering_hash`;
- `policy_version`, for runtime decisions;
- the native AAuth `(approver, s256)` reference when applicable;
- issuer and audience;
- authenticated agent and actor-chain context;
- decision or lifecycle evidence identifiers.
An authorized auditor resolves consumer- or audience-pairwise Mission references at `mission.origin` to a canonical audit correlation identifier. The MAS supplies canonical lifecycle state; credential issuers and enforcement points still supply their own issuance and decision evidence. Exact raw-string joins are valid only when a deployment deliberately uses one non-pairwise identifier.
# Runtime Enforcement
The [Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/) can evaluate AAuth requests, but its Core input must be substrate-neutral:
- Mission reference and state;
- integrity hashes and `policy_version`;
- applicable Authority Set entries;
- authenticated subject and agent;
- actor chain;
- resource;
- action or requested scope;
- parameters;
- tenant and current policy context.
An AAuth adapter obtains these values from signed requests, agent tokens, resource tokens, auth tokens, the `AAuth-Mission` reference, and Mission Status. It validates native credentials at their issuers and obtains governance state from `mission.origin`. It does not translate AAuth into OAuth `authorization_details` merely to call the PDP.
# Threat Model
This profile adds the following composition risks:
- **Reference substitution.** An attacker combines a valid `AAuth-Mission` tuple with a different governance Mission. The PS or MAS MUST maintain and verify the mapping; clients cannot assert it.
- **Projection issuer abuse.** A PS or Access Server references a Mission it is not authorized to project. Mission Status or a MAS-signed projection assertion MUST bind authorization to the issuer, Mission, tenant, substrate, and applicable audience.
- **PS-asserted trust confusion.** A resource treats Person Server claims as a command to authorize. In PS-asserted access the resource accepts claims and consent evidence but applies its own policy.
- **Lifecycle ambiguity.** A temporary governance suspension is represented as permanent AAuth termination, or a deployment claims suspension without a way to signal resumption. Implementations supporting suspension MUST define both a temporary-denial signal and a bounded resumption mechanism.
- **Authority-model confusion.** OAuth RAR entries are interpreted as AAuth scopes, or vice versa. Every Authority Set entry is explicitly typed and substrate-scoped.
- **Correlation.** A shared raw Mission identifier links OAuth and AAuth activity. Pairwise projections and authenticated audit resolution mitigate this.
# Conformance
A deployment claims this composition profile only when:
- [ ] It uses AAuth's native mission endpoint, mission blob, `AAuth-Mission` header, resource tokens, auth tokens, and call-chaining flow rather than replacing them.
- [ ] It maintains a verified mapping between `(approver, s256)` and the governance Mission reference.
- [ ] It distinguishes AAuth `s256`, `proposal_hash`, `authority_hash`, and `consent_rendering_hash`.
- [ ] It commits a canonical Authority Set with typed, substrate-scoped entries.
- [ ] AAuth projections use AAuth resource, scope, permission, and auth-token semantics.
- [ ] Rich governance states are explicitly projected into AAuth's native lifecycle.
- [ ] Native credential validity is checked at the credential issuer and Mission state at `mission.origin`.
- [ ] Pairwise Mission identifiers are resolved through authenticated status or audit APIs rather than raw-string joins.
- [ ] A PS or Access Server projects only Missions for which it is authorized for the applicable tenant, substrate, and audience.
- [ ] If it supports resumable suspension, it implements a distinct temporary-denial signal and bounded resumption discovery.
## AAuth and the Conformance Ladder
[Part 8's Conformance Ladder](/notes/mission-bound-authorization-conformance/#conformance-ladder) is substrate-neutral by design. AAuth deployments map to it as follows:
- **Level 0 (substrate-only).** Native AAuth `-01`, including its optional Mission, without this composition profile. Native AAuth Mission remains useful; Level 0 means only that the deployment does not claim the additional Mission-Bound governance contract.
- **Level 1 (Mission-bound issuance).** The composing PS uses AAuth's native mission endpoint, mission blob, and `AAuth-Mission` carriage, while recording the governance mapping, committing the Authority Set, computing distinct integrity hashes, and applying the lifecycle projection defined here.
- **Level 2 (Mission-aware projection).** Resource-token and auth-token flows preserve the native Mission reference and a resolvable governance projection. Federated flows preserve that binding across the Access Server boundary.
- **Level 3 (Mission-aware Resource Server).** Achieved when AAuth Resources query Mission Status at `mission.origin` (or consume Mission state events) and evaluate the audience-relevant Authority Set projection at request time.
- **Level 4 (full Runtime Enforcement).** Achieved by composing with [Part 6](/notes/mission-bound-runtime-enforcement-profile/). The PDP contract is substrate-independent; an AAuth adapter supplies native credential and actor context.
- **Level 5 (verifiable governance).** Achieved by adding interoperable optional modules for claimed Decision Receipt, Tool Binding, Attestation, or other verifiable-governance capabilities. A MAS is required only when multiple substrates must consume one canonical Mission, not merely to reach Level 5.
# Standards Path
The standards contribution is a focused AAuth composition draft, not a second AAuth Mission specification. It should define:
- the native AAuth Mission to governance-Mission mapping;
- preservation of the native Mission reference and any registered governance-projection claim;
- the AAuth Authority Set entry and projection type;
- extended lifecycle projection;
- Mission Status;
- MAS consumer and projection-issuer binding;
- audit correlation and pairwise identifier resolution.
# References
- [AAuth Protocol -01](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/01/)
- [Mission-Bound OAuth Profile](/notes/mission-bound-oauth-profile/)
- [Mission-Bound Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/)
- [Mission Authority Server Profile](/notes/mission-authority-server-profile/)
- [Mission Shaper Profile](/notes/mission-shaper-profile/)
- [RFC 8785](https://datatracker.ietf.org/doc/html/rfc8785): JSON Canonicalization Scheme (JCS)