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 <[email protected]<mailto:[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, "刘大鹏(鹏成)" <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
