Note that EMVCo released a specification for the specific use case of Agentic Payment that has the notion of Payment Mandate and Checkout mandate as well as the correlation in between the two: https://www.emvco.com/resources/emv-agentic-payments-framework-for-specifications-v1-0-draft-comment-period-ends-30-sept-2026/
Jean-François “Jeff” Lombardo | Amazon Web Services Principal Standards Specialist, Identity Services Montréal, Canada -----Original Message----- From: Ron Bartor <[email protected]> Sent: September 30, 2026 8:31 AM 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 Iman, That separation is the right one, and your purchase test is sharper than anything in my write-up. Reserve A at one RS, charge for B at another, each permitted locally, both carrying the goal ID, and the goal not met. Every party that checks one operation at a time says yes, so none of them can see that the two operations don't add up to the purchase. It also changes where I'd put the requirement. I had the task-in-goal check at the goal holder before a task is issued. Your case shows a second check after the fact: whoever asserts that the goal was satisfied needs an authenticated, typed answer from each RS about what it did, and needs to compare those answers across RSs. The RSs don't have to share a policy language for that; the answers have to be typed and the comparison has to have something to compare on, an order line or an item reference that both parts carry. The goal ID on its own doesn't give you that. I'd like to take you up on the offer. I'll add your test as the positive and negative case in the write-up, stated as an obligation on the information rather than on where the comparison runs, and send the revised version to the list this week. If you can point me at your exact-action case, I'll state mine in the same form so the two read as a pair. Ron On Tue, 29 Sept 2026 at 23:25, Iman Schrock <[email protected]> wrote: > > Hi Ron, > > Your gateway case makes the ownership question concrete. I would separate who > asserts that the decomposition satisfies the owner’s goal from who authorizes > each RS’s actual operation. > > A useful test could be a purchase where one RS reserves product A and another > charges for product B. Each local operation may be permitted, and both may > carry the same goal ID, without jointly satisfying the intended purchase. The > goal ID alone cannot establish that correspondence. > > The RSs need not share a policy language, but whichever party claims goal > satisfaction needs enough authenticated, typed information to make that > comparison. Your use case could help the design team state that obligation > without prematurely prescribing a new cross-service evaluator. > > I’d be glad to help turn it into a small positive/negative case alongside the > exact-action case I mentioned. > > Best, > Iman > > > > On Tue, 29 Sep 2026 16:08:36 -0700, Ron Bartor <[email protected]> wrote: > > 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-bounda > ry/> > and an open vector pack > > <https://github.com/emiliaprotocol/emilia-protocol/tree/main/conforman > ce/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-2 > 02607240700-00 > [2] > https://datatracker.ietf.org/doc/polls-126-oauth-202607240900/ [3] > > https://datatracker.ietf.org/meeting/126/materials/slides-126-oauth-se > ssb-policy-language-binding-for-oauth-00 > Best regards,Dapeng Liu > > > _______________________________________________ > 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] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
