Hi Jeff, I am torn about your draft: https://identitymonk.github.io/draft-lombardo-oauth-client-extension-claims/draft-lombardo-oauth-client-extension-claims.html
Providing that information to the RS allows the RS to validate the decisions the AS made before granting the access token. That is good and bad. Bad because the RS is questioning the AS and can reject a valid access token if it does not agree with new claims. I want that the RS trusts the AS and I want that the client can rely on that a valid access token is accepted. Good because RSses that are somewhat loosely coupled with the AS can keep track of what lead to the access token being created. I assume it was not the intention of the draft that RSes can reject valid access tokens, but I fear that is going to happen. What would be error? Maybe "HTTP 500 Internal Error" if we see the RS and AS as one system which do not agree on something? Maybe the new claims should be part of the token introspection endpoint response? That would allow the RS to get to the information, but we do not have to ship it in every access token. The RS could still reject an access token but maybe they are more reluctant to do an extra request to the token introspection endpoint which increases the latency of the API response. Maybe the RS would do this auditing only from time to time like every 1/10000 request and then send a security event token to the AS... Sorry, I did not provide feedback to the feedback the WG gave. Regarding what subcomponents know, should know and might reject, ... It's complicated. "My" RS send requests to several subcomponents that are sometimes in different jurisdictions and operate on a different legal basis. In general, I want to clarify before we go live what clients are accepted by business, the legal basis for using the API, privacy - GDPR and local laws -, etc and I do not want the RS or its subcomponents to question the AS after we are in production. have fun Axel DMs welcome From: Lombardo, Jeff <[email protected]> Date: Monday, 2. February 2026 at 15:17 To: Nennker, Axel <[email protected]>, reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com <reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com>, [email protected] <[email protected]> Cc: Lombardo, Jeff <[email protected]> Subject: RE: [OAUTH-WG] RAR examples not using "typ" oauth-wg/draft-ietf-oauth-rfc7523bis 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]
