Hi Yaron! (sorry for starting a parallel, individual conversation. I add the oauth group as well for transparency).
You're right. That's my proposal. Ad 1.) I believe that this will change in the future. Authentication and attestation are two different things imo. Client attestation is the statement of a third party about the client. I have observed that clients that use Client ID Metadata Document are public clients. In such cases, you cannot rely on client authentication. Therefore, the authorization server may require other data (such as a software statement or a mandate) from the client (without being able to authenticate it). Ad 2.) FiPA assumes that the client interacts with the user directly, while I don't make that assumption - thus a different, though similar proposal. I agree that FiPA is great for the client to collect data from the user. However, you cannot use FiPA during a token exchange, for example. The proposal I have in mind is about client authorization. It allows the authorization server that ,whenever the client requests an access token (or any other token for what's worth), to dynamically request additional data. It's similar to obligations in policy-based approaches like AuthZen where the decision is not a simple yes or no but has conditions (context). The thing is, clients are operating over trust domains, hopping from one domain to another, chaining calls. Different domains may have different requirements. The authorization server should be able to communicate such requirements during a flow and do so dynamically. For example, an authorization server may want to request a mandate from the client during an ID-JAG flow for some scopes but not for others. As mentioned before, those mandates are not necessarily client credentials. A mandate/permit/assertion/software statement could come from a user or from an organization that allows AI agents to SSO into SaaS tools, so it's different from client authentication. We are used to having condition-based authentication rules for users. With the proposal I want to enable condition-based access for clients. /Judith On Thu, May 21, 2026 at 11:14 AM Yaron ZEHAVI <yaron.zehavi= [email protected]> wrote: > Dear Judith, > > Thank you for your response. > > > > What I understood, and it could be that I got it wrong, is you’re > proposing a challenge negotiation which either pertains to client > authentication & attestation or to end-user provided permit / mandate? > > > > If that's the case, then: > > 1) I have not yet seen client authentication & attestation requirements > change according to the contents of the request. Usually these are set per > authorization server and match it's use-case requirements (legal, > compliance, risk, etc). > > 2) End-use challenges are usually provided through direct interaction of > end-user with authorization server, or collected by client in the case of > FiPA. > > > > Therefore, what gap remains that your draft aims to solve? > > > > Regards, > > Yaron ZEHAVI > > > > Classification: GENERAL > > *From:* Judith Kahrer <[email protected]> > *Sent:* Wednesday, May 20, 2026 2:38 PM > *To:* 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 Yaron! > > > I agree, authorization servers communicate a stable set of requirements > through the oauth/oidc metadata. It is important for discovery and > interoperability. The proposed Client Challenge does not change anything in > that regard. Interoperability does not mean that the authorization server > automatically issues a token to the client even if the client supports the > necessary client authentication method or grants. > > > Requirements indeed change per request (e.g. scope). OAuth 2.0 > authorization step-up challenge and OAuth Transaction Challenge are good > example for that :) > > I think, this draft complements the work you did. First, the resource > server answers with an insufficient authorization demanding the client to > seek an access token with higher privileges (scopes, authorization details, > claims...). 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 (compared to the resource server that is distributed) and that > the client should be able to solve the challenge without the user being > present (online or outbound). > > There is some similarity to the OAuth Transaction Challenge. I definitely > see "step-ups requiring end-user approval" as one of the use > cases. However, in the client challenge I proposed, I assume the client can > actively solve the challenge (though, you can model polling or user > interaction as well depending on the challenge). 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. > > > I did not include any specifics in the draft as I did not want to limit it > to a specific use case - just like RAR left the authorization details open > by intention. Still, I see a benefit of having a standardized way to for > the authorization server to challenge the client and request from it > additional data without relying on a user being present (and in addition to > any policy the resource server may have). > > > > Does it make more sense now? > > > > 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). > > 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]
