Hi Yaron! (answering to the OAuth group as well as I did not press reply all)
Authorization servers indeed communicate a stable set of requirements through the oauth/oidc metadata. Those requirements are important for discovery and interoperability. The proposed Client Challenge does not change anything in that regard. Interoperability is different to authorization, though. Even if the client supports the necessary client authentication method or grants, it does not mean that the authorization server automatically authorizes the client and issues a token to the client. Ephemeral clients and AI agents disrupt the assumption that the requirements for client authorization are stable. The authorization server may not have a pre-established trust with a client yet. Clients are still applications but with AI agents, they may behave differently, requiring the authorization server to reevaluate its requirements on every request. So, I disagree with requirements being stable. Requirements change per request (e.g. scope). OAuth 2.0 authorization step-up challenge and OAuth Transaction Challenge are good examples for how requirements can change concerning an end-user. AI agents raise comparable requirements because they behave more like users (but are still applications). The proposed standard is a way to increase the trust in such OAuth clients and authorize them. I think, my proposal complements the work that you and others did. This is how it would work: 1. First, the resource server answers with an insufficient authorization demanding the client to seek an access token with higher privileges (scopes, authorization details, claims...). 2. For the authorization server to give the client those higher privileges it is not enough to authenticate the client - it did that already for the low privilege token. Instead, it needs more proof (like an attestation from a trusted party, an intent, permit or mandate from the user). The thing here is that the authorization server, centrally, controls the policy and that the client is responsible for solving the challenge. You may, if you like, think of it as MFA for clients. That's something that only the authorization server can enforce. I also see "step-ups requiring end-user approval" as one of the use cases and there is some similarity to the OAuth Transaction Challenge. However, in the client challenge I proposed, I assume the client is responsible and actively involved in solving the challenge (compared to the authorization server that interacts with the end-user). I assume, the client can present some artifact that resolves the challenge, e.g, that it represents an end-user approval that it has received out-of-band. Let me outline an example. Assume the end-user has a trading AI agent. They connect this AI agent to their bank and other financial institutions. The end-user grants the AI agent to list their portfolio, sell and buy stocks. Now, the end-user instructs the AI agent to monitor the market and to buy new stocks for a given amount via its integrations when some stock price drops under a certain threshold. Obviously, buying stocks is a sensitive operation that requires user approval. The whole point of AI agents, though, is that they are autonomous. The user is not present anymore - they delegated the task to the AI agent and provided it with a cryptographically verifiable mandate (you can find this type of idea in Agent Payment Protocol and Mastercard's Verifiable Intent, for example). With MCP requiring OAuth, it makes sense to me to have the authorization server challenge and validate such artifacts. The reason to put that responsibility on the authorization server is because the resource server should not have to care about whether they deal with a confidential client, mobile app, browser-based app or AI agent (and how that AI agent may be deployed). All the resource server cares about is whether a presented access token conveys the appropriate access rights (e.g., scope, authorization_details, claim, acr_values). If it does not, the resource server asks the client to get those. It's the responsibility of the authorization server to authenticate the client and validate what the client is authorized for. The authorization server reflects that decision in the access token. The latter includes checking the grant and collecting any user approval. The authorization server identifies the client as an AI agent, and thus challenges the AI agent to present the user's mandate. It reflects the user's delegation from the mandate (e.g., the maximum amount to buy for) in the access token. When the resource server gets the access token it can check whether the action that the AI agent aims to perform is covered by the access token. The benefit of using a new token error response type (compared to having a dedicated endpoint) is, that the authorization server can add the challenge to any grant, e.g., during a token exchange, client credentials or authorization code grant or even to PAR. In other words it fits into the existing ecosystem. It does not require any change on the API (resource server) side of things and works with other proposed solutions. It is backwards compatible with existing client integrations while adding support for new use cases. I did not include any specifics in the draft because my goal is to define a framework. I do not want to limit it to a specific use case - just like RAR left the authorization details open by intention, or like token exchange that supports all kind of use cases. I see a benefit of having a standardized way in the form of a framework that allow the authorization server to challenge the client and request from it additional data without relying on a user being present. It allows the authorization server to authorize the client in a policy-based approach where the client needs to fulfill certain obligations for it to receive an access token. I realize my answer got rather long but I hope it clarifies the intention behind the draft. Regards, Judith On Tue, May 19, 2026 at 10:58 PM Yaron ZEHAVI <yaron.zehavi= [email protected]> wrote: > Dear Jeff, > > Thanks for the mention and clear summary. > > > > Dear Judith, > > I’m not sure if the challenge your draft tackles is not handled by RFC > 8414 authorization server metadata: > > - grant_types_supported > - response_types_supported > - token_endpoint_auth_methods_supported > - token_endpoint_auth_signing_alg_values_supported > - code_challenge_methods_supported > > > > And metadata added later by: > > - RFC 9101 (JAR): > - require_signed_request_object > - request_object_signing_alg_values_supported > - request_parameter_supported / request_uri_parameter_supported > - require_request_uri_registration > - … > - RFC 9126 (PAR): > - require_pushed_authorization_requests > - RFC 8705 (mTLS Client Authentication): > - tls_client_certificate_bound_access_tokens > > > > My experience is that authorization servers have a *stable set* of > security requirements from clients, representing their regulatory, legal > and security requirements, which is communicated through oauth / oidc > metadata. > > This set of requirements afaik does not dynamically change per request, > otherwise the entire metadata discovery pattern’s interoperability would be > severely diminished. > > > > Note: My draft and @Yaroslav Rosomakho <[email protected]>’s are > about step-ups requiring end-user approval. > > > > Have I missed something regarding the challenge your draft aims to address? > > > > Regards, > > Yaron ZEHAVI > > > > Classification: GENERAL > > *From:* Lombardo, Jeff <[email protected]> > *Sent:* Tuesday, May 19, 2026 3:32 PM > *To:* Judith Kahrer <[email protected]>; oauth < > [email protected]> > *Cc:* Yaroslav Rosomakho <[email protected]>; Yaron ZEHAVI < > [email protected]> > *Subject:* Re: [OAUTH-WG] New Draft: OAuth Client Challenge Protocol > > > > This message is from an external sender - be cautious, particularly with > links and attachments. > > > > 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 > 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]
