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]> Sent: Monday, June 22, 2026 8:15 PM To: Yaron ZEHAVI <[email protected]> Cc: oauth <[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] To unsubscribe send an email to [email protected]
