Thanks Yaron - the latest commits to https://github.com/yaron-zehavi/oauth-authority-metadata do satisfy both points.
Many thanks! Omri. -- Omri Gazitt On Wed, Oct 14, 2026 at 1:29 PM Yaron ZEHAVI < [email protected]> wrote: > 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]> 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]> > Sent: Thursday, October 8, 2026 5:13 AM > To: [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] > 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). >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
