IETF Last Call Review of draft-ietf-oauth-identity-chaining-11
review-ietf-oauth-identity-chaining-11-opsdir-lc-liu-2026-05-12-00

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?