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 <yaron.zehavi= [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]> > *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 <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 > > 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]
