Thanks Judith, This definitely makes it clearer for me, and you might have identified a real gap: There’s no normative language for an AS to specify different requirements based on request contents (e.g scope read-only = X, but scope payments means rar + dpop + confidential client with mTLS or private_key_jwt etc).
However, it might be possible to solve this challenge and the other points you’ve raised, using existing RFCs and drafts. I’ll try to identify solutions for each point you’ve raised. And please use the OSW to figure this out further. Unfortunately I won’t be there next week due to a wedding, but I wish you luck! * CIMD is not limited to public clients. Confidential clients can use it to publish token_endpoint_auth_method, jwks, jwks_uri all supporting confidential clients as well. * Client authentication requirements regarding attestation (should be) solved by https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-08.html. I think it may be lacking metadata for specifying requirements regarding attestation’s type and issuer, to support attestations issued by 3rd parties. I’ve copied the draft authors in cc. * Step-up of user authentication is solved by rfc 9470 * Step-up of token scope is solved by rfc6750, or mitigated without step-up by consulting rfc 9728 resource metadata document, to request adequate token * Step-up requiring rfc 9396 rar is solved by my rar-metadata draft, or mitigated without step-up by consulting (rar-metadata draft proposed addition to) rfc 9728 resource metadata document, to request adequate token. So your use case of the trading AI agent could be solved by a step up, requesting missing scope or rar, which once granted would be represented by an access token satisfying the trading resource. However, if that elevated permission OAuth request has different requirements of client authentication, 3rd party attestation, dpop, par, jar etc – how can an AS specify that? I can think of a solution based on current RFCs of “authorization server partitioning”: * Resource server publishes multiple resource metadata documents, per resources (e.g /account-read-access and /trading). * Each metadata document names `authorization_servers`, which might be on the same domain but have path suffixes such as: https://as.example.com/low-risk https://as.example.com/medium-risk https://as.example.com/high-risk * Each “authorization server partition” publishes it’s RFC 8414 authorization server metadata with its specific requirements Is this too cumbersome? Does it merit a new draft? Let’s see at the OSW 😊 Regards, Yaron ZEHAVI Classification: GENERAL From: Judith Kahrer <[email protected]> Sent: Thursday, May 21, 2026 12:31 PM To: Yaron ZEHAVI <[email protected]> Cc: oauth <[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 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 <[email protected]<mailto:[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<mailto:[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]<mailto:[email protected]>> Sent: Tuesday, May 19, 2026 3:32 PM To: Judith Kahrer <[email protected]<mailto:[email protected]>>; oauth <[email protected]<mailto:[email protected]>> Cc: Yaroslav Rosomakho <[email protected]<mailto:[email protected]>>; Yaron ZEHAVI <[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Tuesday, May 19, 2026 9:15 AM To: oauth <[email protected]<mailto:[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). 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]
