Thanks Judith, That’s very valuable feedback, I appreciate it! ad1, I accepted Rune’s recommendation to opt for a separate endpoint as perhaps not all clients and use-cases use RAR and therefore although it logically is part of AS metadata, could overload the main AS metadata document, introducing performance concerns for clients. Also, some humans read AS metadata, to understand requirements or debug failures and I making it cumbersome for them was also a consideration. However I understand and accept opinions to the contrary and leave the matter of dedicated endpoint for RAR types metadata or not, for the WG.
ad2, See https://www.rfc-editor.org/rfc/rfc9728.html#name-protected-resource-metadata-. A resource server MAY publish several resource metadata documents, specific per resource, e.g: /.well-known/oauth-protected-resource/resource1. But I accept your point, that normative error remediation better be provided in the WWW-Authenticate error response and not in the resource metadata. This approach is also better aligned with MCP server use-cases, which don’t use separate endpoints for different resources, instead specifying required tools in json-rpc request body. As for specifying metadata of required RAR objects vs providing clients with actionable RAR objects, those are two separate approaches that this draft supports. ad4, Very good point! I’ll add resource server processing rules to reflect handling of large rar objects according to the draft. Thanks once more for taking the time to provide this feedback. Regards, Yaron Classification: GENERAL From: Judith Kahrer <[email protected]> Sent: Monday, June 8, 2026 2:13 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, 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 <[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Friday, June 5, 2026 2:12 PM To: Yaron ZEHAVI <[email protected]<mailto:[email protected]>> Cc: oauth <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<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, 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]
