This is a follow-up to Mission-Bound OAuth.

That RFC made one main claim:

agent systems need a durable, governed authority object that survives across token lifetimes, approval delays, delegation hops, and business-event termination.

The question here is narrower:

If Mission-Bound OAuth is the incremental path for existing OAuth deployments, is AAuth the clean-sheet path for the same underlying architecture?

AAuth (draft-hardt-aauth) is Dick Hardt’s proposed agent-native authorization protocol: conversational, signed-request-first, and designed to depart from OAuth’s redirect model rather than extend it. Both Mission-Bound OAuth and AAuth are early-stage proposals, so this comparison is necessarily tentative. Either may change materially before any standardization.

My current answer is: probably yes, but only if AAuth defines a Mission-like governance object rather than treating purpose and chaining alone as sufficient.

If you are skimming, the core claim of this note is simple:

• AAuth looks like a better protocol substrate than OAuth for agent authorization.
• It still does not obviously remove the need for a durable Mission governance object.
• The most plausible long-term comparison is Mission governance on OAuth versus Mission governance on AAuth.

At a glance:

What AAuth Already Gives You

One reason AAuth is interesting is that it already has several properties Mission-Bound OAuth has to build indirectly.

From the current draft, AAuth already gives you:

• signed requests using HTTP Message Signatures
• explicit agent identity alongside user identity
• deferred authorization with 202 Accepted
• pending-state polling
• user clarification during authorization
• direct approval flows
• chained downstream authorization via upstream_token
• a first-class purpose field

That matters because these are exactly the areas where classic OAuth looks most strained in agent deployments.

Relevant sections in the current AAuth draft (links reference a specific draft iteration and may shift as the spec evolves):

• Authorization request flow
• Deferred responses and pending state
• User interaction
• Direct approval
• Call chaining
• Purpose

Why This Comparison Matters

Mission-Bound OAuth was never mainly about adding another token claim.

Its real claim was that delegated machine authority needs to be represented as a governed object:

• proposed
• approved or attenuated
• stored durably
• enforced across derivation steps
• revocable independently of token lifetime
• terminable when the business reason ends

AAuth changes the protocol substrate substantially. It is more conversational, more agent-native, and stronger by default on proof-of-possession and chaining.

So the real question is:

Does AAuth already solve the governance problem by virtue of having better protocol structure, or does it still need an explicit Mission-like authority layer?

The High-Level Mapping

This is the rough mapping I would use today.

Where AAuth Looks Better

There are at least five places where AAuth looks cleaner than Mission-Bound OAuth.

1. Approval and clarification are native

Mission-Bound OAuth has to introduce proposal endpoints, approval endpoints, pending states, and optional clarification flows around an OAuth core that was not designed for conversational authorization.

AAuth already has the right shape:

• signed request
• 202 Accepted
• pending URL
• follow-up interaction
• direct approval path

That is a more natural fit for agent authorization than stretching classic OAuth redirects into a multi-step approval conversation.

2. Agent identity is part of the protocol

Mission-Bound OAuth has to work hard to distinguish:

• subject
• client
• active actor
• delegation chain

because OAuth starts from the client model, not the agent model.

AAuth is much closer to the reality that software agents are actors in the protocol, not just hidden implementation details behind a client.

One deployment caveat: AAuth identifies agents via HTTPS URLs pointing to published metadata at /.well-known/aauth-agent.json. That works well for internet-scale agents with public endpoints. It is a meaningful assumption for enterprise environments where internal microservices, batch jobs, and RPA workflows today register as OAuth clients and often have no public-facing HTTPS endpoints. A Mission profile for AAuth would need to address this, either through an enterprise agent registration companion or a fallback identity model for internally-scoped agents.

3. Proof-of-possession is the baseline

Mission-Bound OAuth has to strongly recommend DPoP or mTLS because durable delegated authority on bearer tokens is too risky.

AAuth starts from signed requests. That is a much better default for any protocol that wants to make serious claims about agent governance.

4. Chaining is built in

