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; both 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:

Short Version

• AAuth already solves several things Mission-Bound OAuth has to assemble from multiple OAuth extensions.
• But AAuth does not obviously eliminate the need for a durable Mission authority object.
• The real comparison is not “OAuth or AAuth.”
• It is “Mission governance on OAuth” versus “Mission governance on AAuth.”

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 stretched 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 four 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.

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. 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?

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.

One Concrete Example

Take a simple example: an assistant schedules a meeting, sends invites, and records the follow-up in a CRM.

In Mission-Bound OAuth, the architecture says:

• the prompt becomes a Mission Proposal
• approval creates an Approved Mission
• the AS derives a Mission Authority Model
• token exchange for calendar, email, and CRM stays bounded by that Mission
• the Mission can later be suspended, revoked, or terminated when the business purpose ends

In AAuth, the same scenario already looks cleaner at the interaction layer:

• the initial request can be signed directly
• approval can be deferred with pending state
• the user can ask clarifying questions during authorization
• downstream calls can be chained more natively

But the same hard question remains after approval:

What is the durable object that says this assistant is still operating under the same governed authority across the calendar, email, and CRM steps?

If the answer is only “the current chained authorization artifacts,” then lifecycle governance, authority-envelope checks, and mission-level audit still look under-specified. If the answer is “a durable Mission-like object,” then the AAuth comparison becomes much cleaner: AAuth is the better protocol substrate, and the Mission remains the governance layer.

Open Questions for AAuth

The preceding sections point to two questions that matter more than the others.

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.

Additional Gaps Worth Naming

There are a few other gaps that seem worth calling out explicitly.

Approval evidence is still less explicit than it should be

Mission-Bound OAuth eventually had to make approval evidence a first-class artifact:

• what was shown
• who approved it
• what authority model was actually bound to that approval

AAuth has strong approval mechanics, but it is less clear whether it retains a verifiable approval artifact after the exchange completes. For regulated deployments — finance, healthcare, government — this is not an architectural preference; it is a compliance requirement. 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 how good the interaction flow is. AAuth’s conversational approval model is much better than OAuth’s redirect, but the retention and verifiability of the resulting evidence needs to be explicit in any Mission profile.

The machine-evaluable artifact is still underspecified

Mission-Bound OAuth had to distinguish between:

• the governance artifact
• the machine-evaluable authority artifact
• projected artifacts at protocol boundaries

AAuth currently looks stronger on interaction flow than on the long-lived machine-evaluable artifact that a gateway, PDP, or mission-aware resource server would rely on after approval.

Related: AAuth currently has no equivalent to OAuth Rich Authorization Requests (RAR). Authorization context is scopes, space-delimited strings, plus the free-text purpose field. Section 9.1 of the current draft acknowledges this explicitly: “A future version may define a URI-based authorization claim referencing a Rich Authorization Request document.” Until that lands, there is no structured, machine-processable authorization request format. Any Mission profile on AAuth would need to define that layer.

Cross-domain semantics are still open

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

Those remain architecture questions, not just wire-format details.

A staged adoption story would still help

One reason Mission-Bound OAuth became more practical was forcing a staged story:

• AS-side lifecycle first
• management plane next
• cross-domain and richer runtime enforcement later

AAuth would benefit from the same kind of realism. The rough equivalent on AAuth would look like:

• Stage 1: AS-side Mission lifecycle only. AAuth-issued auth tokens carry a mission_ref claim. The AS enforces Mission state at issuance and refuses renewal when the Mission is revoked or expired. No proposal API required.
• Stage 2: Mission management plane. Proposal submission, approval endpoints, Mission templates, and display representation are added as an AAuth companion protocol. Policy-controlled Mission issuance without per-client custom code.
• Stage 3: Cross-domain Mission assertions, SSF/CAEP integration for business-event termination, Mission introspection for live state queries at gateways and resource servers.

Even a cleaner protocol needs a credible entry path. Skipping directly to Stage 3 is how adoption stalls.

What AAuth Would Still Need for a Mission Profile

If the right long-term answer is “Mission governance on AAuth,” the smallest useful profile would still need to define a few things explicitly:

• a durable authority object created from the approved request, not just the current request state
• a projected Mission reference carried through auth artifacts and chained requests
• a machine-evaluable authority model that gateways, PDPs, or resource servers can rely on — with an explicit access mechanism (Mission introspection endpoint, signed Mission Authority Model artifact, or Mission-derived claims in the auth token)
• lifecycle state independent of token expiry, including suspension, revocation, and termination
• approval evidence that binds what the user saw to what the system later enforced, in a tamper-evident retained artifact
• bounded expansion rules for downstream discovery and chaining that override the current upstream_token “not a scope ceiling” behavior

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

My Current Position

• Mission-Bound OAuth is the practical retrofit path for the OAuth world we already have.
• AAuth looks like the cleaner protocol environment for the same underlying problem.
• But AAuth does not obviously eliminate the need for a Mission-like governance object.
• It may simply be the better place to put one.

The real choice may not be “Mission-Bound OAuth or AAuth.” It may be “Mission governance on OAuth” versus “Mission governance on AAuth.” That framing is more useful because it separates the governance model from the transport and protocol substrate.

That is the point of the comparison. It is not arguing that AAuth makes the Mission idea obsolete. It is arguing that AAuth may be the better place to host it.

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

If you are working on OAuth, AAuth, agent runtimes, or policy systems, the questions I care most about are:

• does AAuth already imply a durable authority object, or would it still need one to support Mission-like governance
• purpose is conversationally live during authorization but not machine-processable or policy-bearing in the current draft. Is that the right long-term design, or should it become structured?
• does upstream_token plus deferred approval already cover enough of the lifecycle problem to make a Mission object redundant? The spec itself says revocation is out of scope and chaining is exploratory, but the design intent matters.
• if not, what would the smallest useful “Mission profile for AAuth” actually need to standardize?