Thanks, Alex, for taking the time to share your feedback. -00 is quite dated now. I'll publish -01 in the next few weeks, and the editor's copy <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html> already reflects much of it.
The core deliberately separates two questions: what Authority Set was approved, and did the system correctly understand what was originally meant? The core gives a protocol guarantee around the first: the Authority Set is committed at the approval event, and later derived authority cannot exceed it. It does not claim to solve the second, and I don't think a protocol can. What the architecture does instead is make each boundary explicit and auditable: request, untrusted shaping, structured Intent, mechanical derivation, approval, committed Authority Set, runtime enforcement. The core is also one layer of a much larger Mission architecture <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html>, layered so that several answers below point to companions. To be candid, getting that layering right, what belongs in the core and what belongs in a companion, is something I'm still working through. Reviews like yours help. 1. Original intent. The core does capture the submitted Intent: it renders it beside the Authority Set and commits it as intent_hash. The narrower gap you've found is that nothing authenticates the requester's pre-shaping instruction. Mission Intent Shaping <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-shaping.html> can record that input as Shaping Evidence, including an input_digest and the shaper's resolutions and ambiguities. Its hash can be committed as part of the Consent Evidence associated with the approval. What isn't standardized is an evidence type that authenticates the provenance of that pre-shaping request. The Intent Submission Evidence <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-submission-evidence.html> framework is where such a type would plug in. 2. Rubber stamping. I agree there's a real comprehension limit, and the protocol cannot prove comprehension. What it can do is make the consent object complete, structured, layered and auditable. Consent Evidence <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-consent-evidence.html> defines a structured disclosure with material notices and constraint provenance, plus layered rendering and a question channel for the Approver. In -01 I'll make the comprehension caveat explicit in the approval section. I'll add rendering guidance too: grouping, summary with drill-down, flagged high-consequence entries, and when a set is too large to approve as a single decision. "Forget me" is exactly that case. Where policy-only drawdown or dispatch is used, irreversible actions such as deletion are excluded and fall back to a fresh human decision. 3. Granularity. Agreed. In -01 I'll name the trade-off between approval fatigue and blanket approval, with guidance on where the line sits. The architecture has separate mechanisms for the two shapes of the problem. Progressive Authorization <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.html> covers one evolving task that draws authority under an approved ceiling. Template <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-template.html> covers repeated instances of a recurring task under an approved ceiling and dispatch policy. 4. AI derivation. The editor's copy now does what you suggest. -00 permitted generating authority from free text; the editor's copy defines only two mechanical modes: narrowing a client proposal, and a configured lookup that is "not synthesis". A deployment can add generative processing as a local-policy extension, but it stays subject to the same Intent bounds. Under the normative prose boundary, changing goal, task_bounds or success_criteria alone cannot change the Authority Set. 5. Trusted Intent author. I agree separating shaping from execution is useful, and the Shaping companion does exactly that. Where I differ is making the shaper trusted. A generative shaper is still fallible and can be influenced by an attacker, so its output deliberately remains an untrusted proposal. It can produce auditable Shaping Evidence, and policy can require a defined Intent Submission Evidence type authenticating the request's provenance. Authority is still created only by issuer validation and approval. On AuthZEN: an evaluation request describes one authorization question. It's a good input to policy and to runtime enforcement, through the AuthZEN profile <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>, but it isn't the durable task object or approved envelope a Mission represents. For that, the draft already reuses an existing standard, RFC 9396 (Rich Authorization Requests). I'll open GitHub issues for 2, 3, and the provenance evidence type in 1. Comments there are welcome. Thanks, Karl On Thu, Oct 1, 2026 at 10:40 AM Alex Babeanu <[email protected]> wrote: > Hello all, > > I've been reading @Karl McGuinness <[email protected]>’s draft: > Mission-Bound > Authorization for OAuth 2.0 > <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-00>. > (draft-mcguinness-oauth-mission-00) and want to raise a set of concerns > about the proposed trust and consent model. > > 1. My main concern: There is no independent artifact of the Subject's > original intent anywhere in the specified system. The pipeline is > agent-proposed-text > → AS-derived authority → human approves authority. The thing the user > actually wanted never gets captured in a form anything can check against.. > Nothing in the protocol lets you later verify that the derived authority > actually corresponded to the subject's original instruction. > > 2. Rubber stamping. The spec cites: > > "Neither anchor proves the Approver understood the rendered task, nor that >> the AS rendered it faithfully; they commit what the AS recorded, and make >> post-hoc tampering of those records detectable." > > > Indeed, we can't rely on the user's approval, they may not even understand > the Authority Set they are tasked to approve. Everything downstream rests > on the human meaningfully consenting to a derived Authority Set, yet the > spec's only requirement is that the AS render it "in human-meaningful > terms." > > Concrete Example - human prompt: "*Forget me.*" - as in GDPR's Right to > be Forgotten. This can derive into dozens of cross-system delete actions > across databases, SaaS, and affiliates, etc. A very legitimate 2 word > prompt could therefore require the user to approve an Authority Set > containing potentially many actions (which might be gibberish to them). > > A human cannot act at this scale. This draft should add bounds or tiers on > Authority Set complexity, maybe require require summarization/progressive > disclosure, or an explicit statement that comprehension is out of scope and > why that's acceptable. > > 3. The previous point leads to the following: approval-granularity > guidance trades one risk for another without saying so. > Section 1.5 recommends narrow, per-task Missions, each separately > approved. Narrow Missions make each approval comprehensible (good) but > multiply the number of approvals a human faces in a multi-step workflow > (bad); coarse Missions do the reverse. The draft asserts the preference > without acknowledging the tension. I think it should name this trade-off > explicitly and give guidance on where the line sits, because the two > failure modes (approval fatigue vs. blanket approval) are both > consent-defeating. > > 4. AS Authority Set Generation. The way the AS derives the Authority Set > is left on purpose to local imnplementations. I doubt it will always be > possible to make this derivation deterministic (the preferred route of > course); this step may require AI Generation, in some cases at least. Now > section 5 calls this: "*the least portable and most semantically fraught > option*". Given that AI Generation at this step may lead to further > security issues, the draft should probably discourage this or at least > require some constraints here. > > 5 The authoring party for the Mission Intent should be constrained, not > left out of scope. > Section 4.1 places who produces the Intent — including a trusted "*Mission > Shaper*" — out of scope. Since the agent is explicitly untrusted, > allowing the untrusted agent to also author the proposal that seeds > derivation leaves "*the narrative is inert*" as the only mitigation. I'd > like the draft to consider requiring that the authoring component be > trusted and distinct from the agent executing the Mission. > > I.e., formalize the "Mission Shaper", calling it explicitly for what it > is, a Generative LLM-Backed Agent, i.e., an "Intent Agent". Call the > "Intent Agent" *before* the Actor client, and let it run on the > *Subject's* prompt. The Intent Agent should be separate and not directly > promptable by the user. It should not have any stake in the actual mission, > its only goal is to produce a parseable Mission (OpenID AuthZEN > evaluations is a better format for this, imho. Reusing an existing > standard would also greatly simplify this draft). The mission is now tied > to the *subject's* actual intention, not to the Agent's. And the Agent's > actions can now be validated against that Mission's Authority Set. > > Regards, > > ./\lex Babeanu. > > > On Thu, Oct 1, 2026 at 8:47 AM Lombardo, Jeff <jeffsec= > [email protected]> wrote: > >> Agreed with Yaron, I thought I provided the reference. It seems not. >> >> @Ron : The discussion is the right one, it just that I think we should >> have it as part of the Mission Draft instead of yet another Draft. >> >> >> >> Jeff >> >> >> >> *Jean-François “Jeff” Lombardo* | Amazon Web Services >> >> >> Principal Standards Specialist, Identity Services >> Montréal, Canada >> >> >> >> *From:* Yaron ZEHAVI <[email protected]> >> *Sent:* October 1, 2026 1:43 AM >> *To:* Ron Bartor <[email protected]>; Karl McGuinness < >> [email protected]> >> *Cc:* Lombardo, Jeff <[email protected]>; [email protected]; Iman Schrock >> <[email protected]> >> *Subject:* RE: [EXT] [OAUTH-WG] Re: Call for interest: fine-grained >> authorization in OAuth (IETF 126 follow-up) >> >> >> >> *CAUTION*: This email originated from outside of the organization. Do >> not click links or open attachments unless you can confirm the sender and >> know the content is safe. >> >> >> >> *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur >> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous >> ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas >> certain que le contenu ne présente aucun risque. >> >> >> >> Dear Ron, >> >> >> >> I think the goal enforcement you’re seeking may be found in @Karl >> McGuinness <[email protected]>’s draft: Mission-Bound Authorization >> for OAuth 2.0 >> <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-00> >> . >> >> It adds an AS-persisted durable higher level mission intent object, >> against which authority requests are evaluated at token issuance time. >> >> >> >> It should empower the authorization server to evaluate if reservation A >> and payment B are within the scope of the approved mission, apply policies >> to validate they’re related and if so issue the tokens for the relevant >> audience resource servers. >> >> >> >> Regards, >> >> Yaron >> >> >> >> >> >> Classification: GENERAL >> >> *From:* Ron Bartor <[email protected]> >> *Sent:* Thursday, October 1, 2026 3:58 AM >> *To:* Yaron ZEHAVI <[email protected]> >> *Cc:* Lombardo, Jeff <[email protected]>; [email protected]; Iman Schrock < >> [email protected]> >> *Subject:* Re: [OAUTH-WG] Re: Call for interest: fine-grained >> authorization in OAuth (IETF 126 follow-up) >> >> >> >> You don't often get email from [email protected]. Learn why this is >> important <https://aka.ms/LearnAboutSenderIdentification> >> >> This message is from an external sender - be cautious, particularly with >> links and attachments. >> >> >> >> Hi Jeff, Yaron, >> >> Yaron, thanks for the correction, and good to meet you. I was citing the >> old draft, my mistake. I'll cite draft-ietf-oauth-rar-metadata-remediation >> from here on and stop saying "per-RS discovery", since that's not what it >> does. The way I read it now, the metadata endpoint tells a client what the >> AS can issue, and what a particular resource actually needs you find out by >> calling it and getting the remediation back. I also take the gateway point. >> It relays the call and relays the remediation and doesn't need to know >> anything about the downstream types to do that. >> >> Jeff, agreed on the rest. Each RS says what it needs in RAR terms, the AS >> normalizes, and if there's a broker in front it adds one more layer and >> normalizes for its own client. That's the per-RS problem, and I think the >> draft handles it well. My write-up says as much. >> >> What I'm trying to point at is one step above that, and a concrete case >> is clearer than my first mail was. Say the goal is "buy product A". It >> turns into a reservation at an inventory service and a charge at a payments >> service (two RSs with their own vocabularies, and quite possibly two >> different ASs). Each RS remediates in its own terms, each remediation gets >> normalized correctly, each request gets authorized. Except the reservation >> is for A and the charge is for B. Nothing in that path compares the two, >> and I don't think anything in it can, because comparing them needs the >> goal, and the AS that has authority over the payments service doesn't hold >> the goal. It holds a grant for one service, not what the user was trying to >> do across several. >> >> Yaron's correction actually makes this a bit sharper. If there's no >> discovery ahead of time, whoever holds the goal can't decompose it into >> typed parts up front. It only learns what each RS needs when that RS >> refuses. So the question "is this remediation still within the goal" has to >> be asked on every remediation as it comes back, and then once more across >> all of them at the end. The gateway relays those without reading them, >> which is the right thing for a gateway. But somebody still has to read them >> against the goal, and that's the party I'd like the design team to name, >> whether it ends up being the client, the AS, the broker, or each RS for its >> own slice. If the answer is "the broker, when there is one", fine, that's >> an answer, but I'd rather it was said out loud, because it means the goal, >> and whatever evidence is needed to judge against it, lives at the >> intermediary. >> >> Jeff, I think your token exchange idea fits here. If an exchange can hand >> back a RAR remediation, the broker gets a typed remediation at token time, >> in the RS's own vocabulary, without having to be refused by the RS first. >> For the per-RS half of this across a broker hop that's probably the >> cleanest carrier, and I'll put it in the write-up next to ID-JAG. >> >> Ron >> >> >> >> On Wed, 30 Sept 2026 at 08:18, Yaron ZEHAVI < >> [email protected]> wrote: >> >> Hello everyone, >> >> >> >> @Lombardo, Jeff <[email protected]> thanks for the shout out. >> >> @Ron Bartor <[email protected]>, pleased to meet you 😊 >> >> >> >> One comment, OAuth 2.0 RAR Metadata and Error Remediation does not offer >> per-RS metadata discovery. >> >> This idea was explored in earlier drafts: >> >> >> https://www.ietf.org/archive/id/draft-zehavi-oauth-rar-metadata-03.html#name-oauth-20-protected-resource >> >> >> >> And removed following feedback from WG members. >> >> The idea was add to RFC 9728 RS metadata: >> >> >> >> "authorization_details_types_required": { >> >> "oneOf": ["payment_initiation", "payment_approval", >> >> "beneficiary_designation"] >> >> } >> >> >> >> With Boolean expressions allOf, and, or. >> >> This was deemed not very helpful as: >> >> - Different resources have different requirements (but in MCP the >> resource is not expressed on the http path) >> - Lots of logic which in the end doesn’t tell the client exactly >> which RAR types to request. >> >> >> >> Then the next idea was include the Boolean logic in the WWW-Authenticate >> header. Opted instead to return the actionable RAR object to remediate the >> failure. >> >> >> >> That being said, I think the task of RS-Gateways was made simpler. >> >> They don’t need to have foreknowledge to combine downstream RS metadata. >> >> >> >> Instead, client makes a request, a failing downstream RS may return the >> remediation payload. Gateway relays the calls without requiring additional >> metadata. >> >> >> >> Yaron >> >> >> >> >> >> Classification: GENERAL >> >> *From:* Lombardo, Jeff <[email protected]> >> *Sent:* Wednesday, September 30, 2026 4:08 PM >> *To:* Ron Bartor <[email protected]> >> *Cc:* [email protected]; Yaron ZEHAVI <[email protected]>; >> Iman Schrock <[email protected]>; Lombardo, Jeff < >> [email protected]> >> *Subject:* RE: [OAUTH-WG] Re: Call for interest: fine-grained >> authorization in OAuth (IETF 126 follow-up) >> >> >> >> This message is from an external sender - be cautious, particularly with >> links and attachments. >> >> >> >> Hi Ron, >> >> Speaking under the supervision of Yaron. I am not sure I follow the multi-RS >> decomposition problem you try to point at here. >> >> >> >> draft-zehavi-oauth-rar-metadata now >> draft-ietf-oauth-rar-metadata-remediation [ >> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar-metadata-remediation/] >> allows each RS to express the RAR-based mediated response along what the AS >> that has authority can speak in terms of RAR schema. >> >> >> >> It means that it is up to each AS to normalize the mediated response, If >> brokered through an API Gateway, this is just adding another layer and it >> is now up to the Gateway / Broker to normalize it for its client. >> >> >> >> As ID-JAG supports RAR, there could be an extension to Token Exchange to >> return a RAR remediation to ease this path. >> >> >> >> Jeff >> >> >> >> >> >> *Jean-François “Jeff” Lombardo* | Amazon Web Services >> >> >> Principal Standards Specialist, Identity Services >> Montréal, Canada >> >> >> >> *From:* Ron Bartor <[email protected]> >> *Sent:* September 29, 2026 7:09 PM >> *To:* Iman Schrock <[email protected]> >> *Cc:* [email protected] >> *Subject:* [EXT] [OAUTH-WG] Re: Call for interest: fine-grained >> authorization in OAuth (IETF 126 follow-up) >> >> >> >> *CAUTION*: This email originated from outside of the organization. Do >> not click links or open attachments unless you can confirm the sender and >> know the content is safe. >> >> >> >> *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur >> externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous >> ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas >> certain que le contenu ne présente aucun risque. >> >> >> >> Hi Dapeng, all, >> >> >> >> I support continuing this direction and would like to contribute to the >> design team. >> >> >> >> I wasn't in the room at 126, so apologies if this was covered, but I'd >> like to put one scenario on the table for the "goal state management" and >> "discoverable schema" pillars. I operate an enterprise API gateway that >> fronts MCP and agent traffic. A single agent request routinely fans out to >> several downstream resource servers, and each of those RSs owns its own >> authorization semantics: its own notion of what a task is, what the >> constraining attributes are, and how a request is scoped. Those semantics >> are not shared across services, and in some cases cannot be. A concrete >> example is an RS that was integrated from a separate business unit; its >> authorization model reflects its own history and is materially different >> from the rest of our services, and harmonizing it is neither quick nor, for >> some of its consumers, desirable. >> >> >> >> In that setting, per-RS schema discovery (as in >> draft-zehavi-oauth-rar-metadata) solves the local problem but not the >> cross-RS one: the goal has to be carried across trust domains that are >> mutually opaque, and something has to decide whether each downstream task >> is still within the goal without any RS seeing the others' vocabulary. The >> slides put "task in goal" evaluation out of scope, which I understand, but >> I think the design team should at least be explicit about where that >> evaluation lives in a multi-RS decomposition (client, AS, >> gateway/intermediary, or each RS independently) and what the goal-state >> representation needs to look like so that it remains meaningful to an RS >> that only understands its own schema. >> >> >> >> I'd be glad to write this up as a concrete use case, and I think it fits >> naturally with the RS-to-client signaling work already in the WG >> (txn-challenge, client-challenge, RAR-metadata) rather than requiring new >> machinery. >> >> >> >> Best regards, >> >> Ron Bar-Tor >> >> >> >> On Tue, Sep 29, 2026 at 3:13 PM Iman Schrock <team= >> [email protected]> wrote: >> >> Hi Dapeng, >> >> I support continuing this work. One boundary I would like the design team >> to test: a goal-level authorization can help a client negotiate what an RS >> requires, but it is not approval of the eventual exact action. A changed >> payment destination after negotiation, or a lost response after provider >> entry, needs its own decision and recovery rule. >> >> We have published AEB >> <https://datatracker.ietf.org/doc/draft-schrock-action-evidence-boundary/> >> and an open vector pack >> <https://github.com/emiliaprotocol/emilia-protocol/tree/main/conformance/aeb-1> >> for that boundary. I would be glad to bring a small cross-system case to >> the design team and see where it belongs alongside existing OAuth work. >> >> Best, >> Iman >> >> >> >> On Wed, 30 Sep 2026 00:19:52 +0800, "刘大鹏(鹏成)" <max.ldp= >> [email protected]> wrote: >> >> Hello all, During IETF 126 we had a discussion on how OAuth can support >> fine-grained authorization for AI agents [1]. The topic generated a lot of >> interest in the room, and the poll showed support for continuing the >> discussion [2]. A quick summary of the problem space as presented in the >> session [3]: 1. Enabling clients to construct fine-grained authorization >> requests using: a. Goal state management, b. Discoverable domain-specific >> schemas for task and authorization definition, c. Task-in-goal evaluation >> requests 2. Establishing a negotiation pattern that allows a resource >> server to guide clients towards the required authorization The session also >> proposed forming a design team to explore this space [3]. Before IETF 127, >> we would like to hear from the WG: - Is this a direction the community is >> interested in pursuing? Replies on the list will help shape the discussion >> at IETF 127. [1] >> https://datatracker.ietf.org/meeting/126/materials/minutes-126-oauth-202607240700-00 >> [2] https://datatracker.ietf.org/doc/polls-126-oauth-202607240900/ [3] >> https://datatracker.ietf.org/meeting/126/materials/slides-126-oauth-sessb-policy-language-binding-for-oauth-00 >> Best regards,Dapeng Liu >> >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> This message and any attachment ("the Message") are confidential. If you >> have received the Message in error, please notify the sender immediately >> and delete the Message from your system, any use of the Message is >> forbidden. Correspondence via e-mail is primarily for information purposes. >> RBI neither makes nor accepts legally binding statements via e-mail unless >> explicitly agreed otherwise. Information pursuant to § 14 Austrian >> Companies Code: Raiffeisen Bank International AG; Registered Office: Am >> Stadtpark 9 >> <https://www.google.com/maps/search/Am+Stadtpark+9?entry=gmail&source=g>, >> 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial >> Court of Vienna (Handelsgericht Wien). >> >> This message and any attachment ("the Message") are confidential. If you >> have received the Message in error, please notify the sender immediately >> and delete the Message from your system, any use of the Message is >> forbidden. Correspondence via e-mail is primarily for information purposes. >> RBI neither makes nor accepts legally binding statements via e-mail unless >> explicitly agreed otherwise. Information pursuant to § 14 Austrian >> Companies Code: Raiffeisen Bank International AG; Registered Office: Am >> Stadtpark 9 >> <https://www.google.com/maps/search/Am+Stadtpark+9?entry=gmail&source=g>, >> 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial >> Court of Vienna (Handelsgericht Wien). >> _______________________________________________ >> 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]
