Rune, Respectfully, HTTP caching is a well-understood, documented, and standardized process. While I know that IETF RFCs rarely provide implementation guidance (...), in this case it would make sense to document the performance/scaling need for caching and how to do so "securely" beyond what is currently in section 9.1. With proper caching, client implementations will NOT download large metadata because they'll use conditional requests to minimize bandwidth usage, and will use reasonable TTL defaults (<= 30 seconds) to further reduce bandwidth usage and latency. And if you don't need to download large JSON files repeatedly then you don't need separate metadata documents...
> On Jun 6, 2026, at 10:18 AM, Rune Andreas Grimstad <[email protected]> wrote: > > Hi. I can confirm that the separate endpoint was my suggestion. I believe > that the cost of a separate endpoint is low and it offers some real benefits > here. > > In my experience many client implementations will download the metadata very > frequently (often with every token request). If the metadata document is > large this will cause a large increase of bandwidth usage. This will affect > both response times and the costs of operating the system. > > In addition I would expect that many clients do not need this extra metadata, > this also justifies putting them in a separate endpoint. > > > > Rune > > From: Yaron ZEHAVI <[email protected]> > Sent: Friday, June 5, 2026 10:04 PM > To: Judith Kahrer <[email protected]> > Cc: oauth <[email protected]> > Subject: [OAUTH-WG] Re: Request for review of draft-zehavi-oauth-rar-metadata > Dear Judith, > Thanks for taking the time to review and for the positive feedback. > The nits and typos I corrected, thanks for noticing. > As for the discussion points: > • A separate metadata endpoint was proposed by one of the first > reviewers, I think it was Rune Grimstad of HelseID. It made sense as RAR > schemas and additional documentation’s sheer size would far exceed AS > metadata, making AS metadata cumbersome to read. It seemed to justify a > dedicated endpoint. > • The 2nd approach was not intended to provide metadata but rather the > actionable RAR objects, lifting from clients the burden of learning to > construct valid RAR objects. We have this use case in banking as we have many > clients per resource server, and the idea is that resource endpoints (e.g > POST /payments) fail when RAR is insufficient, but they provide an actionable > remediation path (Bob wanted to pay Alice 50$, so here’s the RAR object to > allow it). However, you do raise a good point about the difference between > supported vs required. However when reading RFC 9728 description of > scopes_supported claim, it actually means which scopes are required to access > a resource. But, since the RAR requirements may differ per resource, fully > using the propsosed authorization_details_types_required attribute requires a > resource server to support multiple resource metadata endpoints (per resource > endpoint), which might be a lot to ask (and is discouraged by MCP’s JSON-RPC > style). However, I take a good idea from your feedback: perhaps a resource > server should provide the specifically required RAR types for failing > resource, in the HTTP body. I’ll be happy for additional feedback on this > point. > • The WWW-Authenticate new error code insufficient_authorization_details > was modelled after RFC 6750’s insufficient_scope error code, which is > returned with HTTP 403 error code. Looking into RFC 9110: “403 Forbidden > (§15.5.4): the server understood the request but refuses to fulfill it. If > authentication credentials were provided, the server considered them > insufficient”, which I think matches the scenario well. > • The motivation is to remain with JWT tokens when that’s the token type > of choice, as opaque tokens can make issuer discovery more difficult for > resource servers that accept tokens from multiple authorization servers > because the token value itself typically does not reveal which authorization > server issued it. > Regards, > Yaron > > Classification: GENERAL > From: Judith Kahrer <[email protected]> > Sent: Friday, June 5, 2026 2:12 PM > To: Yaron ZEHAVI <[email protected]> > Cc: oauth <[email protected]> > Subject: Re: [OAUTH-WG] Request for review of draft-zehavi-oauth-rar-metadata > This message is from an external sender - be cautious, particularly with > links and attachments. > 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 > <[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) > 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] > 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] ________________________ Michael Sweet _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
