---
title: "AAuth Now Has a Mission Layer, and R3 Shows Where It May Go"
date: "2026-04-09T11:21:00-07:00"
lastmod: "2026-04-09T11:21:00-07:00"
description: "The latest AAuth editor's draft now includes missions, mission approval, mission-scoped resource tokens, and PS-managed governance in the core protocol. Read alongside the exploratory R3 draft, it points toward a stronger architecture, even though Mission still sits as an orthogonal governance layer rather than the protocol's full authority model."
summary: "The current AAuth editor\u0026rsquo;s draft adds missions, the AAuth-Mission header, mission-aware resource and auth tokens, and Person Server governance endpoints. The exploratory R3 draft adds richer resource-local authorization semantics. Together they move AAuth materially closer to the mission architecture argued on this blog, while leaving the hardest authority-model and lifecycle questions open."
slug: "aauth-now-has-a-mission-layer"
tags:
  - "AAuth"
  - "Authorization"
  - "Agentic Identity"
  - "OAuth"
  - "Mission Shaping"
  - "Standards"
---


The latest editor's copy of the [AAuth Protocol](https://dickhardt.github.io/AAuth/draft-hardt-aauth-protocol.html), with the draft header dated April 9, 2026, has moved materially closer to a mission-aware architecture.

That does not mean AAuth has become a full Mission architecture in the sense I have argued for on this blog: an architecture where durable task authority has an explicit state owner and the rest of the IAM stack composes around it. It does mean the protocol is no longer only about agent identity, proof-of-possession, and token choreography.

The draft now includes a real **Mission layer**.

