Many thanks to Russ Housely for the ARTART review.

I have no objections to this document. Thanks to the authors and the working group for producing this document, and thanks for including a privacy considerations section.

Thanks to Russ H. for the review.  Thanks to Rifat for the shepherd write up, nice to see the implementations.

Thanks to the authors for a very concise document.

Thanks for the work done in this document. I regret that the shepherd's write-up does not have real justifications for the intended publication status or for the number of authors.

In section 2.5, should this rather be a "MUST" in `Authorization Servers SHOULD verify that the requested scopes are not higher privileged than the scopes of the presented subject_token` ? If "SHOULD" is kept, then please provide the additional guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

The same issue in section 5.4, i.e., why not a "MUST NOT" in `The authorization server in trust domain B SHOULD NOT issue refresh tokens ` ?

The same IESG statement also considers that BCP14 terms should not be used in appendix.

Final regret for not using SVG graphics, but this is cosmetic.

Thank you for the work that has been put into this document. I do not see any transport-protocol related concerns.

However, I would have found it helpful to have read a more informative abstract.

I would  expect this to explain that request information needs to be preserved when a request crosses one or more trust domains, known as "chaining", and to mention the combination of OAuth 2.0 Token Exchange and the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants. Please consider adding one or two more lines of text.

Gorry

Thanks to the authors and the WG for their work on this document.

I would like to point out that there is some text in the IANA Considerations that does not belong there (i.e., it does not have any instructions for IANA) per RFC8126.

"The parameter indicates the supported token types that can be requested in an [RFC8693] Token Exchange."
This seems like a repeat of the Metadata Description and can be deleted?

And then the section 4.2 below is more for information of readers and not something for IANA team to act on. This is better moved somewhere else in the document, I don't have a good suggestion as to where that might be.

4.2. Media Types
This specification does not define any new media types.

Profiles or deployment-specific implementations can adopt explicit typing as defined in JSON Web Token Best Current Practices [RFC8725] and define a new media type [RFC2046] in the "Media Types" registry [IANA.media-types] in the manner described in [RFC6838].

Hi Arndt, Pieter, Kelley, Michael, Brian, and Aaron, 

Thank you for the effort put into this document. 

Thanks to Bing Liu for the OPSDIR review and the authors for engaging.

Please find below some few minor comments: 

# It is not clear at this stage how a client knows that server in that other domain:

CURRENT:
   The client in trust domain A then presents
   the received grant as an assertion to the authorization server in
   trust domain B, using the JWT authorization grant feature of ..

An easy fix is s/trust domain B/trust domain B (Section 2.2)

# Mysterious use cases

CURRENT:
   The identity and authorization chaining flow outlined below describes
   how a combination of OAuth 2.0 Token Exchange [RFC8693] and JWT
   Profile for OAuth 2.0 Client Authentication and Authorization Grants
   [RFC7523] are used to address the use cases identified.

Which use cases are we referring to here? Those in the appendix? Else? Please clarify in the text.

# Figure 1

How a client knows its trust domain and what triggers discovery of a server in another domain?

# Discovery

CURRENT:
   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.
 
The second sentence lists discovery examples which may be interpreted as contradicting with “not define”.

I think “s/does not define/does not mandate any” or similar would be better.

# I suggest to add a mention in the main body to introduce the appendixes.

# A PR with some nits and minor edits [1]. Feel free to grab whatever useful for you.

Cheers,
Med

[1] https://github.com/oauth-wg/oauth-identity-chaining/pull/193

Thank you to Lars Eggert for the GENART review.

To the responsible AD
-- does the >5 author count make sense for this document?
-- as this document scope is covered in the new 05-05 charter up for approval, could it be ensured that they see approval concurrently?