Hi Yaron, Thanks for your proposal . I second the different needs. But I am not sure I second the all the needs into one single proposal.
* RAR metadata capability is something interesting that is needed whatever the RS has a signalling capability you describe or just the natural 401/403 or a 401/403 with RFC 9470 - OAuth 2.0 Step Up Authentication Challenge Protocol<https://datatracker.ietf.org/doc/rfc9470/>. Therefore it should live as such into its own proposal. Most of the time, the client will try to use RAR with the AS without reaching out to the RS in the first place. * Helping the client understand what additional authorization details it must be delegated to come closer to an acceptable resource disclosure is a real problem. This is a work we collaborated on before and this is still unsuccessfully resolved. Still it should live into its own proposal too. With this we leave it up to the implement of the client to decide exactly how to resolve and form the potential 2nd Authorization request whatever it is related to the support by the RS of the extended signalling or not, whatever the client wants to rely on RS guidance partially, fully or not. By separating it, this could also cover the case that RAR can be used for other grant flow than Authorization Code (so far all the example are using Authorization code grant flow). Aaron Parecki proposed on Fri, Dec 5, 2025 at 9:24 AM – Subject: Identity Assertion JWT Authorization Grant – RAR to make RAR (RFC 9396) authorization_details parameter more apparent in RFC 8693 as well as in the Draft for ID-JAG [https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant]. I also agree that this should be work together as a coherent solution with other proposal like Yaroslav’s OAuth Transaction Authorization Challenge draft<https://www.ietf.org/archive/id/draft-rosomakho-oauth-txn-challenge-00.html> as part of the comments that there are an enormous number of proposals and there is a need for collaboration and homogeneity over isolated work. Yes the WG will sort it out as part of the process, but anything worked ahead is a more straightforward path. On other comment you already received: * Considering a case when the AS used so far, cannot provide the required RAR types and the client should switch to another AS: * This plays with multiple trust domain and would fall under identity chaining IMO at the very least. * As other noted, multiple AS raises a lot of other problems like namespacing * Therefore this might require more intricate work. I would recommend solving it for one trust domain as a first approach before trying to boil the ocean right off the bat. * "authorization_hint" is very obscure to me * It should be opaque for the client but at the same time allow the client to “select an existing access token associated with equivalent authorization details”. These requirements are mutually exclusive. * If it is Opaque, that means that the client should not or could not even be able to process it. How would it select something based on it then? * This mechanism would required that the RS has already seen the token before, understood the content of it and not just if it valid in the context of the request or not, AND stored it in a way it could look it up later on. * This sounds highly specific as I know no API endpoint doing that more than maybe storing a hash for authorization caching * This sounds dangerous as it means there is a clear text token storage somewhere * This sounds costly as from an Authorization standpoint it makes some elements mandatory * There is no clear (even non-normative) example on how the client could resolve any action out of this hint * Even 7.1 Client Processing Rules does not help understand how the hint works. * Handling large RAR objects when issuing access tokens * I would not over sweat this, PQC will break things and force for adaptation before we even think of this. Header space will have to grow * I second Justin comment and feedback we got before that we cannot assume anything about the Body and therefore cannot mess with it. I made the same comment to you on OAuth Transaction Authorization Challenge draft<https://www.ietf.org/archive/id/draft-rosomakho-oauth-txn-challenge-00.html> exchange * As none of "authorization_details_types_required" nor "authorization_details" will be a signed JSON structure and as the later issued token containing most of this structure will have to sent back as part of a Bearer, there is few reason to be concerned IMO. * Globally Section 6. is pointing at OAuth2 Rich Authorization Request – RFC 9636<https://www.rfc-editor.org/rfc/rfc9396> Section 9 and should limit at one sentence pointing to it , instead of reexplaining it. * Section 7.1 is overstepping too much in the implementation of the client, this section should limit itself to describe what are the information available to the client if it decides to make a new authorization request. There is nothing: * forcing the client to abide by the RS guidance, * guaranteeing that following this guidance will lead to the issuance of a new set of tokens (the AS might have different views and access control rules), * guaranteeing that even if the client obtain a new set of tokens following the RS guidance, the RS will accept to disclose the resource on the basis of this new set of tokens being presented * Section 7.2 is overstepping too much on the RS implementation and curt corners: * There is no mention that the JWT needs to be validated following RFC 7519, RFC 7515 * Introspection to get authorization_details should be a MAY not a SHOULD * HTTP 403 with WWW-Authenticate: Bearer error="insufficient_authorization_details" should not be returned cause the authorization details are missing or insufficient but in this state the resource cannot be disclosed and the RS has sufficient confidence the client can resolve the missing elements. * This could come from a PDP endpoint hint on what is missing. * I don’t see why authorization_details_types_required is recommended. The RS will decide how to express the needs in the best form possible. * There is not mention processing rules of authorization_hint which does not help understand the purpose of it * I would suggest reading use cases introduced by https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html and https://github.com/openid/authzen/pull/531 by Karl Mc Guiness Jeff Jean-François “Jeff” Lombardo | Amazon Web Services Architecte Principal de Solutions, Stratégie de Sécurité Principal Solution Architect, Security Strategy Montréal, Canada Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. From: Yaron ZEHAVI <[email protected]> Sent: June 14, 2026 6:07 PM To: oauth <[email protected]> Cc: Judith Kahrer <[email protected]> Subject: [EXT] [OAUTH-WG] Request for review of draft-zehavi-oauth-rar-metadata CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. 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
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
