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] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
