Abstract

On the spine: Part 4 maps the Mission and Authority steps onto AAuth. Intent shaping remains generic (Part 2); runtime enforcement remains substrate-independent (Part 6).

AAuth 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 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; the litmus test for “what makes something a Mission” applies to AAuth-substrate Missions that satisfy this composition profile. The Lifecycle Composition section below specifies only how those states project onto AAuth’s native two-state model.
• Lethal Trifecta Boundary. Part 3 and Part 6 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 covers state freshness, unknown-constraint brittleness, and stale-Mission concerns that transcend the credential format.
• Runtime enforcement contract. Part 6 defines the PDP contract substrate-independently. The 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 defines the Conformance Ladder, Resource Server Tiers, and Compliance Tiers substrate-neutrally. The AAuth and the Conformance Ladder section below maps the substrate-specific projection.

The board-packet Worked Example in Part 3 and the MCP application in Part 7 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 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:

1
2

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "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. 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 defines the Authority Set as the JCS-canonical maximum typed authority committed by authority_hash. This example contains both OAuth and AAuth entries:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "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:

The same projection visually:

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:

1
2
3
4
5
6

{
  "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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

{
  "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, Part 3, Part 7) 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:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   { "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, 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. 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 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 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. 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
• Mission-Bound OAuth Profile
• Mission-Bound Runtime Enforcement Profile
• Mission Authority Server Profile
• Mission Shaper Profile
• RFC 8785: JSON Canonicalization Scheme (JCS)