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]>
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]<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).
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
