Hi, A similar idea was proposed at OSW 25 in Iceland see recording at https://youtu.be/9683Ds9GldY
This proposal had the interest of Yaron ( Raiffeisen Bank International )see the personal draft pushed at https://datatracker.ietf.org/doc/draft-lombardo-oauth-step-up-authz-challenge-proto/and presented at IETF 123 Madrid. Later, Yaron worked on https://yaron-zehavi.github.io/oauth-rich-authorization-requests-metadata/draft-zehavi-oauth-rar-metadata.html Also pointing to Yaroslav (ZScaler) work at: https://yaroslavros.github.io/oauth-txn-challenge/draft-rosomakho-oauth-txn-challenge.html Overall the greatest difficulty for the personal draft I lead as part of the feedback received were: * Ability to formalize the cardinality of possible challenge sent back to the client * In this aspect Yaroslav made it easier by focusing only on the Transaction Token related questions * Ability to respect that the Body cannot contain the answer as it would break other protocols like MCP that uses that for transfer of information . This put more challenges on the header which can be constraint in term of information transiting there. 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: Judith Kahrer <[email protected]> Sent: Tuesday, May 19, 2026 9:15 AM To: oauth <[email protected]> Subject: [EXT] [OAUTH-WG] New Draft: OAuth Client Challenge Protocol 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 all, in preparation for OSW, I would like to draw your attention to a proposal that I documented in a new draft: OAuth Client Challenge Protocol https://datatracker.ietf.org/doc/draft-kahrer-oauth-client-challenge-protocol/ While designing OAuth integrations for AI use cases, I identified a requirement were the authorization server needed to request more data from a client before it could form a final decision about a token request. With CIMD, clients may register on the fly (i.e, the authorization server may observe the client ID for the first time during an authorization or token request). A consequence from that is that the authorization server needs to be able to establish trust on the fly as well. And for that it may need more data. In addition, AI agents may have a grant that goes beyond the user's currently intended tasks and where the authorization server wants to double check whether the client has a current mandate from the user for the requested access or whether it acts beyond some intended scope. I pictured something like "MFA for clients". I was investigating use cases where there is no user (resource owner) and where the client is a third-party client acting on behalf of a user. I needed something similar to FiPA that challenged the client to provide data but that went beyond user authentication and focused on reassuring the grant (e.g., an existing token during token exchange or client credentials). So, I came up with an extension to the OAuth token error response that challenges the client to provide more data to complement a grant. I ended up calling it the "OAuth Client Challenge Protocol". It is a simple and extensible protocol that fits into the existing landscape of OAuth standards (proposed or drafts) like CIMD, FiPA, RAR, PAR, probably more. It simply defines a new error code for the token error response that allows the authorization server to define authorization requirements that the client needs to satisfy. How does that sound? What do you think? Best regards, Judith Kahrer
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
