Karl, Agreed that the issuer cannot sign for what a resource server's fields mean. I don't think that rules out a portable artifact, though. It changes what the Mandate commits to.
Yaron's authority metadata gives each resource server a published description of the authority behind each scope or authorization_details type, with the amb digest over it. If the Mandate commits, per Authority Set entry, to the amb digest of the description the approval was evaluated against, the issuer signs which declaration it relied on, not what the declaration means. The resource server stays the author of its own semantics. That is enough to compute Ron's join without the AS. A verifier holding the Mandate, the evidence records and the resource servers' metadata can check each record against the declaration the approval used, and because each record is typed in its resource server's declared fields, the reservation and the charge can be compared on those fields. Per-field commitments in the records (#1019) are still needed. The digest in the Mandate is what ties those fields back to what was approved. Freshness stays with the issuer, as you say: the Mandate records state at minting, and a verifier checks current state with the issuer. That is the same split I make in draft-sweeney-wimse-credential-delegation for receipt chains. The chain proves narrowing offline, and current authority comes from the server. I'll put the same on #1051. Kieran On Tue, Oct 06, 2026 02:16 PM, Karl McGuinness <[email protected]> wrote: > 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 <yaron.zehavi@rbinternational. >>> com>; 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=40alibaba-inc.com@ >>> dmarc.ietf.org. 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]
