Hi Yaron, You're welcome :)
ad 1, thanks for the clarification regarding a dedicated Authorization Details Types Metadata Endpoint vs incorporating that data in the authorization server metadata. I doubt machines are concerned about AS metadata being "cumbersome to read". However, I get that the AS metadata can grow in size if it contains the full schema for every supported authorization details type. Any client loads all that data during discovery which may raise performance concerns. I see how a separate endpoint addresses such concerns. The data in the authorization server metadata should be fairly static and therefore caching is a considerable approach as well imo. I understand the implementation concerns and don't have a strong opinion on having a separate endpoint or not. From a conceptional viewpoint, I think, the authorization details types metadata should be part of the authorization server metadata. ad 2. I don't agree regarding the interpretation of RFC 9728 and the *scopes_supported* attribute. Section 7.2 in RFC 9728 clearly states: "It is not meant to indicate that an OAuth client should request all scopes in the list" which contradicts the characteristic of the scopes being required. I don't understand how the proposed *authorization_details_types_required* attribute addresses the fact that multiple resources may have different requirements. How does the client determine which requirement it needs to fulfill for which resource? I think *authorization_details_supported* and the *insufficient_authorization_details* error are sufficient. Ideally, the resource server would respond with an authorization details object that the client can just copy in their authorization (or token) request to the authorization server. There may be a use case where it should return a required type expression instead. Though, I can't think of one right now. Anyways, I prefer if the resource server communicates any requirements in its error response rather than via the protected resource metadata. ad 3. Fair point! ad 4. You're totally right regarding the issuer discovery with opaque tokens! Which means, that, when implementing your draft, the resource server must introspect all JWTs that do not already contain an authorization details claim, correct? Otherwise it won't be able to distinguish between the use case of authorization details are missing and authorization details were omitted because of size restrictions, right? I think, you should add some normative language (MUST?) around that to avoid cases where the resource server returns an error to the client for insufficient authorization details when the client already had requested them but they were not included in the access token. Best regards, Judith On Fri, Jun 5, 2026 at 10:03 PM Yaron ZEHAVI <yaron.zehavi= [email protected]> wrote: > 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: > > 1. 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. > 2. 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. > 3. 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. > 4. 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 <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] > > 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]
