Thanks, Thi. Agreed, these are two different questions, and the architecture keeps them apart on purpose.
Apologies, I used "left empty" as shorthand in my email, not the drafts. Runtime enforcement lives in a companion, Mission-Bound Runtime Enforcement <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>; that split is the layering cost I mentioned to Alex. Under its runtime contract <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html#runtime-contract>, a consequential action executes only after a permit that evaluates the action and its concrete parameters against the approved Mission, and the permit is bound to those parameters. The Mission must be active within a published staleness bound. Token possession alone never suffices, and every consequential phase of a compound action gets its own decision. So the check repeats at every action, not just at approval. The AuthZEN profile <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html> puts that contract on the wire: it maps the decision inputs onto an AuthZEN evaluation request, so a PEP and PDP interoperate on decisions alone. On who is acting, I'd split "right person, right device" into two parties: - *The agent.* Agent identity says who is acting; the Mission says why its authority exists <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html#three-objects>. The runtime takes the authenticated client, the delegation chain, attested instance context and registry state as actor inputs <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html#input-actor>, and each gates independently: a valid credential never overrides a revoked agent. Sender-constrained credentials pin possession, and mediated custody <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html#custody> can keep the key out of the agent entirely. - *The human.* For high-consequence actions, a deployment should require a fresh action-bound approval <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html#action-approval>, bound to the concrete parameters and resolved on a surface the agent can't drive. It composes with RFC 9470 step-up, but step-up alone doesn't approve an action. In the AuthZEN profile, a missing approval is an approval_required denial; the PEP can request one through the AuthZEN Access Request and Approval Profile <https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0> and present it on a fresh evaluation <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html#context-approval>, where it is checked against the parameter digest as input, never as a bearer grant. PSEA fits here: evidence that a present, verified human approved a specific action is the kind of input that approval can carry. I agree with you on frequency. The runtime says to reserve this for actions that warrant a pause, because applied broadly it trains rubber-stamping. On a key that only works while the conditions hold: agreed, and the validity model <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html#validity-model> treats it as first-class. A short lifetime moves the check to re-issuance, so each renewal is the policy re-check, and authority lapses when the conditions fail, with no revocation message. The limits are that something still has to observe the conditions at renewal, and worst-case exposure equals the lifetime. That's why the high-consequence classes also need an active freshness source. Thanks, Karl On Thu, Oct 1, 2026 at 2:46 PM Thi Nguyen-Huu <[email protected]> wrote: > Hi all. > > > > If I understand correctly: > > > > Ron's example shows the problem clearly: the reservation is for product A, > but the charge is for product B. Nothing catches this, because the check > happens when the mission is approved, not when each action actually happens. > > > > Everyone in this thread, including Karl's design, is working on > authorization: was this the right thing to approve, did we understand the > request correctly, does each step still match what was approved. Karl's own > outline even has a step called "runtime enforcement," but it's left empty. > > > > If that's a fair read, there's a second question nobody's asking yet: is > the one doing this action right now still the one who was approved for it? > That's authentication, not authorization. Left alone, I'd guess "runtime > enforcement" becomes another authorization check — does this still match > the approved scope — not a check on who is actually there. > > > > Mohamad Yossif's PSEA draft already asks for this directly: proof that a > real human is present, and that the device is trustworthy, at the moment of > the action — not just proof the action was authorized. Maybe the design > team should treat this as its own topic, separate from goal-tracking and > schema discovery. > > > > One more thought, building on Mohamad's idea: proving someone is present > doesn't have to mean asking them to approve something again and again. A > mission record is a decision made once, then trusted later. Checking a > request against it only tells you the request matches what was approved — > it says nothing about what's happened since. A different approach: give the > agent a key that only works while the original conditions are still true — > right person, right device. If those conditions stop being true, the key > simply stops working. No revoke message needed, because there's nothing > left to revoke. > > > > This isn't a competing proposal to Karl's draft, or to Mohamad's. It fills > in the empty "runtime enforcement" step Karl already left open, and it's > one way to get what Mohamad is asking for, without needing to ask the human > again every time. > > > > Cheers > > > > *Thi Nguyen-Huu* > > *CEO* > > winmagic.com > > 11-80 Galaxy Blvd. > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > | > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > Toronto, ON > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > | > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > M9W 4Y8 > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > | > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > Canada > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > > > > *From:* 刘大鹏(鹏成) <[email protected]> > *Sent:* Thursday, October 1, 2026 5:11 PM > *To:* Lombardo, Jeff <[email protected]>; Yaron ZEHAVI < > [email protected]>; Ron Bartor <[email protected]>; Karl > McGuinness <[email protected]> > *Cc:* [email protected]; Iman Schrock <[email protected]> > *Subject:* [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> > > CAUTION:This email originated from outside of the organization. Do not > click links, open attachments or respond unless you recognize the sender > and know that the content is safe. > > > > Hi Jeff and all, > > > > I think whether the problem is real and whether there is enough > interest in the WG to work on it are separate from the question > of which draft would be the solution. > > That was the purpose of > the call for interest, and I read the replies so far as > interest in the problem itself rather than in any particular solution. > > > > The discussion in this thread reaches a similar problem from > several independent directions. We reached it ourselves earlier: > draft-liu-agent-operation-authorization was presented at IETF 125. > > It investigates how to extend OAuth to > express bounded work proposals from agents and the mechanism > for approving them. It shares much of the problem and solution > space discussed in this thread. > > > > I think the important question for the next steps and for the > upcoming IETF 127 meeting is whether the WG has enough support > for the problem space and enough interest to work on potential solutions. > > We do not need to limit ourselves to a specific draft > at this stage. If we agree on the problem, the WG or a design > team can work on the solution together. > > > > > > Regards, > > Dapeng > > ------------------原始邮件 ------------------ > > *发件人**:*Lombardo, Jeff <[email protected]> > > *发送时间**:*Thu Oct 1 23:47:20 2026 > > *收件人**:*Yaron ZEHAVI <[email protected]>, Ron Bartor < > [email protected]>, Karl McGuinness <[email protected]> > > *抄送**:*[email protected] <[email protected]>, Iman Schrock < > [email protected]> > > *主**题**:*[OAUTH-WG] Re: Call for interest: fine-grained authorization in > OAuth (IETF 126 follow-up) > > 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 [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]
