Thanks Jeff, I appreciate your detailed feedback. > RS processing The RS inherently understands how its valid RAR types are structured, as it enforces these when protecting resources. To generate the authorization_reference, the RS canonicalizes the authorization_details it intends to return—this addresses claim ordering concerns—and then hashes the result. This ensures stability: semantically equivalent RAR objects from the same RS will always produce the same reference.
> Client processing The client’s task is straightforward: upon receiving an authorization_reference, it checks if it holds a token matching that reference (i.e., a token obtained after a previous RS challenge with the same reference). If found, it retries with that token; otherwise, it requests a new grant. > Collisions Hash collisions are unlikely given token lifetimes. I can add language that matching authorization_reference values be scoped to the same RS. > PAR and JAR interoperability Do you think explicitly addressing PAR or JAR is necessary here? The client’s remediation step occurs before and outside the scope of any OAuth grant. Once the client proceeds to request a new grant, it may use any extension or RFC, including PAR or JAR. The draft already states compatibility with any RFC or grant that uses RAR. Regards, Yaron > RS processing The RS knows how its expected valid RAR types are structured, as it uses this knowledge to enforce whenever a RAR protected resource is called. To generate the authorization_reference, the RS canonicalizes and hashes the authorization_details it is about to return. As the RS creates actionable RAR objects, then canonicalizes (which solves claim ordering concerns) and hashes. This provides for stability so the reference of the same semantically equivalent RAR objects from a specific RS will always have the same reference. > Client processing Client's job is then quite simple: When it gets an authorization_reference, checks if it has a token matching that reference? (a token created after an RS challenge returned same reference) If so, use it. If not, request a new grant. > Collisions I don't think hash collisions will be a concern, as token lifetimes are anyway limited, what are the odds? I suppose I can add language saying if you got matching authorization_reference from the same RS, therefore scoping it to a specific RS. > PAR and JAR interoperability Do you think that's necessary? If so, where? The client challenged by the RS for remediation happens before and outside the scope of any OAuth grant. Once challenge is obtained and client opts for new OAuth grant they may use any extension and RFC. I already put language to that effect, that this draft is compatible with any rfc and grant that uses RAR. Regards, Yaron Classification: GENERAL -----Original Message----- From: Lombardo, Jeff <[email protected]> Sent: Monday, July 6, 2026 11:50 PM To: Yaron ZEHAVI <[email protected]>; oauth <[email protected]> Cc: Lombardo, Jeff <[email protected]> Subject: RE: [OAUTH-WG] FW: New Version Notification for draft-zehavi-oauth-rar-metadata-05.txt This message is from an external sender - be cautious, particularly with links and attachments. Thanks Yaron this new version seems to address most of my personal points. >From how I understand the authorization_reference works, please correct me if >I am wrong,: - The RS will generate a JSON structure of expected authorization_details surely based on the authorization_details types the AS is supporting, knowledge it can acquire through the new metadata endpoint - The RS hashes this structure where the order of claims will be important - The RS transmit this hash value as authorization_reference - The RS expects the Client to have multiple active tokens, for which the client will take the authorization details part if it exists and iterate until either it finds a match with the authorization_reference or it exhausts the list of tokens it owns. Multiple question here: - Writing this exposes that this is a lot of work from the client, no? - What happens if the authorization_details in the token are sorted differently? the hash will never match. A JWT's payload (and header) is a JSON object, and RFC 8259 (The JSON Data Interchange Format) explicitly states: "An object is an unordered collection of zero or more name/value pairs." - What happens if an authorization_details from another issuer match the hash value of the authorization_reference? Therefore, I am not sure about the value of the authorization_reference holds while it adds hidden complexity. Finally in Protocol Overview step (D) you might want to open the door for the client to do PAR or JAR too. My 2 Canadian cents 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. Thoughts on our interaction? Provide feedback here. -----Original Message----- From: Yaron ZEHAVI <[email protected]> Sent: July 4, 2026 3:34 PM To: oauth <[email protected]> Subject: [EXT] [OAUTH-WG] FW: New Version Notification for draft-zehavi-oauth-rar-metadata-05.txt 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. Dears, I've revised the draft following the latest and very helpful feedback from Justin Richer and Jeff Lombardo. Key changes: - Moved resource server's response from body to WWW-Authenticate header. - Changed from HTTP 403 to 401. - Removed required authorization details types. - Renamed authorization_hint to authorization_reference and clarified its usage. - Clarified authorization server broader considerations on omitting RAR from JWT access tokens. - Clarified document's interoperability with any OAuth rfc and any grant that supports RAR. Additional feedback is welcome. Regards, Yaron Classification: GENERAL -----Original Message----- From: [email protected] <[email protected]> Sent: Saturday, July 4, 2026 9:11 PM To: Yaron ZEHAVI <[email protected]> Subject: New Version Notification for draft-zehavi-oauth-rar-metadata-05.txt This message is from an external sender - be cautious, particularly with links and attachments. A new version of Internet-Draft draft-zehavi-oauth-rar-metadata-05.txt has been successfully submitted by Yaron Zehavi and posted to the IETF repository. Name: draft-zehavi-oauth-rar-metadata Revision: 05 Title: OAuth 2.0 RAR Metadata and Error Remediation Date: 2026-07-04 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/archive/id/draft-zehavi-oauth-rar-metadata-05.txt Status: https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/ HTML: https://www.ietf.org/archive/id/draft-zehavi-oauth-rar-metadata-05.html HTMLized: https://datatracker.ietf.org/doc/html/draft-zehavi-oauth-rar-metadata Diff: https://author-tools.ietf.org/iddiff?url2=draft-zehavi-oauth-rar-metadata-05 Abstract: OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] standardizes the exchange and processing of authorization details but does not define metadata for describing authorization details types. In addition, no interoperable guidance is offered to clients, to remediate failures by resource servers due to insufficient authorization details. This document addresses this interoperability challenge, allowing clients to dynamically discover metadata instead of relying on out- of-band agreements, as well as standardizes failure signaling including interoperable remediation when insufficient authorization details are the cause of failure. The IETF Secretariat 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] 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]
