Dear Max, Thank you for this helpful feedback. See my response below each point in your text.
Regards, Yaron Classification: GENERAL From: Max Gerber <[email protected]> Sent: Wednesday, June 24, 2026 6:51 PM To: Judith Kahrer <[email protected]> Cc: Yaron ZEHAVI <[email protected]>; oauth <[email protected]> Subject: Re: [OAUTH-WG] Re: Request for review of draft-zehavi-oauth-rar-metadata You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> This message is from an external sender - be cautious, particularly with links and attachments. Yaron, Thank you for the updated document. On `authorization_details_types_required`: > client can decide which authorization server to use next and which RAR types > to request. If the intent is to handle access tokens from different authorization servers, shouldn't the required types be namespaced by the issuer? Otherwise, what guarantee do we have that details type `foo` from authorization server A is equivalent to details type `foo` from authorization server B? Unless these details are defined by an additional profile in the banking or healthcare industry that I am unfamiliar with. (But if the details are defined by a well-known profile, why does the schema need to be discovered dynamically?) Perhaps it is my unfamiliarity with the banking industry, but I would like to see a different example resource server response for `authorization_details_types_required` in §A.2.1. I have trouble imagining an endpoint that requires a `payment_initiation` details grant _or_ a `beneficiary_designation` details grant in order to succeed - those sound like very different usecases and API endpoints to me. I see your point how name-spacing RAR types would prevent confusion and collision, in case several authorization servers support types of the same name, but with different content. I’m not sure implementing guarantees is required, because in the end the resource server decides which authorization servers are supported, which already reduces the risk of name collision. And of course it evaluates if the provided authorization_details satisfy the resource requirements. What are the odds that a resource server would support several authorization servers, offering semantically different RAR types which have the same name? Keep in mind that even if a name collision is possible on a specific resource server, still a correctly named RAR type with inadequate contents would be rejected. I’m not sure if the probability of such collisions merits name-spacing. Note - I changed the example you mentioned for more clarity. On `authorization_hint`: I'm happy to see the inclusion of `authorization_hint` pursuant to our conversations in the MCP FGA WG. Are authorization hints meant to be 1-1 with authorization details objects, or do they uniquely identify the token itself - incusive of (all details + all scopes)? If hints correspond to individual details objects, the RS should return an array of hints, instead of just one. Additionally, since `authorization_hints` are "stable within the context of the same resource server, client, subject, and authorization server," should the authorization server to _also_ return the authorization_hint parameter in the token endpoint response? I think my description of authorization_hint you quoted wasn’t clear enough and therefore I consider changing to: “The value SHOULD be stable when semantically similar `authorization_details` are returned”. The idea is to guide client on token selection in case it already has a satisfying token which it hasn’t used, instead of starting a new oauth grant. Therefore the authorization_hint value should represent the entire authorization_details, also when it contains multiple objects. Note – scopes have established step-up mechanisms (see RFC 6750) so authorization_hint doesn’t apply to scope at all. Perhaps I should add a clarification of this point. On JSON Schemas: I would like to see more concrete client processing rules for JSON schema retrieval and validation. JSON schemas themselves can reference remote schemas via URIs. This means that in the worst case a client can dynamically retrieve some AS metadata, dynamically retrieve the authorization details types metadata, retrieve a schema_uri, and then potentially need to make additional network requests to fully resolve the contents of the schema_uri. This could lead to a very slow initial loading process, or possible DoS infinite loops or SSRF attacks if a malicious authorization server constructs invalid schema URIs. I think schema treatment could be simplified if remote schemas and `schema_uri` were removed and only inline schemas were permitted. Since the metadata has already moved to its own endpoint, size concerns from returning larger schemas inline are less of an issue. If we want to keep `schema_uri` we should add implementation and security considerations around remote loading of schemas + avoiding SSRF. My reading on JSON schemas (not my expertise…) is that “$ref” references including uris such as “https:// ” are identifiers and not HTTP resolvable. Happy to get more feedback if schema_uri should stay or be removed, and if it stays which security considerations apply. My thought in adding it is that authorization servers might want to leverage existing documentation uris stored outside the authorization server. Best, Max On Wed, Jun 24, 2026 at 2:19 AM Judith Kahrer <[email protected]<mailto:[email protected]>> wrote: Dear Yaron, I understand that the authorization_details_types_required is beneficial in such a case. I simply wonder, when does such a case appear? When would a client send an access token from an authorization server that is not compatible with the resource server? When thinking more about it, I found a different argument - simplicity. The authorization_details_types_required is a way for the resource server to simplify its implementation by saying "I don't want to bother with what each authorization server or the current authorization server supports. Figure it out yourself. Here are the requirements." Simplification is a fair point for the feature, I guess. For me it is at least much easier to understand than clients switching authorization servers. The latter would raise a warning for me... With that said, I'm content. Just one more note. The examples indicate that the strings in the authorization_details_types_required map to the schema type. I would point to the authorization details type property in the Authorization Details Types Metadata document (and not the type in the schema). I think, that would make parsing easier. You don't have to bother about a schema validating multiple authorization details types because each authorization details type can only appear once in the JSON document. Best regards, Judith On Mon, Jun 22, 2026 at 11:14 PM Yaron ZEHAVI <[email protected]<mailto:[email protected]>> wrote: Dear Judith, Thanks again for your helpful feedback. About your question, I fully agree the client would normally continue with the same authorization server used so far in remediating the failure. My intention was to consider a case when the authorization server used so far, cannot provide the required RAR types. For example if the resource requires RAR types provided only by accredited / notified authorization servers (e.g through some regulatory framework like PSD2 / eIDAS). But the access token used was not provided by such an authorization server, and the satisfying RAR types might vary across authorization servers. In such case the resource server does not know which authorization servers are available for client and end-user and cannot be expected to provide multiple possible variations of satisfying RAR objects. The client would benefit from discovering through authorization_details_types_required, which RAR types are required. These might not be supported by the authorization server used so far, but then client can decide which authorization server to use next and which RAR types to request. Hopefully this is now clearer, and also makes sense 😊 Regards, Yaron ZEHAVI Classification: GENERAL From: Judith Kahrer <[email protected]<mailto:[email protected]>> Sent: Monday, June 22, 2026 8:15 PM To: Yaron ZEHAVI <[email protected]<mailto:[email protected]>> Cc: oauth <[email protected]<mailto:[email protected]>> Subject: Re: 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! Sorry for not getting back to this thread earlier, I was busy on other ends. I'm happy you considered my feedback and that you found it useful. I honestly think, the proposed protocol is much cleaner with the error response now! Well done :) I like the authorization_details in the body, because it makes integration so much easier if the client can just copy whatever the resource server returns. There's one thing I don't really understand yet. Why would a client change the authorization server and attempt to get a new access token from a different authorization server than the one it got its insufficient access token from? I expect the client to retry with the same authorization server and that would mean that you don't need the authorization_details_types_required in the error response. I guess, I'm missing something. Can you clarify with a use case? Best regards, Judith On Mon, Jun 15, 2026 at 12:07 AM Yaron ZEHAVI <[email protected]<mailto:[email protected]>> wrote: Dear OAuth Working Group, I would like to reach out once more to request additional 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. Draft -04 addresses feedback kindly provided by @Judith Kahrer<mailto:[email protected]> about clearer processing rules and resource server providing required RAR types alongside a WWW-Authenticate error caused by insufficient rar. The draft was presented at IETF 125 and OSW 2026, where it received positive feedback, and 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) This demonstrates the need for a standardized mechanism for RAR capability metadata discovery. We would greatly appreciate additional feedback. 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 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]<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).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
