Thanks Jeff for that background info. For me your answer and past efforts just confirm that there is a need for this kind of capability within OAuth. I believe OAuth integrations would benefit from a standardized approach.
I'm sorry to hear that your ideas didn't get adopted and that you faced such challenges. I will have a look at your material and study your approach to get a better understanding of the context. I can already tell you that I don't have any ambition to provide all the answers or complete solution. Instead, I want to focus on the framework, similar to how RAR works. I hope that keeping it as simple as possible and supporting existing standards or adopted work appeals to people so that the group eventually adopts the idea. Again, thanks for sharing your work! Best regards, Judith On Tue, May 19, 2026, 15:33 Lombardo, Jeff <jeffsec= [email protected]> wrote: > 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]
