Hi Yaron, I had a look at the draft. I think it really closes a gap in the OAuth framework, and I am overall positive .
There are some details and decisions that I do not completely follow. You suggest a authorization_details_types_metadata_endpoint that lists the authorization details types that the authorization server supports. What's the rational behind adding a new endpoint compared to adding the types (schemas) to the authorization server metadata? You also describe two approaches on how to discover which authorization details types a client should add in its request: - The resource server publishes the required types in its resource server metadata. - The resource server adds the required type in an error response. I'm a bit reluctant to the first approach because traditionally, metadata contains data about the supported features not the required. I think that the second approach is better and should be the only one. I understand, that there are limits in your current suggestion in cases where authorization servers do not support the same authorization details type required by the client. Still, I think, the error response from the resource server is a better place to define the requirements than the metadata. Maybe there is a good way to add the expression in the response? Regarding the error response, I noticed that you use the 403 HTTP code in the protocol. Personally, I think 403 + WWW-Authenticate makes sense. 403 + challenge with Bearer scheme communicates to the client: “I understand the token but the token is insufficient for the request. Changing the credentials may change my mind.”, Similarly, 401 Bearer scheme communicates: “The token is not valid for the target resource. Get a new token and try again.” The distinction between “not sufficient” and “not valid” is more or less philosophical imo. However, I have learned at OSW that 401 is the more established and thus preferred pattern for challenges (and the one listed in RFC 9110/STD 97: HTTP Semantics). You probably should change to 401. When it comes to JWTs becoming too big because of the authorization details, Introspection is the way to go as you correctly point out. However, I think that this phrase is misleading: "If the size exceeds this threshold, JWT access tokens SHALL NOT include the authorization_details claim; instead, approved authorization details will be accessed via token introspection." I read it like JWT access tokens should be introspected which is not a common pattern. I suggest you rephrase your guidance. Maybe require the authorization server to return opaque tokens instead? Best regards, Judith --- P:S: Some nits/typos:: Abstract: In second paragraph, line #54, “tp” should be “to”: […] allowing clients [tp -> to] dynamically discover metadata […] Introduction List: Each bullet point should complement the phrase “this document defines”. Remove “adds” from the second bullet point, and add “a” at the beginning the last (A recommended handling of). You could also move the recommended handling of large authorization details objects to a separate paragraph. Simplify: “*The* *optional* *providing* *of* *actionable* *authorization* *details* *objects* *by* *resource* *servers* *enables:*” (line 73) Suggested update: Providing actionable authorization details objects in the error response from the resource server enables: Rational: The subject of the sentence, “the optional providing of actionable authorization details objects by resource servers”, makes the sentence hard to read imo. “providing actionable authorization details objects by resource servers” describes an act done by the resource servers (passive voice). Often, the meaning of a sentence is more clear with an active voice. Also the fact that the provision is optional, is not relevant for its benefits. On Thu, Jun 4, 2026 at 12:18 PM Judith Kahrer <[email protected]> wrote: > Hi Yaron! > > I'll have a look and get back to you with some thoughts. From what you > write in your mail and from what I have heard, it sounds like an > interesting draft indeed! I look forward to studying it in more detail. > > Best regards, > Judith > > > On Wed, Jun 3, 2026, 22:37 Yaron ZEHAVI <yaron.zehavi= > [email protected]> wrote: > >> Dear OAuth Working Group, >> >> I would like to request your review and feedback for this draft: >> >> https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/ >> >> >> >> The document addresses a practical interoperability challenge around Rich >> Authorization Requests (RAR): discovery of metadata for authorization >> details types, allowing clients dynamic discovery rather than relying on >> out-of-band agreements. It also standardizes error signaling in case >> insufficient RAR was provided and offers structured ways of remediation. >> >> >> >> The draft was presented at IETF 125 and OAuth Security Workshop (OSW) >> 2026, where it generated valuable discussion and received positive >> feedback, which has been incorporated into the latest revision of the draft. >> >> >> >> Importantly, the draft is already seeing interest and adoption across >> real-world deployments, including: >> >> - Norway's HelseID healthcare identity platform >> - Raiffeisen Bank Romania >> - The Model Context Protocol (MCP) Fine-Grained Authorization Working >> Group (see SEP-2643 >> <https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2643> >> ) >> >> >> >> These deployments and positive feedback demonstrate the need for a >> standardized mechanism for RAR capability discovery and metadata >> publication. >> >> Given the willingness to adopt the proposal and positive feedback from >> the community, we’d like to ask the Working Group to consider its adoption. >> >> We would greatly appreciate additional review, feedback, and discussion >> from OAuth WG participants. >> >> >> >> Thank you for your consideration. >> >> >> >> Best regards, >> >> Yaron Zehavi >> 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). >> >> Classification: GENERAL >> _______________________________________________ >> 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]
