Hi Jonathan, Peter, all, While AAuth Protocol (draft-hardt-oauth-aauth-protocol <https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/>, R3 ( draft-hardt-aauth-r3) <https://datatracker.ietf.org/doc/draft-hardt-aauth-r3/>, and Mission <https://github.com/mcguinness/mission-bound-authorization> developing in parallel, we shared notes and compared how each approached many of the same problems.
That helped validate a design principle we have been using throughout the Mission work, which we walked through at the recent OAuth Mission-Bound Authorization interim <https://datatracker.ietf.org/meeting/interim-2026-oauth-10/session/oauth>: define Mission as a durable, substrate-neutral approved-work boundary, then realize it using the native mechanisms of each authorization substrate. For the OAuth binding, the test has been simple: if a reusable OAuth mechanism exists or is being developed for identity, discovery, structured authorization, deferred interaction, delegation, federation, or transaction authorization, profile it rather than create a Mission-specific equivalent. The companion drafts should stay thin and add only the semantics and invariants needed to bind those mechanisms to approved work. This is similar to the compositional discipline in AIMS ( draft-ietf-wimse-aims) <https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/>, which assembles existing and emerging identity and authorization standards into an agent architecture rather than defining another end-to-end protocol. Mission applies that discipline specifically to approved-work governance, while defining the durable Mission boundary and its invariants where there is not already a substrate abstraction to reuse. For the OAuth binding, the mapping is roughly: Function Reusable OAuth / adjacent substrate What the Mission OAuth binding adds *Identity & discovery* Attestation-Based Client Authentication <https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/> , Client Instance Identification <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-id/> , AS Metadata <https://datatracker.ietf.org/doc/rfc8414/>, Protected Resource Metadata <https://datatracker.ietf.org/doc/rfc9728/>, RAR Metadata / Remediation <https://datatracker.ietf.org/doc/draft-ietf-oauth-rar-metadata-remediation/> Bind approved work to authenticated client/instance context and advertise Mission capabilities on existing metadata surfaces *Structured authority & approval* PAR <https://datatracker.ietf.org/doc/rfc9126/>, RAR <https://datatracker.ietf.org/doc/rfc9396/>, Resource Indicators <https://datatracker.ietf.org/doc/rfc8707/>, DTR <https://datatracker.ietf.org/doc/draft-ietf-oauth-deferred-token-response/> Mission <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html> adds the Proposed Mission, committed Authority Set, approval semantics, and narrowing invariant; Mission Deferred Approval <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html> applies the DTR model for deferred interaction *Issuance & lifecycle* JWT Access Token Profile <https://datatracker.ietf.org/doc/rfc9068/>, Token Introspection <https://datatracker.ietf.org/doc/rfc7662/>, Token Status List <https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/>, Shared Signals Framework <https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html> Mission binding, active-state issuance gating, Mission Status and Lifecycle <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html> , Mission Status List <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status-list.html>, and Mission Lifecycle Signals <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html> *Delegation, federation & context propagation* Token Exchange <https://datatracker.ietf.org/doc/rfc8693/>, Actor Profile <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/>, Identity Chaining <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/>, ID-JAG <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/> , ICA <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-id-continuation-assertion/> , Transaction Tokens <https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/> Mission Expansion <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html> , Cross-Domain Projection <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>, and Mission Continuation <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-continuation.html> preserve the approved-work boundary across derivation, actors, hops, and domains while allowing transaction context to propagate independently *Action-time authorization & presenter binding* Transaction Authorization Challenge <https://datatracker.ietf.org/doc/draft-rosomakho-oauth-txn-challenge/>, DTR <https://datatracker.ietf.org/doc/draft-ietf-oauth-deferred-token-response/> , DPoP <https://datatracker.ietf.org/doc/rfc9449/>, OAuth mTLS <https://datatracker.ietf.org/doc/rfc8705/> Mission Transaction Authorization <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-transaction-authorization.html> requires the concrete transaction and any fresh decision to remain inside the active Mission while preserving presenter binding *Runtime & oversight* AuthZEN Authorization API 1.0 <https://openid.net/specs/authorization-api-1_0-final.html>, Token Introspection <https://datatracker.ietf.org/doc/rfc7662/>, Token Status List <https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/>, Shared Signals Framework <https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html>, local policy Mission Runtime <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html> defines the substrate-neutral enforcement contract; the Mission Runtime OAuth Adapter <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime-oauth.html> maps OAuth credentials into it; the Mission AuthZEN Profile <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html> maps the decision model onto AuthZEN We also used early DTR prototypes to test whether the abstraction could grow beyond polling. SSE streaming <https://github.com/mcguinness/draft-mcguinness-oauth-deferred-code/blob/main/proposals/sse-streaming.md>, a revisable grant mode <https://github.com/mcguinness/draft-mcguinness-oauth-deferred-code/blob/main/proposals/revisable-grant-mode.md>, and webhook result delivery <https://github.com/mcguinness/draft-mcguinness-oauth-deferred-code/blob/main/proposals/webhook-result-delivery.md> were experiments, not publication-track mechanisms. The goal was to validate the extension model without forcing every interaction or delivery pattern into the core protocol. Against that decomposition, there are a few useful approaches to compare. The Hardt AAuth Protocol <https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/> and R3 <https://datatracker.ietf.org/doc/draft-hardt-aauth-r3/> provide a purpose-built, batteries-included agent authorization stack. AAuth integrates identity, proof of possession, discovery, authorization, federation, interaction, and its native mission and governance model. R3 closes the authority loop by turning resource-declared requirements into enforceable grants, with issuer policy, user consent, per-call decisions, content-addressed binding, and audit provenance. That integrated model removes substantial composition and integration complexity, which is a real advantage for implementations that want a native end-to-end agent authorization system rather than integrating comparable capabilities across a broad set of OAuth specifications and extensions. The Rosenberg OAuth AAuth draft <https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-02.html> takes another approach, defining a specific OAuth reactive-elevation flow built around an RS-signed scope_challenge, approval, request_code, and polling/SSE/WebSocket completion. Mission sits at a different layer. Like AIMS, it follows a compositional approach rather than replacing the underlying identity and authorization mechanisms. Mission defines the approved-work governance abstraction and binds it to each substrate's native authorization model. In OAuth, that means composing the existing ecosystem rather than rebuilding those functions inside Mission. In AAuth, it means preserving the native mission reference, Person Server governance, and resource authorization model, including R3 where used, rather than imposing OAuth's Authority Set semantics. The OAuth realization then gives us a fairly complete path: identify -> discover -> propose -> approve -> issue -> delegate -> cross domains -> continue -> authorize action -> decide -> enforce -> observe lifecycle HITL, HOTL, and HOOTL are operating modes over that same governance model, not different authorization models. What changes is where interaction and supervision occur; the approved-work boundary does not. In the OAuth binding, at action time, a request may remain within the Mission Authority Set and proceed subject to current policy and runtime checks, remain within it but require a fresh transaction decision, or exceed it and therefore require Expansion or new approval. The common abstraction is approved work; its realization stays substrate-native. OAuth composes the OAuth ecosystem, while AAuth preserves its native mission, Person Server governance, and R3/resource authorization model. Happy to chat more about this in San Francisco! -Karl On Sun, Nov 1, 2026 at 11:01 AM Jonathan Rosenberg <[email protected]> wrote: > We had an OAuth interim meeting a few weeks back on the topic of AI agent > authorization flows, discussing Dick's draft which is addressing that need. > At the time, there was interest raised around solutions for this problem > which can be done using an OAuth extension (namely, via a new grant flow), > rather than a totally new protocol. > > In response to this interest, myself and Pat White revived our prior draft > on this topic, filled out significant details, and we have just submitted: > > https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-02.html > > There is a brief overview which I think gets the general idea across ( > https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-02.html#name-brief-overview-of-operation > ) . This also has a section which compares this with Dick's document. > > I'll be in SF and am interested if there is community interest in pursuing > a solution like this. > > Thx, > Jonathan R. > > > > > -- > Jonathan Rosenberg, Ph.D. > [email protected] > http://www.jdrosen.net > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