My earlier comparison in [Mission Architecture on AAuth](/notes/mapping-mission-architecture-to-aauth/) argued that AAuth looked like a better clean-sheet substrate than [OAuth](https://datatracker.ietf.org/doc/html/rfc6749), but still appeared to need a Mission-like governance object above it. The current editor's draft closes some of that gap.

The important shift is not that AAuth added one more field. It is that the draft now gives missions a real place in the protocol:

- a **Mission** as a scoped authorization context
- mission creation and approval at the **Person Server (PS)**
- an `AAuth-Mission` request header
- mission objects carried in resource tokens and auth tokens
- mission lifecycle states
- governance endpoints for interaction, plus named placeholder endpoints for permissions and audit

That is a meaningful change.

# What Changed

The draft now presents AAuth as two dimensions:

- **resource access modes**
- **agent governance**

That is a subtle but important point. Missions are now in the protocol, but they are described as an **orthogonal layer**, not as the thing every AAuth flow depends on.

The protocol's main roles are now:

- **Agent**
- **Agent Server**
- **Resource**
- **Person Server (PS)**
- **Access Server (AS)**

The core architecture is organized around four resource access modes:

1. identity-based access
2. resource-managed access (two-party)
3. PS-managed access (three-party)
4. federated access (four-party)

Missions sit on top of that as the governance layer an agent with a PS can use.

That is different from the earlier Mission Manager framing. The current draft does not say the whole protocol is built around a separate Mission Manager role. It says the **Person Server** represents the legal person, brokers authorization, and optionally governs the agent through missions, permissions, audit, and interaction.

That distinction matters. The PS is broader than the mission layer. It also handles non-mission token brokerage, identity assertions, and consent. Missions are now in the protocol, but the protocol still does not define the full machine-evaluable authority model above them.

# What the Mission Layer Looks Like Now

The mission-aware flow in the current draft is straightforward:

1. The agent obtains an agent token from its agent server.
2. If it wants governance, it sends a mission proposal to the PS's `mission_endpoint`.
3. The PS may involve the user through review, approval, or clarification.
4. On approval, the PS returns an `AAuth-Mission` header containing the `approver` and `s256` (SHA-256) hash of the approved mission body.
5. The agent includes that `AAuth-Mission` header on all subsequent requests to resources.
6. A mission-aware resource includes the mission object in the resource token it returns.
7. The agent presents that resource token, a signed JWT describing the resource-side authorization request, to the PS.
8. The PS evaluates the request against mission context before issuing an authorization token (auth token) directly or federating with the resource's AS.

The approved mission itself is now a real protocol object. The draft defines it as a JSON mission blob that must include:

- `approver`
- `agent`
- `approved_at`
- `description`

It may also include:

- `approved_tools`
- `capabilities`
- `interaction_endpoint`

The required fields give the mission a durable protocol identity. The `s256` hash of the approved blob is what travels through resource tokens, auth tokens, and audit records, serving as a correlation handle that links every downstream artifact back to a specific approval event.

# Why This Improves the Protocol

## 1. Mission is now a first-class protocol concept

The draft now defines Mission explicitly as:

- a scoped authorization context for agent governance
- proposed by the agent
- approved by the PS
- identified by the SHA-256 hash of the approved mission JSON

That matters because it gives mission context a durable protocol identity rather than leaving it as an implementation detail outside the wire model.

It is still intentionally light. The mission description is Markdown, not a full machine-evaluable [Mission Authority Model](/notes/the-mission-shaping-problem/). But it is no longer just an informal idea above the protocol.

## 2. Mission approval is now part of the core governance flow

The PS is now responsible not only for brokering token requests but also for:

- mission creation
- mission approval
- named endpoints for permissions
- named endpoints for audit
- relayed interaction

That is a more coherent architecture. The protocol now has a place where approved intent can exist before individual resource requests are authorized, even though missions remain optional rather than mandatory for every PS interaction. One important caveat: the permission endpoint and the audit endpoint sections in this draft are both explicitly marked as TODO placeholders. The endpoints are named in PS metadata and their purpose is described, but neither section specifies normative behavior. The governance surface is named. It is not yet specified.

This aligns with the argument in [The Mission Shaping Problem](/notes/the-mission-shaping-problem/): approved user intent has to become something the system can carry forward, not disappear after the initial user interaction.

## 3. Mission context now travels through the authorization chain

When an agent includes `AAuth-Mission`, the resource can include the mission object in the resource token. The auth token can also carry that mission object.

That means mission context is no longer local to the agent or PS. It can now travel through:

- resource token issuance
- PS evaluation
- AS federation
- auth token issuance
- downstream call chaining context

That is a major improvement over architectures where purpose exists only in prompts, UI state, or audit logs, even if the draft still stops short of a fully interoperable cross-domain mission semantics model.

## 4. The draft now has a clearer governance vantage point

The PS sees:

- mission proposals
- resource token requests
- approvals and clarifications
- permission requests through a named but still-placeholder endpoint
- audit events through a named but still-placeholder endpoint

That gives the protocol a real governance point rather than treating authorization as only a resource-local or AS-local problem.

This aligns directly with [Open-World OAuth Still Needs Mission Shaping](/notes/open-world-oauth-still-needs-mission-shaping/): open-world discovery and first-contact authorization are not enough. Something still has to decide whether a newly discovered action fits the approved task.

## 5. R3 strengthens the resource-local side of the model

The exploratory R3 draft is worth reading as part of the same architectural story.

R3 does three important things:

- it lets resources describe access in a structured vocabulary the agent and AS may already know how to discover and parse, such as [Model Context Protocol (MCP)](https://modelcontextprotocol.io/), [OpenAPI](https://spec.openapis.org/oas/latest.html), or [gRPC](https://grpc.io/)
- it gives the AAuth decision-makers a content-addressed resource authorization document (`r3_uri`, `r3_s256`) rather than only opaque scope strings
- it lets auth tokens carry vocabulary-based grants (`r3_granted`) and conditional operations (`r3_conditional`) that the resource can enforce directly

That is meaningful progress on a problem the base protocol still leaves fairly loose: what exactly the resource is asking to authorize.

There is one terminology wrinkle here. The current base AAuth draft uses **PS**. The R3 draft text still says **Mission Manager (MM)** in a few places when describing who fetches and presents R3 display information during approval. I am treating them as the same architectural slot here: the mission-side governance component acting for the legal person.

Analytically, R3 helps with **resource request meaning** more than **mission meaning**. It gives the resource a stronger, machine-evaluable way to say "these are the operations I expose and these are their consequences." It does not yet define a shared model for saying "these operations are inside the approved mission purpose across domains and over time."

That distinction matters. R3 narrows one part of the semantic gap. It does not close the larger Mission Authority Model gap.

# How This Aligns with the Blog's Argument

## 1. Identity substrate, resource meaning, and Mission governance are separate layers

In [OAuth for Open-World Ecosystems](/notes/oauth-for-open-world-ecosystems/), I argued that one layer solves discovery, proof-of-possession (cryptographic binding of tokens or requests to the presenting actor), first-contact trust, and cross-domain interaction. In [Open-World OAuth Still Needs Mission Shaping](/notes/open-world-oauth-still-needs-mission-shaping/), I argued that this still leaves a separate governance problem: is this newly discovered action still inside the purpose the user approved?

The current AAuth draft reflects that split. Identity and authorization modes handle protocol substrate. Missions, permissions, audit, and interaction handle governance. R3 adds a more structured resource-local description layer in between. Approved intent now survives the first consent screen — the user approves a task, not just a protocol grant, and the approved mission blob and its `s256` hash give the rest of the protocol a durable correlation handle for carrying that approval context forward. That is the core point of [The Mission Shaping Problem](/notes/the-mission-shaping-problem/), and the draft now has a protocol home for it.

## 2. Governance and resource policy stay distinct

The PS represents the legal person and handles missions, consent, identity, and governance. The AS represents the resource and applies resource policy. That separation maps to the argument in [Why Mission-Bound OAuth Might Be the Wrong Answer](/notes/why-mission-bound-oauth-might-be-the-wrong-answer/): governance and resource authorization are related, but they are not the same role. AAuth maintains that boundary cleanly.

The distinction is sharpest in four-party mode. In three-party mode, the PS issues the auth token directly and therefore collapses more governance and authorization responsibility into one place. In four-party mode, the split is cleaner: the PS governs whether the discovered request fits the mission, while the AS remains sovereign for whether its own resource domain will authorize that request.

AAuth was already the stronger clean-sheet substrate on per-agent cryptographic identity, proof-of-possession, deferred authorization, interaction chaining, and PS-to-AS federation. The current draft no longer leaves mission outside that story.

# Gap Analysis: What AAuth Still Does Not Address

This is the important part. The draft is materially better. It is still not complete in the places that matter most for durable authority governance.

## 1. Mission is still text-first, not authority-model-first

The approved mission body includes structured top-level fields, but the actual mission scope still centers on a Markdown `description`.

What is still missing is not merely more mission metadata. It is a Mission Authority Model: the machine-evaluable derivative of approved intent that says which resource classes, actions, constraints, stages, and delegation bounds are actually inside the mission.

That is useful for:

- approval
- integrity
- audit
- propagation

Mission text is good for approval and audit. It is weak as a shared enforcement artifact.

It is not the same thing as a full **Mission Authority Model**.

The draft's optional `approved_tools` field might seem to address this. It gives the mission a machine-readable allowlist of permitted tool identifiers. But a tool list is a permission set, not a bounded authority envelope. It names which tools may be called. It does not define the resource classes those tools may touch, the action types they may perform within those classes, the stage constraints on when each applies, or the explicit exclusions the approver intended. A Mission Authority Model is not an allowlist of permitted tools. It is the derivable authority structure that makes tool-level permissions principled rather than ad hoc.

The draft says the PS evaluates token requests against mission context. It does not define a machine-evaluable representation of purpose, constraints, selectors, and attenuation rules that multiple enforcement systems can share consistently. R3 improves one adjacent problem by giving resources and ASes a structured, content-addressed description of resource-local operations and consequences. That is useful. R3 helps the system understand what a resource exposes. A Mission Authority Model would help the system decide whether this mission is allowed to use it. The draft's design rationale addresses this directly under "Why Missions Are Not a Policy Language": the choice is deliberate. The draft separates deterministic policy (handled by scopes, R3 operation semantics, and AS evaluation) from contextual governance (handled by the PS with human or AI judgment). That is a defensible design. It is also not the same as a portable authority model.

That means the core shaping problem is only partly solved. A human-readable mission exists. The authority derivative is still largely implementation-defined, and the draft still does not define the explicit **Mission Authority Model** I would want enforcement systems to share.

## 2. Mission management is introduced, but not fully specified

The draft names mission states such as:

- `proposed`
- `active`
- `suspended`
- `resumed`
- `completed`
- `revoked`
- `expired`

But it also says mission lifecycle management is an administrative concern that may be standardized later.

That leaves important questions open:

- who can trigger which transitions
- how transitions affect outstanding token requests
- how revocation or suspension propagates
- what resources are required to do with already-issued mission-scoped tokens

Lifecycle is one of the load-bearing parts of mission governance. Naming the states is good. It is not the same as specifying the lifecycle.

## 3. Revocation is stronger in the control plane than in the runtime plane

The draft gives the PS meaningful revocation levers:

- revoke missions
- deny future token requests
- revoke outstanding auth tokens through revocation endpoints

But it still does not fully close the operational gap between control-plane revocation and runtime termination.

In practice, the strength of revocation will still depend on:

- auth token lifetime
- cache behavior
- whether resources re-check revocation promptly
- how many downstream hops are already in motion

This is an operational inference from the draft rather than a textual contradiction. The architecture now has a source of revocation truth. It still does not guarantee instant stop everywhere.

## 4. Downstream attenuation is still too weak

The draft still says downstream authorization is not required to be a subset of upstream scopes.

Sometimes that is correct. A downstream resource may need orthogonal capability. The payment-processor example in the draft is real, and the draft's design rationale addresses it directly under "Why Downstream Scope Is Not Constrained by Upstream Scope." The draft authors have made a deliberate choice here, not an oversight: the PS evaluates each hop against mission context rather than enforcing algebraic attenuation rules.

From the standpoint of mission governance, that is still a gap. Governance-based constraints are more flexible than formal subset rules, but they are also weaker as a provable bound. Visibility and provenance improve. Formal boundedness does not.

That means AAuth is still stronger on chain transparency than on chain attenuation.

That gap is not independent of Gap 1. Principled attenuation requires that downstream authority be derivable as a proper subset of the parent grant. If the parent grant is a Markdown description, attenuation reduces to PS heuristics applied at each hop. The Mission Authority Model is the prerequisite for making attenuation provable rather than asserted.

## 5. Mission context travels without mission meaning

The draft now carries mission context through the authorization chain: the `s256` hash and approver URL appear in resource tokens, auth tokens, and audit records. Parties that receive those artifacts can confirm that an action was correlated to an approved mission. That is real progress.

What the protocol still cannot do is prove that a correlated request was inside the mission's authority. That requires a shared authority derivative — a machine-evaluable representation of purpose, constraints, and boundaries that multiple PSes and ASes can evaluate consistently. The draft deliberately does not define one, and the design rationale explains why: the authors separate deterministic policy from contextual governance handled by the PS with human or AI judgment. R3 makes deterministic policy richer at the resource boundary, but it still does not define mission semantics above that boundary. That is a coherent position. It is also the position that makes cross-system interpretation inconsistent.

That does not mean the AS is blind to mission context. An AS can still use the mission object as a local policy input if the deployment wants it to. What the draft does not provide is a shared semantic model that would let different ASes interpret and enforce that context consistently across domains.

Consider the recurring structured example from this series:

> Assemble the board packet, reconcile the final numbers, and call back for approval before releasing the presentation.

An agent may then discover and request access to:

- finance systems
- content repositories
- spreadsheet and version-history tools
- HR systems, treasury systems, or an external release channel

The first three fit the expected shape of the mission. A human reviewer can see the connection immediately. The fourth category is where the absence of a shared authority derivative starts to matter. Does board-packet preparation include reading HR data to explain headcount variance? Querying treasury to confirm cash positioning? Releasing material externally before the callback approval step? Those are adjacent requests, not obviously absurd ones. That is exactly why they are hard.

The stage dimension in the same example is equally hard. The mission description says to call back for approval before releasing the presentation. That is not a scope question. It is a sequencing constraint: external release should be blocked until the callback approval is recorded, regardless of what credentials the agent holds. A Mission Authority Model that carried stage constraints could make that boundary explicit and enforceable. Without one, the PS either reads the prose and makes a judgment call, or the constraint disappears entirely. The current draft has no mechanism for representing it.

Without a shared authority derivative, one PS may decide a treasury query is a reasonable extension of reconciling final numbers. Another may require a new approval step. A downstream AS sees only that the user holds treasury read access and that the request is tied to a mission hash. That is enough for correlation. It is not enough for shared semantic enforcement.

With a stronger Mission Authority Model, the approval could be shaped into something more explicit: allowed resource classes, allowed actions, explicit exclusions, and stage constraints. At that point the PS is not improvising from prose. It is evaluating a derived authority envelope, and a downstream AS can do the same.

Without it, the complexity does not disappear. It moves into PS heuristics, AS-local interpretation, repeated human review, and post-hoc audit arguments about what the mission "really meant." A shared authority derivative is the mechanism for making that complexity explicit rather than fragmenting it across implementations.

The system can prove a request was correlated to the mission. It cannot prove the request was inside it. That is the difference between carrying mission context and carrying mission meaning.

## 6. Runtime alignment is still outside the protocol

The PS can:

- approve missions
- deny permissions
- log audit events
- relay interaction
- refuse future token issuance

That is meaningful governance.

It still does not solve the problem described in [Mission Shaping Is Not Enough](/notes/mission-shaping-is-not-enough/): an agent can remain nominally inside mission scope while drifting semantically away from the user's intent.

The draft does not really address:

- runtime containment
- semantic drift detection
- release gates before high-consequence actions
- how observation systems feed back into mission governance

That is not a flaw in the protocol draft so much as a reminder that request-time governance and runtime alignment are not the same thing.

## 7. Cross-domain mission semantics are still loose

The draft is much more explicit now about:

- PS-to-AS federation
- trust establishment
- pairwise user identifiers
- mission object propagation

That is real progress.

But hard questions remain:

- what exactly does the AS trust the PS to assert about the mission
- how much mission context should cross trust boundaries
- how should different domains interpret mission context consistently

The draft does take a position on one of these: resources and ASes see only the `s256` hash and the approver URL, not the full mission content. That answers the within-domain privacy question. It does not answer the cross-domain question of how a foreign AS should reason about mission context from an external PS when only the hash and approver travel. Open-world agent systems become hardest exactly there.

That is a real tradeoff, not just an omission. Limiting what crosses the boundary is the right call on privacy and minimizes mission disclosure to foreign domains. Its cost is that cross-domain mission enforcement cannot be derived from the protocol alone — it depends on whatever trust agreements exist between the PS and the foreign AS.

# The Real Takeaway

The takeaway is no longer:

> AAuth still seems to need a mission layer.

The better takeaway now is:

> AAuth has a mission layer now, and that is a meaningful improvement.

The architecture is much closer to the one I have been arguing for:

- agent identity and proof-of-possession at the protocol edge
- a Person Server representing the legal person
- a richer resource-local authorization description layer emerging through R3
- mission proposal and approval before broader authorization unfolds
- mission-scoped resource and auth tokens
- PS-to-AS federation across trust domains
- governance endpoints for interaction, plus named placeholder endpoints for permission and audit

The remaining gaps are now easier to name precisely:

- mission text is still not a full authority model
- lifecycle exists, but is only partly specified
- revocation is stronger in the control plane than in guaranteed runtime stop
- attenuation across chains is still too weak
- runtime alignment still needs more than request-time mission checks
- cross-domain mission semantics still need sharper definition

That is a much better place for the discussion to be.

The protocol family is no longer pretending that agent identity and token choreography are the whole answer. It is now building around a mission-aware governance layer and a richer resource-local authorization layer, even if the deeper authority-model problem is still not fully solved. The current drafts standardize mission coordination and correlation, and R3 adds more resource request meaning. They still do not standardize mission meaning.

That limitation has adoption benefits. It lowers the standardization burden, makes implementation easier, fits heterogeneous domains better, limits mission disclosure across trust boundaries, and avoids freezing a universal authority vocabulary too early. It also has real costs: weaker cross-system interpretation, weaker cross-domain enforcement, looser bounded delegation, and a less precise answer to whether a correlated action was actually inside the mission's granted authority.

If the protocol keeps enough extension room, richer mission meaning can come later without redesigning the whole architecture. The real risk is not primarily technical. It is organizational: if the ecosystem starts treating `approver` plus `s256` as the finished answer rather than the first layer, correlation-only behavior may harden into the de facto model. The right way to read the current drafts is as a foundation for mission-aware governance, not as the final form of mission-aware authority.

# Sources

- [AAuth Protocol editor's copy, draft header dated April 9, 2026](https://dickhardt.github.io/AAuth/draft-hardt-aauth-protocol.html)
- [AAuth Rich Resource Requests (R3) draft dated March 24, 2026](https://raw.githubusercontent.com/dickhardt/AAuth/refs/heads/main/draft-hardt-aauth-r3.md)
- [Mission Architecture on AAuth](/notes/mapping-mission-architecture-to-aauth/)
- [Open-World OAuth Still Needs Mission Shaping](/notes/open-world-oauth-still-needs-mission-shaping/)
- [The Mission Shaping Problem](/notes/the-mission-shaping-problem/)
- [Mission Shaping Is Not Enough](/notes/mission-shaping-is-not-enough/)
- [Why Mission-Bound OAuth Might Be the Wrong Answer](/notes/why-mission-bound-oauth-might-be-the-wrong-answer/)