Dear Yaroslav and co-authors, Thank you for sharing this draft. I found it interesting and useful.
As background, my rar-metadata<https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/> draft explores a related pattern: a protected resource returns an authorization failure using the WWW-Authenticate header to indicate insufficient authorization, together with actionable remediation information, including authorization details objects. I therefore appreciate seeing a similar pattern explored here, and I think this is a useful area for the WG to discuss. Detailed feedback and questions: * Transaction and single-use semantics. The specific “transaction” concept is familiar to me from banking use cases. However, up until now OAuth has not generally defined single-use token semantics. That is, an authorization server typically has no idea how many times a resource server will accept a given access token for a given resource request. This has historically been enforced by the resource server. What requirement motivates making the authorization server aware of resource-server token-handling semantics? If the AS is expected to know this, would it make sense for the token response to include a token-usage attribute, analogous to but distinct from expires_in? * Role of the agent. The agent appears to be a normative part of the draft. To me, that seems to limit the scope of the solution, while the agent does not appear to perform specific protocol steps beyond declaring capability. In several places, the agent seems more like a channel that requires adversarial considerations, such as tampering, rather than a required protocol actor. Should the draft instead treat the agent as a security consideration? * Capability discovery. OAuth has metadata mechanisms for discovering client, authorization server, and resource server capabilities. Perhaps the capability declaration currently associated with the agent could instead reuse or extend those mechanisms. In addition to the agent, the client needs to be able to process the challenge, be a client of any authorization server identified by the challenge JWT, and that authorization server also needs to support the mechanism. It may be useful to describe how these capabilities are discovered and negotiated. * Initial failure as the only path. The draft seems optimized for the case where the client first calls the protected resource, receives a challenge, and then obtains a compliant token. If the client already knows the resource’s authorization requirements, can it request a compliant token up front and avoid the initial failure? If so, it may be useful to describe that path explicitly. * HTTP 401 vs 403. The draft uses HTTP 401. Could you explain the reasoning? For insufficient authorization where credentials were already provided, HTTP 403 seems more directly aligned with RFC 9110: “the server understood the request but refuses to fulfill it. If authentication credentials were provided, the server considered them insufficient.” This is also the approach I took in my draft. * JWT representation of transaction challenges. Could you elaborate on why transaction challenges are represented as JWTs? * If the goal is authenticity or integrity of the challenge contents, it would help to state that explicitly. * RAR, RFC 9396, does not require signed authorization details; the AS evaluates the authorization_details input as part of the authorization request. If the concern is that the agent or another intermediary may tamper with the challenge, perhaps the JWT could be consumed by the client. The client could validate the JWT, extract the usable parts, and use them in a normal OAuth request. That would avoid requiring the AS to understand challenge JWTs or maintain a trust relationship with resource servers. * The JWT does not appear to be included in the later access token request or in the client’s subsequent request to the protected resource. Therefore, checks such as verifying consistency with the authorization_details claim in the transaction authorization challenge seem to require resource-server state. Is that intended? * Header size. Returning the challenge JWT in the WWW-Authenticate header may create interoperability issues due to header size limits, even before considering larger post-quantum signatures. * Authorization server selection. The challenge can appear to identify an authorization server different from the one used to obtain the token in the failing request. This may be problematic if the client cannot use the indicated AS, is not registered with that AS, or the AS does not support this mechanism. It may be useful to describe the expected client behavior in that case. * New endpoint / grant pattern. Could you explain the reason for introducing a new transaction authorization endpoint? Is this also intended to define a new grant type? Since FiPA already supports challenge negotiation and allows the AS to request direct interaction with the end user through redirect_to_web, perhaps a FiPA extension with your use case plus the Deferred Token Response draft<https://datatracker.ietf.org/doc/draft-gerber-oauth-deferred-token-response/> could address your use case without necessitating a new endpoint. * Transaction authorization endpoint details. Which parameters does the transaction authorization endpoint accept, and which OAuth mechanisms are intended to apply to it, such as client authentication, PAR, DPoP/mTLS sender-constraining, etc.? * User redirection and polling. When authorization_uri is returned and the end user is redirected there, how does the client obtain the result? Is the client expected to poll in parallel? * Token issuance pattern. FiPA returns a code and leaves token issuance to the token endpoint, whereas this draft’s transaction authorization endpoint appears to return tokens directly. Would it make sense to align the patterns? * Access token relay. The draft says: “In deployments where one agent delegates work to another agent, the access token MAY be relayed through one or more intermediate agents before being presented to the protected resource.” Relaying an access token through multiple agents seems difficult to combine with DPoP, since the proof binds token use to one key. Regards, Yaron ZEHAVI Classification: GENERAL From: Yaroslav Rosomakho <[email protected]> Sent: Thursday, June 25, 2026 1:50 PM To: [email protected] Cc: [email protected] Subject: [OAUTH-WG] OAuth Transaction Authorization Challenge You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> This message is from an external sender - be cautious, particularly with links and attachments. And this time without a typo in the email alias for draft authors... -yaroslav On Thu, Jun 25, 2026 at 12:19 PM Yaroslav Rosomakho <[email protected]<mailto:[email protected]>> wrote: Dear OAuth enthusiasts, Pieter, Brian, Karl and I have submitted a new individual draft: OAuth Transaction Authorization Challenge (draft-rosomakho-oauth-txn-challenge). This specification defines a mechanism for a protected resource to request transaction-specific authorization before completing a particular operation. The protected resource returns a signed transaction authorization challenge, which is relayed through the agent(s) down to the client. The client presents the challenge to the authorization server, which validates it, obtains any required approval from a human user and/or any additional relevant approving party, and issues an access token whose granted authorization details describe the approved operation. The motivating use cases include agent-initiated actions requiring human approval (aka "human-in-the-loop") and flexible integration with organizational approval workflows. The mechanism is intended to complement OAuth step-up authentication and CIBA by requesting authorization for a specific transaction rather than stronger or fresher authentication alone. Questions, suggestions, concerns and overall feedback is very welcome! Thank you. -yaroslav ---------- Forwarded message --------- A new version of Internet-Draft draft-rosomakho-oauth-txn-challenge-00.txt has been successfully submitted by Yaroslav Rosomakho and posted to the IETF repository. Name: draft-rosomakho-oauth-txn-challenge Revision: 00 Title: OAuth Transaction Authorization Challenge Date: 2026-06-25 Group: Individual Submission Pages: 33 URL: https://www.ietf.org/archive/id/draft-rosomakho-oauth-txn-challenge-00.txt Status: https://datatracker.ietf.org/doc/draft-rosomakho-oauth-txn-challenge/ HTML: https://www.ietf.org/archive/id/draft-rosomakho-oauth-txn-challenge-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-rosomakho-oauth-txn-challenge Abstract: This document defines an OAuth mechanism for transaction-specific authorization challenges. A protected resource can require additional authorization for a particular operation by returning a transaction authorization challenge. This is useful when requests are mediated by agents, automated workflows, or delegated services and the protected resource requires confirmation from a human user, resource owner, or organizational authority. The client presents the challenge to an authorization server, which validates the challenge, obtains any required approval, and issues an OAuth 2.0 access token whose granted authorization details, expressed using Rich Authorization Requests, describe the approved operation. The access token is then presented to the protected resource as evidence that the challenged operation was authorized. The IETF Secretariat This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system. 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]
