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. Although the JWT assertion naturally supporting multi-hops, it not necessarily supports a multi-hop authentication/authorization framework and solution automatically. 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. 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. 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? iii. Considerations of potential semantic shifting when doing multiple Claim Transcribing. iv. Loop prevention and scalability considerations of the chain etc. 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. 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. 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. 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? _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
