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. *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? *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. Best, Max On Wed, Jun 24, 2026 at 2:19 AM Judith Kahrer <judith.kahrer= [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 <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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
