Hi Alex, Glad to see you here!
commenting on the second part, signaling the grant type and extensions used as part of a token issuance, I initially proposed this as a personal Draft to Madrid: https://github.com/identitymonk/draft-lombardo-oauth-client-extension-claims following a presentation Alex Babeanu and I made at OSW: https://youtu.be/9683Ds9GldY We had a debate as: * The header might be available to all the sub-components exercising the access control at a RS while the payload is * Surcharging the jwt typ header value with a lot prefixes might lead to a confused deputy situation depending on the order of the values, at least it would require a draft to specify the order to make sure everyone got it right. The feedback was: * don't use claim that are already used by the market, this is not a Pro, this is a Con to the proposal as it will have replying effects - This should be an easy fix * consider Vector of Trust as way to carry information * I am still torn onto that VoT passes reference values that need to be mapped on both sides not necessarily specification related values that have a clear meaning Happy to follow-up discussions in DM to resume the proposal if any interest. Jeff Jean-François "Jeff" Lombardo | Amazon Web Services Architecte Principal de Solutions, Spécialiste de Sécurité Principal Solution Architect, Security Specialist 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: [email protected] <[email protected]> Sent: February 1, 2026 9:14 AM To: reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com; [email protected] Subject: [EXT] [OAUTH-WG] RAR examples not using "typ" oauth-wg/draft-ietf-oauth-rfc7523bis 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. Hi, draft-ietf-oauth-rfc7523bis recommends strong typing of JWT but currently none of the examples use "typ". I think that https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#section-5 should update all examples in "OAuth 2.0 Pushed Authorization Requests" [RFC9126<https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#RFC9126>] E.g.: eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrhTWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6sef5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-KdTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8WyeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJERWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6GQ Uses { "kid": "k2bdc", "alg": "RS256" } I think there should be the now recommended typ value. Examples are only examples and not normative, but I think examples should follow security recommendations. Another topic, wouldn't it be better to have more types instead of one for client authentication? Something like rar_client_authn+jwt for rar, and ciba_client_authn+jwt for CIBA and ... Doesn't hurt because servers and clients are recommended to adapt current implementations anyway, right? Kind regards Axel From: Michael B. Jones <[email protected]> Date: Saturday, 31. January 2026 at 23:05 To: oauth-wg/draft-ietf-oauth-rfc7523bis <[email protected]> Cc: Nennker, Axel <[email protected]>, Author <[email protected]> Subject: Re: [oauth-wg/draft-ietf-oauth-rfc7523bis] tradeoffs between using issuer and specific endpoint urls (PR #24) @selfissued commented on this pull request. ________________________________ In draft-ietf-oauth-rfc7523bis.xml<https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24#discussion_r2750097587>: > + or its token endpoint URL. Using the specific token > endpoint URL provides + stronger endpoint binding and is RECOMMENDED when the endpoint URL is + configured from a trusted, out-of-band source. Using the issuer identifier + allows greater flexibility at the cost of reduced endpoint-specific binding. As @PedramHD<https://github.com/PedramHD> wrote in his initial description of the attack, "a malicious OP could specify token endpoints of other OPs, thus, obtaining private key JWTs created by an RP that it could use at those OPs." This is the core of what enables the attack: Attackers can specify that the audience be the token endpoint of the legitimate site being attacked. The use of endpoint URLs as audience values do not stop the attack. The use of validated issuer URLs do. - Reply to this email directly, view it on GitHub<https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24#discussion_r2750097587>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANEMB3OWYNI4YEH3RVCZHL4JURJPAVCNFSM6AAAAACRQSIOLGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTOMZTGY3TCNJRGQ>. You are receiving this because you authored the thread.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
