Bing, on behalf of the authors, I want to thank you for your patience while we reviewed your feedback.
We appreciate the time you took to review the draft and the questions you raised. Thank you. OAuth represents a rich and complex standards ecosystem that is widely deployed. This specification is an addition to that eco-system and must be read within that broader context (e.g. discovery, configuration, scale, deplyment policy, practical deployment experience etc). After considering the feedback the authors believe that the points raised do not surface new issues that should be addressed in this specification. Below is a summary of our response (we also left comments inline): 1. *"Chaining" is a single hop, repeated.* Multi-hop is achieved by repeating the same single cross-domain exchange successively (A -> B, then B -> C, and so on). Each authorization server is only concerned with the grant presented to it by the immediately preceding domain. A grant may contain information about preceding hops, but that is an implementation or policy choice, outside the scope of this specification. Neither the name of the draft, nor the recursive nature of multi-hop support has been raised as a concern during the specification's development over the last few years. Implementation experience to date proves that this recursive model works in practice. 2. *Frameworks vs Profiless.* This specification is intentionally a framework. Specific claim semantics, trust relationships, and deployment details are left to profiles optimised for specific use cases. The Identity Assertion JWT Authorization Grant (https://datatracke r.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) and the Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining ( https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) are examples of this. We believe more profiles will be developed. Embedding those details in the base specification would over-constrain it. 3. *Cross-domain, not intra-domain.* The mechanism described in this draft is intended for situations where identity and authorization context must cross a trust domain boundary. It is explicitly not aimed at workload-to-workload interactions inside a single trust domain, which drafts like Transaction Tokens ( https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/08/) address. 4. *Loop prevention is not an authorization-layer concern.* Applications calling each other in loops is an application-design problem, not something the authorization layer should arbitrate. The risks of looping is no different in this specification than already exist in OAuth. No new scalability constraints are introduced beyond those already present in OAuth. 5. *Discovery, configuration, and future automation are deliberately out of scope.* Consistent with other OAuth specifications, deployment-specific configuration that does not affect interoperability is left to implementers. Speculation about future automation mechanisms would be inappropriate in a standards-track document. We believe the concerns raised are either already addressed by the existing design, appropriately deferred to profiles, or intentionally out of scope. We are grateful to you for the careful read, but do not believe the draft requires signifiant changes based on the feedback received. With gratitude Pieter Kasselman On Tue, May 12, 2026 at 7:33 PM Bing Liu via Datatracker <[email protected]> wrote: > Document: draft-ietf-oauth-identity-chaining > Title: OAuth Identity and Authorization Chaining Across Domains > Reviewer: Bing Liu > Review result: Not Ready > > Hi Dear authors, I'm assigned to review > draft-ietf-oauth-identity-chaining-11 > by OPSDir. > > 1. General status: Not Ready > > I think the draft is addressing a real issue, esp. for currently hot > discussed > AI Agent interoperability stuff. The solution is simple yet effective. It > integrates with existing RFCs and provides clear JSON structures to > propagate > and preserve the original user’s identity and authorization. And the > security/privacy considerations are also well addressed. > > However, there is one major issue that made me mark it as “Not ready”: > The solution name is “chaining”, which implies multi-hop processing. But > the > specification primarily describes bi-directional interactions between two > domains. The protocol describes how identity and authorization context is transferred from one domain to another. The same protocol transfers context to a third, fourth or fifth trust domain. Whenever identity and authorization context is transferred, the same protocol is used, regardless of how many times it needs to be done. > Although the JWT assertion naturally supporting multi-hops, it not > necessarily supports a multi-hop authentication/authorization framework and > solution automatically. Practical experience suggests otherwise. > I’m not an expert in Oath, but my gut feeling is that > multi-hop collaboration is a much more complex issue than bi-directional > interaction. The "hop" is not bidirectional. It is from Domain A to Domain B. If a client in Domain B needs to access Domain C, it uses the exact same protocol (with the labels of Domain A changed to Domain B, and Domain B changed to Domain C). Multi-hop is just a single hop, done again, and repeated until no more hops are needed. The upper limit of the number of hops is subject to deployment choices and optimisation in implementation, which are out of scope for this draft. > There might be essential gaps between the two, for example: i. > The “chaining” itself might need a model definition. E.g. there might be > different roles in the chain, such as originator/intermediate > relay/intermediate authorizer/destination etc. This draft provides a framework for chaining identity and authorization context between domains. The chaining is achieved by embedding the roles of participants, models, or any other context as claims (hence the explicit mention of claims transcription). The definition of those claims is out of scope for this specification and is left to profiles which may define specific claims for specific use cases. The Identity Assertion JWT Authorization Grant (https://datatracke r.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) and Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining ( https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) are examples of this. We expect more profiles to emerge based on specific deployment models and use cases. > And other considerations like: > is the sequence of the chain essential etc. ii. Multi-hop trust model: > for > example, in the chain of A->B->C, does C only need to confirm assertion of > A or > B, or it needs to confirm A+B? The authorization server in Domain C is only concerned with the authorization grant issued by the authorization server in Domain B to the client in Domain B. The authorization grant issued by the authorization server in Domain B may contain claims that carry information about the request in Domain A. The authorization server in Domain C may choose to accept or reject the authorization grant, subject to its own policies which may be based on those claims, or any other information it takes into account before issuing an access token (basically the same kind of processing an Authorization Server always do before issuing a credential). Which claims are considered is a deployment choice. Specific profiles may be developed for specific types of applications. > iii. Considerations of potential semantic > shifting when doing multiple Claim Transcribing. The specification already states that: "When transcribing claims, it's important that both the place where the claims are given and where they are interpreted agree on the semantics and that the access controls are consistent." > iv. Loop prevention and > scalability considerations of the chain etc. > The risk of looping is no different in this specification than in OAuth in general and is orthogonal to the protocol. Clients calling each other across domains in a loop (looping) is an issue of application design, not how the authorization context is communicated across trust domains. Specifically, it is not the authorization layer's responsibility to ensure that applications do not call each other in loops. In terms of scalability, there are no new constraints that do not already apply to OAuth deployments. > These are not necessarily all valid designing considerations, just > indicate my > main concern that a distributed multi-hop mechanism might not be simply > recursed from a bi-directional one. > This is not a bi-directional flow. Implementation experience suggest that the recursive approach works in real-world deployments. > 2. Minor comments mostly regarding to readability: > > i. The solution highly relies on manual operations in multiple > aspects, > e.g., the trust relationship setup between domains, the discovery of the > remote > authorization server (described as Section 2.2), and the identifier > transcribing across domains etc. This is totally fine from a solution > perspective, but maybe it worthies to briefly summarize the operational > implication in the Abstract/Introduction so that the readers could easily > capture the essence. Details on configuration are deliberately called out of scope as it does not impact the protocol's interoperability and is an implementation detail. This is consistent with OAuth specifications. > ii. For the discovery mechanism defined in Section > 2.2, although it is out of the scope, but since it is an explicit critical > step > in the working flow, I’d suggest to elaborate a little. Say, just > including an > example the static configuration as mentioned in the texts. Discovery is an implementation specific detail and not needed for interoperability of the protocol. Profiles may provide additional details appropriate for more narrowly scoped use cases. Providing more detail than what we provide in Section 2.2 would be inappropriate (repeated below for convenience). This specification does not define authorization server discovery. A client may use the authorization_servers property as defined in OAuth 2.0 Protected Resource Metadata [RFC9728], maintain a static mapping or use other means to identify the authorization server. > iii. Are some of > the manual configurations be potentially automated by protocols in the near > future? E.g., the discovery mechanism. If it is, then maybe briefly > mention it > in the Intro? > It is inappropriate for this specification to speculate about which automation mechanisms will be defined in the future, or which ones will gain market traction.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