Mission-Bound OAuth relies on token exchange, projected Mission references, and careful downstream derivation rules.

AAuth already has a better native story for chained authorization through upstream_token.

One important caveat: Section 4.5.8 of the current draft explicitly flags call chaining as an exploratory feature: “The mechanism described here may change.” It is a better starting point than OAuth’s approach, but it is not yet a stable protocol surface.

5. Authentication-time bootstrap may be less awkward

One thing that has become clearer since the original Mission-Bound OAuth writeup is that classic OAuth needs an authentication-layer companion profile to do this cleanly. In the OAuth world, Client Context and ID-JAG for Mission-Bound OAuth had to define how purpose gets carried into the authentication step and how a reduced Mission view gets projected across same-IdP trust domains.

AAuth likely reduces the need for a separate Client Context-style bootstrap mechanism because signed requests, deferred approval, clarification, and direct approval are already native parts of the protocol flow. That is a real advantage.

But it does not automatically remove the need for the other half of that companion story: a durable Mission record after approval, and a reduced projection model for cases where authority needs to cross domains or be consumed by downstream systems that do not hold the full authoritative state.

In compact form, the comparison now looks like this:

Where The Mission Model Still Adds Something

This is the key part.

Even if AAuth is the better substrate, I do not think it obviously removes the need for the Mission architecture.

1. purpose is not the same thing as a Mission

AAuth has a purpose field, and that is useful. It is also slightly richer than pure display text: AAuth’s clarification chat mechanism (Section 11.4) allows users to ask questions about the stated purpose during authorization, so purpose is conversationally live during the exchange, not just a consent label.

But purpose is still a free-form human-readable string. The spec defines no allowed values, no machine-processable semantics, and no policy-enforcement hooks. It is not automatically:

• a durable authority object
• a versioned authority model
• a lifecycle record
• an audit artifact
• a bounded authority envelope

Mission-Bound OAuth’s strongest idea is not “show more purpose text to the user.” It is “treat delegated authority itself as a governed object.”

2. Deferred approval is not the same as lifecycle governance

AAuth clearly has a better pending/approval story than OAuth.

What is less clear is whether the resulting authorization becomes a durable lifecycle object that can later be:

• suspended
• resumed
• revoked independently of token refresh
• terminated by external business events
• inspected as its own governance record

That is still a separate architectural concern. Notably, the current AAuth draft explicitly puts token revocation out of scope. Section 20.10 states “Token revocation is not defined in this specification.” This is not an oversight; it is an explicit deferral. The only termination mechanism is expiry followed by refused renewal, which is reactive rather than proactive. There is also no event notification or business-event hook of any kind.

3. Chaining is not the same as a bounded authority envelope

AAuth’s chaining model gives provenance, but it introduces a specific least-privilege hazard: upstream_token is explicitly “not a scope ceiling” per the spec. Downstream authorization servers evaluate their own policy independently and may grant scope broader than what was authorized upstream. Without an explicit Mission-like envelope, nothing in the protocol prevents that expansion.

A chain of AAuth hops can expand effective authority, not just narrow it.

That is not a gap in AAuth’s design for its stated goals. It is a gap between AAuth’s chaining model and what Mission governance requires. The chaining model does not automatically define:

• what downstream discovery is inside approved bounds
• what requires fresh approval
• how jurisdiction, relationship, or business-process constraints are preserved
• how open-world exploration stays governable

That is exactly the job the Mission Authority Model was designed to do.

4. Better actor modeling is not yet the same as verified actor continuity

Mission-Bound OAuth now defines Verified Agent Binding explicitly: the Mission record is the binding anchor, sender constraining carries key continuity, the AS performs actor verification at exchange time, and cross-domain projection is treated as a degraded case unless live state is shared.

AAuth is directionally better here than OAuth because agent identity and proof-of-possession are closer to the protocol core. But that is still not the same thing as a defined continuity model that answers:

