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’s
draft:Mission-Bound Authorization for OAuth 2.0.
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
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 thanks for the shout out.
@Ron Bartor, 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
<[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 and an open vector pack 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]> 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, 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, 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]
