Yaron, Yes, I will review draft-zehavi-oauth-authz-req-del-chain and send comments on-list. Answers to your two specific questions first, since they are the parts I have running.
Resolver logic. Three ordered checks, no branching, and it refuses on any failure rather than degrading: 1. Reconstruction. Each hop contributes a signed link naming its delegate by public key thumbprint, not by client_id. The terminal AS walks the links from the terminal presenter back to the principal grant, verifying each signature under ECDSA P-384 or ML-DSA-65. If any link fails to verify or the chain does not terminate at a grant the AS can anchor, the request is refused. No intermediate client needs prior registration, which is the property your deployment needs and the registration countermeasure destroys. 2. Subset. Every hop expresses authority as bounds, never as parameters. The resolver computes the intersection across all hops and checks the requested parameters against that intersection. A hop cannot widen, only narrow. This is what makes truncation and downgrade detectable rather than merely discouraged: a truncated chain yields a smaller anchor set, not a larger authority, so the check fails closed. 3. Spend. The terminal authority is consumed as an auditable event, not just decremented. An auditor reconciling an incident needs to know which execution spent which evidence, not only that evidence existed. Replay prevention. Freshness lives in the link, not in the transport: - Each link commits to the request it authorizes by including the SHA-384 digest of the canonicalized downstream request parameters. A link is therefore not replayable against a different request, which removes the need to trust any hop's nonce discipline. - Each link carries a resolver-scoped unique identifier, and the terminal resolver keeps a bounded-window seen-set keyed on the tuple of terminal identifier and request digest. Window length is a deployment parameter tied to the acceptable clock skew, not to token lifetime. - Links are HMAC-SHA-256 bound to the terminal audience so a chain assembled for AS-1 cannot be presented to AS-2. In your A to B to C to D topology with subsidiary brokers, this is the check that stops cross-subsidiary replay without requiring the subsidiaries to know about each other. On truncation and downgrade specifically: your countermeasure gets stronger if the resolver requires the chain length and the ordered set of hop thumbprints to be committed in the first link the principal signs. Truncation then contradicts a signed statement rather than merely producing a shorter chain, and downgrade becomes a subset violation instead of a policy judgment. On the new client metadata property. Declaring "this client is a broker" at the upstream AS is useful for policy, but be careful what it is load-bearing for. If the AS acts on the flag alone it is trusting a self-description by the party whose behavior is in question, which is the same defect I raised in the RFC 9068 claims thread. Make the flag an operator-set expectation at the upstream AS rather than a client-asserted metadata value, and let the delegation chain be the thing that proves brokering actually occurred. Then a client that lies about not being a broker still cannot produce a valid terminal chain, and a client that lies about being one gains nothing. I run xml2rfc plus idnits in CI on my own drafts, so send me a pointer to your source repo if you want mechanical review alongside the substantive comments. Our resolver-side implementation and interop notes live in a private Sanctum SecOps peer-implementer collaboration repo; I can grant read access if that would be useful for comparing against your bounds vocabulary. Brian Vicente Founding Principal and Architect Sanctum SecOps LLC On Thursday, August 27, 2026 at 8:22 AM UTC, [email protected] wrote: Dear Brian, Thank you for your comments. Since you habe experience with similar brokering challenges, would you be willing to provide feedback to my aforementioned draft, offering tamper-resistant verifiable OAuth request delegation chain? https://datatracker.ietf.org/doc/draft-zehavi-oauth-authz-req-del-chain/ I’m particularly interested in your resolver logic and replay prevention. Worth noting, following feedback from @Karl McGuinness, I’m working on adding countermeasures against delegation chain truncation and downgrade. To enforce, an upstream authorization server needs to know a client is a broker, so I’m thinking about a new client metadata property: "client_roles": ["oauth_broker"] client_roles. OPTIONAL. JSON array of strings identifying roles the OAuth client is expected to perform when interacting with the authorization server. The value "oauth_broker" indicates that the client may act as an intermediary between the authorization server and one or more downstream clients, applications, agents, relying parties, resource servers, or trust domains. Upstream AS can then gracefully reject requests coming from brokers without the required oauth_request_delegation_chain RAR type: error=invalid_request error_description=authorization_details must contain an object with type "oauth_request_delegation_chain" As a sidenote, I think there’s another reason registering downstream clients at terminal authorization would not work: It assumes downstream clients are aware of upstream authorization servers, but often they’re not. They consume a broker which provides a “brokering profile”, ensuring upstream authorization servers meet certain requirements (participating universities, banks, etc implementing an adequate security profile). The downstream client trusts that profile is fulfilled and doesn’t keep track when upstream authorization servers are added to the brokering network. Regards, Yaron ZEHAVI Classification: GENERAL From: Brian Vicente Sent: Thursday, August 27, 2026 12:45 AM To: [email protected]; Yaron ZEHAVI ; [email protected] Cc: Henrik KROLL ; Grese HYSENI ; [email protected]; [email protected] Subject: [OAUTH-WG] Re: Shared Consent in Brokered OAuth You don't often get email from [email protected]. Learn why this is important This message is from an external sender - be cautious, particularly with links and attachments. Yaron, Kaixuan, Yaron's operator experience is the most useful thing in this thread, and I want to build on it rather than restate it. An A to B to C topology where B is a broker, extending to A to B to C to D where subsidiaries run their own brokers, is the deployment reality, and both proposed countermeasures fail against it for the reasons Kaixuan gives: registering downstream clients at upstream authorization servers defeats the purpose of brokering, and broker-rendered consent screens add friction without giving the upstream AS anything it can act on. The framing I would offer is that the upstream AS does not need the downstream client registered. It needs the delegation chain to be verifiable and the terminal authority to be a subset of what each hop actually held. Concretely, that means three properties rather than a registration requirement: 1. Each hop contributes a signed link naming the party it delegated to, so the chain is reconstructable by the terminal AS without prior knowledge of intermediate clients. 2. Authority at each hop is expressed as bounds, not parameters, so the terminal AS performs a subset check rather than trusting a broker's assertion of scope. We implement this on the resolver side and refuse on violation. 3. Reliance on the chain is emitted as an auditable event. With independent upstream authorization servers, each can honestly rely once, and a counter held by any single broker cannot distinguish that from replay. That is close in spirit to the delegation-chaining idea Kaixuan credits, and it complements token-exchange-style delegation at issuance time rather than competing with it. If it would help, I can write up the tenant-isolation variant we run, where each upstream is a separate trust domain with its own policy, as a concrete counterexample to the "register downstream clients" approach. On Sunday, August 23, 2026 at 9:34 PM UTC, [email protected] wrote: Dear Kaixuan, Thank you for the detailed response, I appreciate the feedback and discussion. My comments on the countermeasures offered come from 6 years of experience running an OAuth broker linking 10+ client applications to 10 upstream (CIAM) authorization servers, each run by a subsidiary (bank) for its customers. So an A --> B --> C relationship where B is our OAuth broker. Some subsidiaries also use their own OAuth broker, for example to broker onward across multiple upstream AS, according to customer segments, making it an A --> B --> C --> D relationship, with B & C acting as brokers. In our setup the terminal upstream authorization server needs to know the terminal downstream client, as an input to its authorization decisions: * Some users may use specific downstream client but cannot use others. * When a user may access multiple downstream clients, their resource permissions may differ. We solved this challenge in our setup using internal contracts whereby the broker is trusted upstream and shares information about its client. Registering every downstream client at every upstream authorization server would, in our case, mean 10x work. There might be larger federation networks where the impact is even more significant. That’s what I meant by defeating the purpose, having to maintain the relationship which today brokering handles. Furthermore, the proposed countermeasure of downstream clients providing OAuth brokers with their client credentials so brokers can act in their name, may introduce new security risks such as broker confused deputy, credential and configuration sprawl etc. My draft’s intention was to keep benefits of simpler architecture due to the separation of roles when using OAuth brokering, while providing upstream authorization servers verifiable attestation of the request’s delegation chain, to enable them to make their decisions. Note: good call on the draft’s resource parameter. It is indeed a reference to the original resource parameter, and not necessarily the OAuth request’s actual resource parameter. That said, I cannot see a valid reason why a broker should inform an upstream authorization server of a different resource value than the one it received, if that value is going to be used as the token’s aud value. Happy to keep the discussion going and review the new draft. Regards, Yaron ZEHAVI Classification: GENERAL From: LUO Kaixuan Sent: Sunday, August 23, 2026 1:11 PM To: Yaron ZEHAVI Cc: oauth ; Henrik KROLL ; Grese HYSENI ; Pedram Hosseyni ; Tim Würtele ; [email protected]; Louis Jannett Subject: Re: [OAUTH-WG] Shared Consent in Brokered OAuth You don't often get email from [email protected]. Learn why this is important This message is from an external sender - be cautious, particularly with links and attachments. Hi Yaron, Thanks for the email and the draft. The idea of delegation chaining during an interactive OAuth flow is very interesting, and it complements the token-exchange-style delegation work done at token-issuance time. I do think that the solution you proposed helps solve the shared consent security issue. Thank you! Regarding your concerns about our countermeasures: But the proposed solutions in the draft fall also short in my view: * Registering downstream clients at upstream authorization servers defeats the purpose of brokered OAuth flows. * Presenting users with consent screens from brokers adds friction and does not empower upstream AS to take informed decisions. I understand these concerns. I think the difference here is that whether the broker and upstream AS should be aware of the delegation chain at all. In the patterns we observed, the existence of the downstream clients is transparent to the upstream AS. The broker can also act as a "textbook" RFC6749-compliant AS and OAuth client toward the downstream client and upstream AS, respectively. Our proposed solutions are a best-effort approach given the constraints of real-world broker implementations. Registering downstream clients at upstream authorization servers defeats the purpose of brokered OAuth flows. On the first point, I'd push back a little. Despite the additional efforts of client registration, this approach still eases the development burden on downstream clients, and IMO does not defeat the purpose of brokered OAuth flow: · Brokers usually have pre-built integrations with many common IdPs/SaaS apps, so the downstream client only needs to talk to the broker to reach those upstream services. · Some brokers act more like "token vaults", helping downstream clients manage the full lifecycle of tokens (fetching, storage, refresh, etc.) and/or API calls toward the upstream AS/RS. Pretty much resembling the Backend-for-Frontend (BFF) or Token-mediating backend (TMB) patterns in OAuth. I think what we can add in the security BCP update draft, is to clarify that the two countermeasures apply when the upstream AS uses the client_id to make consent decisions, and acknowledge that there could be alternative ways to distinguish downstream clients (and the delegation chain), such as leveraging RAR authorization_details. Based on the feedback from Vienna, we will probably also move the brokered consent description in section 2.4 into a different document, which would allow for a more complete enumeration of brokers' threats. My two cents. (Cc Louis Jannett, who contributed to the section) Best, Kaixuan Luo PhD Candidate The Chinese University of Hong Kong ===== P.S. It might make sense to mention that the resource member in the authorization detail object is only a reference for the delegation chain, and does not replace the top-level resource parameter [RFC8707] in signaling the intended token audience: Your draft assumes that the protected resource named in the delegation chain is always the RS associated with the upstream AS (e.g., https://api-domain-1.example.com). https://datatracker.ietf.org/doc/html/draft-zehavi-oauth-authz-req-del-chain-00#appendix-A.1 However, a broker, when acting as an AS, may issue its own access_token with aud= to the downstream client. For example: * Brokered OAuth: the broker uses this token to lookup the original access_token issued to it by the upstream AS, and then forwards that original token to the "real" RS for API calls. * Brokered SSO: the broker uses this token to fulfill requests to its own /userinfo endpoint. So the resource member in the authorization_details object does not indicate the expected audience(s) of the tokens issued in brokered OAuth flows. Is that a correct reading? From: Yaron ZEHAVI > Date: Friday, August 7, 2026 at 21:23 To: Pedram Hosseyni >; Tim Würtele >; [email protected] >; [email protected] > Cc: oauth >; Henrik KROLL >; Grese HYSENI > Subject: [OAUTH-WG] Shared Consent in Brokered OAuth Dears, Thank you for considering the risks these flows present, as part of your "Updates to OAuth 2.0 Security Best Current Practice" draft. I have special interest in this topic since we operate a platform offering brokered redirect-based OAuth. In our case we solved it with internal contracts, providing an app_id inside login_hint, telling the upstream AS who the downstream client is. However, our solution does not offer internet-scale interoperability. But the proposed solutions in the draft fall also short in my view: * Registering downstream clients at upstream authorization servers defeats the purpose of brokered OAuth flows. * Presenting users with consent screens from brokers adds friction and does not empower upstream AS to take informed decisions. I believe an improved pattern could be an OAuth Authorization Request Delegation Chain: A request-time RAR object that conveys clear information about downstream clients and brokers, in a verifiable and tamper-resistant way: https://datatracker.ietf.org/doc/draft-zehavi-oauth-authz-req-del-chain/ The proposed solution doesn't include any new endpoints, AS metadata, grant types, error codes, token formats etc. Only an informative recommended RAR type with prescribed creation and validation processing rules. I'm aware of parallel work on the topic of actor delegation, relevant among others in AI and OBO use-case. As my proposal is aimed at request time, I believe it complements actor delegation work and does not compete with it. I welcome WG feedback on the proposal, especially: * Can it help solve the identified security issue? * Are further alignment and layering required with regards to actor delegation prior art? Regards, Yaron ZEHAVI 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). Classification: GENERAL 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]