• what is the binding anchor for the approved actor, and how does it survive across AAuth interaction restarts or renewed requests
• how key continuity is enforced across upstream_token hops, where each AS is re-evaluating independently
• what exactly crosses a trust boundary in projected form, and what must remain authoritative at the home AS
• where actor continuity degrades to projection-only evidence, and what that means for enforcement at downstream resource servers

Signed requests make actor identity visible at each hop. They do not automatically define whether the actor presented at hop N is still the same actor the Mission originally approved, or whether a delegation event has occurred that requires fresh Mission authorization.

That still looks like Mission-profile work rather than something the current AAuth draft gives you automatically.

5. FGA still needs a bounded intermediate artifact

One of the more important arguments in Mission-Bound OAuth is that Missions make AuthZEN/FGA-style decisioning practical for agents by narrowing the search space.

That argument does not go away if the protocol substrate changes.

Even on AAuth, you still seem to need something like:

• a Mission Proposal
• an Approved Mission
• a Mission Authority Model

or you still face the same question:

how does open-ended intent become a bounded, evaluable authority context that policy engines can use safely?

6. Approval evidence and audit trail

Mission-Bound OAuth eventually had to make approval evidence a first-class artifact: what was shown, who approved it, and what authority model was actually bound to that approval.

AAuth has strong approval mechanics. What is less clear is whether the resulting authorization retains a verifiable approval artifact after the exchange completes. For regulated deployments in finance, healthcare, or government, this is a compliance requirement independent of how good the interaction flow is. A tamper-evident record of what was presented for consent, who approved it, and what authority was bound to that approval is required by regulation regardless of protocol quality. AAuth’s conversational approval model is much better than OAuth’s redirect, but the retention and verifiability of that evidence needs to be explicit in any Mission profile.

7. Headless and service-to-service missions

AAuth identifies agents via HTTPS URLs pointing to published metadata. That works well for internet-scale agents with public endpoints. It is a meaningful assumption for enterprise environments where internal microservices, batch jobs, and RPA workflows often have no public-facing HTTPS endpoints.

A Mission profile would need to address this for deployments where the executing actor is not a public agent with a well-known URL. The Mission record already separates mission_subject.sub and mission_client.client_id as the binding anchor. An AAuth Mission profile would need an equivalent internal-agent registration model for actors that cannot serve agent metadata at a well-known HTTPS address.

8. Authority compilation boundary

One of the stronger arguments in Mission-Bound OAuth is the separation between intent and compiled authority:

1
2
3
4
5
6
7

intent
  ->
Mission Proposal
  ->
Approved Mission
  ->
Mission Authority Model

AAuth’s purpose field carries intent forward, and its approval flow is much richer than OAuth’s. But the compiled authority artifact, the machine-evaluable model that gateways and policy engines reason over, does not appear automatically from a better approval flow.

That compilation step, from human-meaningful approval to machine-evaluable bounds, still looks like explicit profile work. Without it, every enforcement point has to re-derive what the approval meant from the same free-text inputs, with no guaranteed consistency.

9. Cross-domain semantics

AAuth is well suited to signed interactions, but that does not automatically answer:

• what authority crosses a trust boundary
• what should be projected versus re-evaluated
• whether the source authority object is preserved or remapped locally

The OAuth companion profile now answers this in one concrete deployment shape: keep the Mission authoritative at home, and use a reduced projection when a downstream same-IdP domain only needs a bounded subset. An AAuth-based architecture may not need the same mechanism specifically, but it would still need to answer the same projection question explicitly.

The Cleanest Alternative

The cleanest alternative is not:

“replace Mission-Bound OAuth with AAuth and forget the Mission idea.”

It is:

“use AAuth as the protocol substrate and express Mission semantics as an AAuth profile.”

That profile would likely add:

• a durable Mission record at the authorization server
• a projected Mission reference in auth artifacts
• Mission lifecycle independent of token expiry
• authority-envelope checks on downstream grants
• business-event termination hooks
• Mission-level audit and approval evidence

In that design:

AAuth replaces the OAuth transport and token choreography. The Mission remains the governance layer.

That may be the cleaner long-term architecture.

