Dear Jeff, Thank you for your detailed and thoughtful feedback. I find it very helpful considering your engagement with the topic, including our shared efforts on related work such as https://www.ietf.org/archive/id/draft-lombardo-oauth-step-up-authz-challenge-proto-02.html
> scope of draft’s content In view of your and Justin’s comments I am considering<https://github.com/yaron-zehavi/oauth-rich-authorization-requests-metadata/issues/8> splitting to 2 drafts: 1. OAuth 2.0 RAR Metadata Discovery: Defines how clients discover RAR types metadata, including schemas, documentation, and examples, via a dedicated authorization server endpoint. 2. OAuth 2.0 insufficient authorization failure signaling and remediation: Defines runtime failure signaling from the resource server when access tokens lack sufficient authorization details, as well as guidance for client on how to remediate by requesting new tokens which include the missing authorization. I welcome further WG discussion on this proposed split. > Applicability of draft to various OAuth grants and flows The draft is intended to be interoperable with all OAuth specifications and usable in any grant flow supporting RAR. While the high level flow mentions authorization code, it is not limited to the authorization code grant. For example, also FiPA uses authorization code<https://www.ietf.org/archive/id/draft-ietf-oauth-first-party-apps-04.html#name-authorization-code-response>. I will clarify this interoperability aspect in the draft. > Need for coherent solution considering other active drafts I fully agree on the need for harmonization and have been in contact with Yaroslav and co-authors to rationalize and align touchpoints. > Should the draft consider cases when token’s issuer cannot issue the required > RAR types I do not consider this identity chaining, which involves trust domain traversal based on an initial grant. In contrast, my draft uses a new grant to remediate, possibly from a different authorization server. This scenario is worth addressing and presents challenges: * RFC 9728 allows RS to accept tokens from multiple ASs, but there’s no guarantee all ASs necessarily support the same RAR types. * Different resources on the same RS may require different RAR types, making RFC 9728’s authorization_details_supported insufficient, unless multiple resource metadata endpoints are offered (which does not work well for MCP). * This scenario exists in practice, e.g., HelseID (confirmed with Rune Andreas Grimstad). * Yaroslav’s draft addresses this by allowing transaction challenge JWTs to specify a different AS via the aud claim. However, I’m considering a simpler approach: * RS optionally returns actionable RAR objects. * Client checks AS metadata to verify support. * Client consults resource metadata to discover other supported ASs and attempts remediation accordingly. This approach requires no Boolean logic expressions to provide interoperability. > authorization_hint is obscure Your feedback indicates the description needs improvement. It is an opaque string generated by the RS by canonicalizing and hashing the actionable RAR objects it returns. This concept is inspired by GNAP’s use of a reference scope-style string representing complex RAR objects. Usage in the draft: * When clients obtain new tokens following a WWW-Authenticate response containing an authorization_hint, they persist {authorization_hint, token} until token expiration. * Upon receiving a new WWW-Authenticate response with an authorization_hint, clients first look for a matching token to remediate the error without requesting a new token. > Large headers not a concern in the future That’s encouraging news. Nonetheless, omitting RAR from JWT token payloads and providing it via introspection remains valuable for confidentiality and privacy reasons. > Processing rules As the draft evolves with this and other feedback, processing rules will be revised to reflect your insights. Thanks, Yaron That tells me it’s description is not good enough. It is an opaque string value, generated by the resource server by canonicalizing and hashing the actionable RAR objects it returns. The concept borrows from GNAP’s usage of a reference scope-style string to represent a complex RAR object. In the draft it is used like this: * Whenever the client obtains new tokens, if they were requested following a WWW-Authenticate response that included an authorization_hint, client perists { authorization_hint, token } until token’s expiration. * Whenever the client receives a new WWW-Authenticate response that includes an authorization_hint, it first looks into any tokens it already has to locate a token matching the authorization_hint, as that token can remediate the error without requiring the issuance of a new token > Large headers not a concern in the future That’s great news. However, the pattern of JWT tokens omitting RAR from token’s payload and authorization servers providing the RAR to authenticated resource servers has use also for confidentiality reasons. > Processing rules As the draft takes shape with this and other feedback, these will change to reflect your feedback. Classification: GENERAL From: Lombardo, Jeff <[email protected]> Sent: Tuesday, June 30, 2026 11:54 PM To: Yaron ZEHAVI <[email protected]> Cc: Judith Kahrer <[email protected]>; oauth <[email protected]>; Lombardo, Jeff <[email protected]> Subject: RE: [OAUTH-WG] 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, 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]<mailto:[email protected]>> Sent: June 14, 2026 6:07 PM To: oauth <[email protected]<mailto:[email protected]>> Cc: Judith Kahrer <[email protected]<mailto:[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 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]
