Ron, thanks for filing #1051 <https://github.com/mcguinness/mission-bound-authorization/issues/1051>; that's the right home for continuing the conversation.
Kieran, I agree that what matters is the artifact rather than where it lives. The Mission architecture addresses this with a companion, Mission Mandate <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.html>: an issuer-signed JWT (or SD-JWT, for selective disclosure) committing to the approved Authority Set and intent, which anyone can verify against the issuer's published keys. It is evidence, never a credential. On freshness, it records state as of minting, so a verifier still checks current state with the issuer. It won't compute Ron's join by itself, though. Runtime evidence records carry parameter digests, not fields, so an auditor can't compare a shared field across services without per-field commitments (an option in #1019 <https://github.com/mcguinness/mission-bound-authorization/issues/1019>). And I wouldn't put the typed vocabulary in the Mandate: what an RS's fields mean is that RS's declaration (Yaron's layer), not something the issuer can sign for. As Ron notes in #1051, evidence alone won't catch the item mismatch. If you'd like to take this further, please comment on Ron's issue <https://github.com/mcguinness/mission-bound-authorization/issues/1051>. Thanks, Karl On Tue, Oct 6, 2026 at 10:12 AM Kieran Sweeney <[email protected]> wrote: > Ron, your correction sharpens the problem into one sentence: the record > exists per PDP, and the join sits where no party stands. I read that as a > symptom rather than the gap. The Mission lives at the AS, History lives at > each PDP, and section 16 puts cross-PDP composition out of scope because no > single party holds both the goal and all the typed records. Every fix > proposed so far picks a residence for the semantics: Yaron publishes them > from the RS, your issue asks the mission layer to host the join, Karl keeps > the Authority Set at the AS. Each residence reproduces the problem one > layer out, at the gateway that sees part of the traffic, at a second AS, at > the auditor after the fact. > > The thing to constrain is the goal artifact, not where it lives. Make the > Mission a portable, self-contained artifact: the committed Authority Set, > the intent hash, and the typed vocabulary the records are written in, > signed and presentable. Then any party holding the artifact and the records > can compute your join, the inventory PDP, the payments PDP, a gateway, or > an auditor holding neither service. Your own tie to Yaron points here: if > the RS metadata fields and the post-execution record fields are the same > declaration, the artifact binding them is the only missing piece, and > nothing about it requires the AS to be present at evaluation time. That is > the issue I would file against section 16. Not "compose the PDPs", which > needs a protocol between every pair of parties, but "make the Mission > evaluable by any party", which needs a common artifact and record > semantics. Portability still needs an explicit trust and freshness > contract: who signs it, how a verifier binds each record to the Mission and > its version, and how revocation and incomplete History are handled. The > artifact makes the join possible where those inputs are available; it does > not establish that every evaluator has a complete record set. > > Kieran > > On Fri, Oct 02, 2026 10:09 PM, Ron Bartor <[email protected]> wrote: > >> Hi Karl, >> >> A correction to my own section 8, after reading the runtime companion >> properly rather than from the thread. The per-action record I asked >> for already exists. Section 11 has every decision and refusal leave an >> integrity-protected record, with execution-outcome evidence for >> high-consequence actions, and the History input in 2.7.8 lets a PDP >> evaluate predicates over the Mission's prior evidence. So I was asking >> for something you've already built. >> >> What's left of my ask is narrower, and it's the part section 16 leaves >> out. History is composed per PDP and per deployment, and cross-PDP >> composition is out of scope. In my negative case the inventory PDP can >> see the reservation and the payments PDP can see the charge, and >> nothing compares the two. That's the join, and it now sits between >> your section 11 and your section 16 rather than outside the drafts. >> >> I'll frame the GitHub issue that way, against those sections, rather >> than as a request for a new record. >> >> Ron >> >> On Fri, 2 Oct 2026 at 19:01, Ron Bartor <[email protected]> wrote: >> > >> > Hi Yaron, >> > >> > Thanks, that's the right split, and I'll stay on the second layer. >> > >> > Your first layer is R2 in my write-up, and publishing the semantics >> > from the resource's own metadata is a better answer to it than the >> > refusal-driven one I had. It also makes my case sharper rather than >> > weaker. In your example the payments authority is bound to source >> > account, destination and amount, which is everything payments can >> > say about a charge. It has no item, because payments doesn't have >> > one, so a charge for the wrong product is within the Mission on >> > every field the metadata can express. That's the join I'm after, >> > and it has to happen somewhere other than at issuance. >> > >> > One tie between the layers. The fields your metadata declares, type, >> > actions, constraints, effects, are the fields the post-execution >> > record should carry too. If the RS says up front what its authority >> > means, the record of what it did can be typed against the same >> > declaration, and the cross-RS comparison has something to compare on. >> > >> > Ron >> > >> > >> > On Fri, 2 Oct 2026 at 14:54, Yaron ZEHAVI >> > <[email protected]> wrote: >> > > >> > > Hi all, >> > > >> > > >> > > >> > > I agree with Alex’s concerns, and I think this highlights a metadata >> gap. >> > > >> > > >> > > >> > > Today an AS or RS can publish scopes_supported / >> authorization_details_types_supported, but that tells only which strings >> are accepted, not what authority this represents, in a way a PDP can >> evaluate. >> > > >> > > >> > > >> > > For mission-bound authorization, the PDP needs to evaluate whether >> the requested authority aligns with the approved Mission. It cannot >> reliably do that from opaque scope strings / RAR types, unless their >> authority semantics shall be documented in a machine-readable way. >> > > >> > > >> > > >> > > The AS may be able to publish scope and RAR authority as it >> understands them, but the stronger source should be the protected resource >> metadata. Since scopes and RAR types are ultimately interpreted and >> enforced by the RS, it should perhaps publish alongside scopes_supported / >> authorization_details_types_supported, a machine-readable description of >> the authority represented by each scope or RAR type, for example: >> > > >> > > >> > > >> > > { >> > > >> > > "resource": "https://payments.example.com";, >> > > >> > > "authorization_servers": [ >> > > >> > > "https://as.example.com"; >> > > >> > > ], >> > > >> > > "scopes_supported": [ >> > > >> > > "payments.read", >> > > >> > > "payments.prepare", >> > > >> > > "payments.execute" >> > > >> > > ], >> > > >> > > "scope_authority": { >> > > >> > > "payments.read": { >> > > >> > > "description": "Read payment status and history.", >> > > >> > > "authority": [ >> > > >> > > { >> > > >> > > "type": "payment", >> > > >> > > "actions": ["read"], >> > > >> > > "constraints": { >> > > >> > > "account": "subject-owned" >> > > >> > > }, >> > > >> > > "effects": ["read"], >> > > >> > > "risk": "low" >> > > >> > > } >> > > >> > > ], >> > > >> > > "rank": 10 >> > > >> > > }, >> > > >> > > "payments.prepare": { >> > > >> > > "description": "Create a pending payment instruction but do not >> execute it.", >> > > >> > > "authority": [ >> > > >> > > { >> > > >> > > "type": "payment", >> > > >> > > "actions": ["create_pending"], >> > > >> > > "constraints": { >> > > >> > > "source_account": "subject-owned", >> > > >> > > "destination": "mission-bound", >> > > >> > > "amount": "mission-bound" >> > > >> > > }, >> > > >> > > "effects": ["state_change"], >> > > >> > > "risk": "medium" >> > > >> > > } >> > > >> > > ], >> > > >> > > "rank": 20 >> > > >> > > }, >> > > >> > > "payments.execute": { >> > > >> > > "description": "Execute a payment instruction.", >> > > >> > > "authority": [ >> > > >> > > { >> > > >> > > "type": "payment", >> > > >> > > "actions": ["execute"], >> > > >> > > "constraints": { >> > > >> > > "source_account": "subject-owned", >> > > >> > > "destination": "mission-bound", >> > > >> > > "amount": "mission-bound" >> > > >> > > }, >> > > >> > > "effects": [ >> > > >> > > "external_transfer", >> > > >> > > "irreversible_or_hard_to_reverse" >> > > >> > > ], >> > > >> > > "risk": "high" >> > > >> > > } >> > > >> > > ], >> > > >> > > "rank": 30, >> > > >> > > "requires_fresh_approval": true >> > > >> > > } >> > > >> > > }, >> > > >> > > "authorization_details_authority": { >> > > >> > > "payment_initiation": { >> > > >> > > "description": "Initiate or execute a payment.", >> > > >> > > "authority": [ >> > > >> > > { >> > > >> > > "type": "payment", >> > > >> > > "actions": ["initiate"], >> > > >> > > "constraints": { >> > > >> > > "source_account": "subject-owned", >> > > >> > > "destination": "request-bound", >> > > >> > > "amount": "request-bound" >> > > >> > > }, >> > > >> > > "effects": [ >> > > >> > > "external_transfer", >> > > >> > > "irreversible_or_hard_to_reverse" >> > > >> > > ], >> > > >> > > "risk": "high" >> > > >> > > } >> > > >> > > ], >> > > >> > > "rank": 30, >> > > >> > > "requires_fresh_approval": true >> > > >> > > }, >> > > >> > > "payment_status": { >> > > >> > > "description": "Read payment status.", >> > > >> > > "authority": [ >> > > >> > > { >> > > >> > > "type": "payment", >> > > >> > > "actions": ["read_status"], >> > > >> > > "effects": ["read"], >> > > >> > > "risk": "low" >> > > >> > > } >> > > >> > > ], >> > > >> > > "rank": 10 >> > > >> > > } >> > > >> > > } >> > > >> > > } >> > > >> > > >> > > >> > > The exact structure is debatable, the key point is authority would >> benefit from structure beyond text. >> > > >> > > This would enable a mission-aware AS receiving a resource parameter >> to fetch the RFC 9728 metadata, resolve the requested scope or RAR type >> into authority semantics, and evaluate whether that authority is within the >> approved Mission. >> > > >> > > >> > > >> > > I would also add a least-privilege principle: >> > > >> > > If scopes and RAR types are published with authority semantics, the >> metadata should help the AS determine whether a lower-authority scope or >> RAR type can satisfy the Mission. A simple ordering from least to most >> authority may help, though in practice this may need a partial order or >> explicit attenuation relationships rather than one global rank. >> > > >> > > >> > > >> > > In other words, the PDP should not evaluate: >> > > >> > > Does Mission M permit scope S or RAR type T? >> > > >> > > >> > > >> > > It should evaluate: >> > > >> > > Does Mission M permit the authority that RS R declares scope S or RAR >> type T represents, and is there a lower-authority alternative sufficient >> for this Mission? And if so, attenuate. >> > > >> > > >> > > >> > > This is related to Ron’s cross-RS use case, but it is a narrower >> point. >> > > >> > > Ron’s example raises the later question of how to determine whether >> actions across multiple RSs jointly satisfied a Mission. >> > > >> > > The point here is earlier in the flow: before issuance, the AS/PDP >> needs authoritative semantics for the requested scope or RAR type in order >> to evaluate mission alignment at all. >> > > >> > > >> > > >> > > I would therefore separate the two layers: >> > > >> > > Authority semantics metadata: used before issuance to decide whether >> requested authority is within the Mission, and to support least-privilege >> attenuation. >> > > Typed action/outcome evidence: used after execution to determine >> whether performed actions jointly satisfied the Mission. >> > > >> > > >> > > >> > > I’m focusing on the first one: mission-bound issuance needs >> machine-readable authority metadata. >> > > >> > > >> > > >> > > scopes_supported and authorization_details_types_supported advertise >> syntax, not authority semantics. >> > > >> > > >> > > >> > > Yaron >> > > >> > > >> > > >> > > >> > > >> > > >> > > Classification: GENERAL >> > > >> > > From: Karl McGuinness <[email protected]> >> > > Sent: Friday, October 2, 2026 12:24 AM >> > > To: Thi Nguyen-Huu <[email protected]> >> > > Cc: 刘大鹏(鹏成) <[email protected]>; Lombardo, >> Jeff <[email protected]>; Yaron ZEHAVI <[email protected]>; >> Ron Bartor <[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) >> > > >> > > >> > > >> > > This message is from an external sender - be cautious, particularly >> with links and attachments. >> > > >> > > >> > > >> > > 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; that split is the layering cost I mentioned to Alex. Under its >> 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 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. The runtime takes the authenticated client, the >> delegation chain, attested instance context and registry state as actor >> inputs, and each gates independently: a valid credential never overrides a >> revoked agent. Sender-constrained credentials pin possession, and mediated >> 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, 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 and >> present it on a fresh evaluation, 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 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. | Toronto, ON | M9W 4Y8 | Canada >> <https://www.google.com/maps/search/80+Galaxy+Blvd.%C2%A0+%7C%C2%A0+Toronto,+ON%C2%A0+%7C%C2%A0+M9W+4Y8%C2%A0+%7C%C2%A0+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 max.ldp= >> [email protected]. Learn why this is important >> > > >> > > 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’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 <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 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, "刘大鹏(鹏成)" <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). >> > > >> > > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