Open Questions for AAuth

Does AAuth want a durable authority object at all? If yes, the Mission architecture maps naturally onto AAuth as a profile. If no, AAuth is solving a different problem: cleaner authorization choreography, not governed delegated authority over time. That is worth knowing explicitly, because it determines whether “Mission governance on AAuth” is a natural extension or an awkward graft.

How does downstream attenuation fit? Mission-Bound OAuth has an open question around Biscuit-style attenuation and chained restrictions that does not disappear on AAuth. If anything it becomes more pressing, because AAuth is already more comfortable with chained, signed protocol artifacts. The right layering looks similar regardless of substrate: Mission governance decides whether the authority should exist and continue; a downstream attenuation mechanism decides how authority can be further narrowed or chained; the attenuation layer must remain bounded by the Mission. AAuth’s native comfort with signed chaining makes it a better place to answer this question.

Is purpose meant to become structured? purpose is conversationally live during authorization, which is a real advantage. But it is not machine-processable or policy-bearing in the current draft. Is that the intended long-term design, or should it become a structured, URI-identified authority claim? Section 9.1 of the draft acknowledges the gap and defers to a future version. The answer to this question determines how much of the Mission Authority Model compilation step an AAuth profile would need to define explicitly.

Does upstream_token imply a scope ceiling? The current spec is explicit that it does not: downstream authorization servers evaluate their own policy independently. For Mission governance, that is a significant gap. A Mission profile would need to define whether the Mission envelope overrides this behavior, and if so, how downstream ASes learn the ceiling and how violations are handled.

How should headless missions work? AAuth’s agent identity model assumes a publicly resolvable HTTPS URL. What is the identity and binding model for internal service agents, batch workers, and automation that have no public endpoint? Any enterprise-oriented Mission profile would need to define this, either through a companion registration mechanism or a fallback binding model for non-public agents.

What would the smallest useful Mission profile actually standardize? Not a full redesign, just the minimum that makes Mission governance on AAuth viable: a durable Mission record, a projected mission_ref claim, lifecycle states independent of artifact expiry, and a bounded expansion rule for upstream_token chains. That profile boundary matters because it determines what AAuth itself needs to change versus what lives purely in a companion specification.

Defining The AAuth Mission Profile

If the right long-term answer is “Mission governance on AAuth,” then the useful next step is not another abstract checklist. It is a concrete profile shape.

This is the AAuth Mission profile that seems to fall out of the comparison.

1. Mission Creation From Approved AAuth Requests

An approved AAuth interaction should not terminate at “authorization granted.” It should produce a durable Mission record at the authorization server.

The profile boundary is:

The key rule is simple: the live request is not the durable authority object. It is the input from which the durable authority object is created.

2. Mission Record And Mission Reference

The profile should define two distinct things:

• a durable Mission record held by the AAuth authorization server
• a projected mission_ref carried in auth artifacts and chained requests

That gives the AAuth-based design the same separation that Mission-Bound OAuth now uses:

• the server governs the authoritative Mission record
• protocol artifacts carry a projected reference
• downstream systems reason over projected facts, not the full internal record

Without that split, AAuth interactions stay cleaner than OAuth, but the architecture still lacks a stable authority object that survives across chained execution.

The service boundary can also stay looser than this post has mostly assumed. One plausible long-term architecture is not only “AAuth plus Mission profile” but “AAuth plus separate Mission authority service,” where the AAuth authorization server consumes Mission state instead of owning it directly. That is closer to the control-plane model from the original Power of Attorney series and may be the cleaner separation if AAuth matures into the transport layer while Mission governance remains its own system of record.

3. Machine-Evaluable Mission Authority Model

The profile should define a machine-evaluable Mission Authority Model derived from the approved Mission, not just from the current request state.

At a minimum, that model needs to carry:

• purpose class
• bounded resource selectors or equivalent authority envelope
• operation groups or action classes
• lifecycle bounds
• delegation bounds
• approval attenuations

And it needs an explicit access path for enforcement points, for example:

