Dear Omri, Thanks for taking the time to provide this thoughtful feedback. I agree with both your points, and they’re now reflected at 9.2 and 10.4. Please have a look and let me know if that is satisfactory.
Yaron Classification: GENERAL From: Omri Gazitt <[email protected]> Sent: Wednesday, October 14, 2026 1:28 AM To: Yaron ZEHAVI <[email protected]> Cc: Blake Morrison <[email protected]>; [email protected] Subject: Re: [OAUTH-WG] Re: 回复：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 Yaron, Thanks for the draft, and for citing the issuance and exchange profiles. I think the layering is right - your metadata describes what a scope means at a resource, which is what a PDP needs when it decides whether to issue it. On the transport question you left open in 1.3: as of PR #677<https://github.com/openid/authzen/pull/677> to the AuthZEN OAuth issuance profile (which landed today), a scope tuple in the issuance profile is the scope value, verbatim, plus the target as a protected_resource in the RFC 9728 sense (see scope tuple<https://openid.github.io/authzen/authzen-oauth-token-issuance-1_0.html#scope-tuple>). That's the same key your authority entries use, so a PDP can resolve your metadata itself, like any other policy data it looks up, and nothing new needs to go in the request. That does affect amb (which you and Blake discussed further down in this thread) though. 9.2 says the authorization server "MUST have applied the identified metadata", but when the AS delegates the decision to a PDP, the PDP is the one that applied it. The profile already lets a PDP return a claim for the AS to put in the token, so amb can flow back that way. Would you consider "the authorization server, or a decision point it consulted" in 9.2? One more note on 10.4: an ID-JAG can't be audience-restricted to the resource that was evaluated - its aud is the resource's authorization server, and the resource travels in a claim. The exchange binding evaluates at both levels for exactly this reason (see two-level evaluation<https://openid.github.io/authzen/authzen-oauth-token-exchange-1_0.html#two-level>), and the redeeming AS restricts the final token. A carve-out for chained grants would cover it. Cheers, Omri -- Omri Gazitt On Sun, Oct 11, 2026 at 3:37 AM Yaron ZEHAVI <[email protected]<mailto:[email protected]>> wrote: Dear Blake, Dapeng, Karl, Ron, Kieran & Omri, I've drafted up the authority metadata proposal: https://datatracker.ietf.org/doc/draft-zehavi-oauth-authority-metadata/ I'm aiming authority metadata to support at any token issuance and exchange decision, also without a mission context. In proposed model an AS has its local policy on authority, which can be tightened (but not relaxed) by protected resource metadata describing the authority (actions, effects, risks) a protected resource assigns scopes and RAR types. I hope this is a helpful shape. Feedback welcome. Yaron Classification: GENERAL -----Original Message----- From: Blake Morrison <[email protected]<mailto:[email protected]>> Sent: Thursday, October 8, 2026 5:13 AM To: [email protected]<mailto:[email protected]> Subject: [OAUTH-WG] Re: 回复：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 Dapeng, Karl, Yaron, Ron, Kieran, Interested. I'd like to add one piece to the problem statement. Both layers in the thread check against the approved Mission. That's Yaron's authority metadata before issuance and Ron's record comparison after it. But the Mission starts as the agent's Intent. The user said "buy product A" before any Intent existed and what they approve is the agent's reading of it. Karl's Mandate commits to that approved intent so it carries the reading rather than the instruction. That piece is evidence of the instruction that started the Mission. 4.3 of Karl's submission evidence draft has the exchange establish the presenter which is the client. The person who gave the instruction isn't a party to it. The evidence also has to survive shaping and 4.2 only lets it name the shaped intent_hash if the type defines a lineage from input_digest. I'm happy to write the requirement up for whichever draft takes it. Blake _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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, 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]
