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 <yaron.zehavi= [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 > <[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 >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