• Mission introspection
• a signed Mission Authority Model artifact
• tightly bounded Mission-derived claims in AAuth auth artifacts

This is the same separation Part 1 had to make on OAuth:

1
2
3
4
5
6
7

approved request
  ->
Approved Mission
  ->
Mission Authority Model
  ->
projected artifacts for runtime use

The protocol substrate may change, but the architecture still needs that artifact stack.

4. Lifecycle Independent Of Token Expiry

The profile should define Mission lifecycle as separate from the lifetime of any single AAuth artifact.

That means the Mission can be:

• suspended
• resumed
• revoked
• completed
• expired

and those states must govern whether new artifacts can be issued or chained, independent of whether a previously issued token or authorization artifact is still structurally valid.

This is where AAuth’s stronger interaction model stops being enough on its own. Deferred approval is not lifecycle governance. A Mission profile has to add that layer explicitly.

5. Approval Evidence As A Retained Artifact

The profile should define approval evidence as something the authorization server retains in a tamper-evident form.

At minimum, that evidence has to answer:

• what the user was shown
• what the user approved
• what authority model was bound to that approval
• what attenuation or clarification happened before approval

That is especially important if AAuth’s conversational approval flow becomes one of its main differentiators. The richer the interaction, the more important it becomes to retain the evidence of what actually happened.

6. Verified Actor Continuity

The profile should define actor continuity explicitly, not assume it falls out automatically from signed requests.

At minimum, it needs to answer:

• what binds the approved actor to the Mission record
• how that actor is re-verified at each chained derivation step
• when a new actor is treated as a delegation event
• what is authoritative in the home domain
• what degrades to projection-only evidence across trust boundaries

This is where the AAuth profile should parallel the Verified Agent Binding work in Mission-Bound OAuth rather than hand-wave past it.

7. Cross-Domain Projection Rules

The profile should define what crosses a trust boundary and what must stay local.

That means distinguishing:

• the authoritative Mission record, which stays at home
• the projected Mission reference
• the reduced set of Mission-derived facts another authorization domain may rely on
• the facts that must always be re-evaluated locally

An AAuth Mission profile may not need ID-JAG specifically, but it still needs the same architectural answer the OAuth companion profile now gives: reduced projection, not portable authority.

8. Bounded Expansion For Open-World Execution

The profile should define a bounded expansion model that overrides the current upstream_token “not a scope ceiling” behavior.

The key question is the same one the OAuth architecture had to answer:

Is this newly discovered downstream action still inside the approved Mission envelope, or does it require fresh approval?

If the profile cannot answer that mechanically, then AAuth’s cleaner chaining model still leaves the core governance problem unresolved.

9. Orchestration-Layer Landing

The profile also has to land in the runtime, not just in the authorization server.

That means the AAuth-side architecture needs an answer for:

• how an orchestrator pauses or terminates execution when Mission state changes
• how irreversible steps trigger escalation instead of blind retry
• how compensating or unwind behavior is tied to Mission lifecycle rather than left as local runtime convention

This is the same lesson as in the OAuth architecture: a governed authority object that never reaches execution control is only partially real.

A Compact Profile Summary

In compact form, the AAuth Mission profile would need to define:

That is not a full protocol redesign. It is a governance layer on top of a cleaner substrate.

And it still does not eliminate the need for a continuous authority evaluation layer distinct from request authorization. AAuth may be the cleaner transport, but Mission governance still has to answer whether execution should continue as conditions change over time, not merely whether the next signed request is well-formed and in-bounds.

Conclusion

The framing that matters is not “Mission-Bound OAuth or AAuth.” It is “Mission governance on OAuth” versus “Mission governance on AAuth.” That separation is more useful because it keeps the governance model distinct from the transport substrate.

AAuth changes the protocol layer substantially, in ways that make it a better substrate for agent authorization. It does not change the underlying requirement: delegated machine authority needs to be represented as a governed object, not just as a better interaction flow.

If Mission-Bound OAuth is the retrofit, AAuth may be the native habitat.