jiebi/TextFlow huggingface dataset:
Original text:
The authorization server MAY add, remove or change claims.  See transcribing-claims. <del> 2.3.3. </del>  The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
The authorization server MAY add, remove or change claims.  See transcribing-claims.  <ins> 2.4.3. </ins> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and
Original text:
"urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. <del> 2.3.4. </del>  Authorization servers MAY choose to:

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
"urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats.  <ins> 2.4.4. </ins> Authorization servers MAY choose to:
Original text:
verify that requested scopes are not higher priveleged than the scopes of presented subject_token. <del> 2.3.5. </del>  All of section 2.2 of RFC8693 applies.  In addition, the following applies to specification that conform to this specification.

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
verify that requested scopes are not higher priveleged than the scopes of presented subject_token.  <ins> 2.4.5. </ins> All of section 2.2 of RFC8693 applies.  In addition, the following applies to specification that conform to this specification.
Original text:
only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C. <del> 2.3.6. </del>  The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). <del> 2.4. </del>  The client uses the received authorization grant from steps B and C as an asseration towards authorization server of domain B. <del> 2.4.1. </del>  If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C.  <ins> 2.4.6. </ins> The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth).  <ins> 2.5. </ins> The client uses the received authorization grant from steps B and C as an asseration towards authorization server of domain B.  <ins> 2.5.1. </ins> If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0
Original text:
The client MAY indicate the audience it is trying to access through the "scope" parameter or the "resource" parameter defined in RFC8707. <del> 2.4.2. </del>  All of RFC7521 (Section 5.2 in specific) applies.  In context of this specification the following rules apply in addition:

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
The client MAY indicate the audience it is trying to access through the "scope" parameter or the "resource" parameter defined in RFC8707.  <ins> 2.5.2. </ins> All of RFC7521 (Section 5.2 in specific) applies.  In context of this specification the following rules apply in addition:
Original text:
Due to policy the request MAY be denied (for instance if the federation from domain A is not allowed) <del> 2.4.3. </del>  The authorization server MAY leverage claims from the present authorization grant for claim population of the access token.  The

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
Due to policy the request MAY be denied (for instance if the federation from domain A is not allowed)  <ins> 2.5.3. </ins> The authorization server MAY leverage claims from the present authorization grant for claim population of the access token.  The
Original text:
The specifics (such as the format) of returned access token is not part of this specification. <del> 2.4.4. </del>  The authorization server responds with an access token as described in section 5.1 of RFC6749. <del> 2.4.5. </del>  The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B

Reviewer comments:
Added use cases. We may want to refine these, or move them into a non-normative section later.

Revised text:
The specifics (such as the format) of returned access token is not part of this specification.  <ins> 2.5.4. </ins> The authorization server responds with an access token as described in section 5.1 of RFC6749.  <ins> 2.5.5. </ins> The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B
Original text:
2.3.2. <del> Either one of resource or audience is required to indicate for what authorization server the authorization grant should be audienced. The authorization server MUST deny the request if neither is set.  An authorization server SHOULD deny the request on an unknown resource/ audience.  In cases where federation to any authorization server is deliberate unknown resource or scope identifiers MAY be allowed. 2.3.3. </del>  The authorization server MAY deny the request due to policy.  For instance if federation to the requested domain/authorization

Reviewer comments:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Revised text:
2.3.2.  <ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any authorization server is deliberate unknown resource or audience identifiers MAY be allowed. </ins> The authorization server MAY deny the request due to policy.  For instance if federation to the requested domain/authorization
Original text:
The authorization server MAY add, remove or change claims.  See transcribing-claims. <del> 2.3.4. </del>  The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and

Reviewer comments:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Revised text:
The authorization server MAY add, remove or change claims.  See transcribing-claims.  <ins> 2.3.3. </ins> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and
Original text:
"urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. <del> 2.3.5. </del>  Authorization servers MAY choose to:

Reviewer comments:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Revised text:
"urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats.  <ins> 2.3.4. </ins> Authorization servers MAY choose to:
Original text:
verify that requested scopes are not higher priveleged than the scopes of presented subject_token. <del> 2.3.6. </del>  All of section 2.2 of RFC8693 applies.  In context of this specification the following applies in addtion:

Reviewer comments:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Revised text:
verify that requested scopes are not higher priveleged than the scopes of presented subject_token.  <ins> 2.3.5. </ins> All of section 2.2 of RFC8693 applies.  In context of this specification the following applies in addtion:
Original text:
only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C. <del> 2.3.7. </del>  The example belows shows a command the client invokes to perform token exchange at authorization server of domain A (https://a.org/

Reviewer comments:
parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details

Revised text:
only one audience is used to prevent Authorization Server B to abuse and present the token to Authorization Server C.  <ins> 2.3.6. </ins> The example belows shows a command the client invokes to perform token exchange at authorization server of domain A (https://a.org/
Original text:
4. <del> To be added. </del>  5.  References

Reviewer comments:
Added a section in the security considerations to address topic raised by
Comment from Kelly: A.2.(D) I think AS in domain A at least SHOULD authenticate to AS in domain B. We have it as a MUST.
Perhaps this can be done in the security considerations.

Revised text:
4.  <ins> 4.1. Authorization Servers SHOULD follow the OAuth 2.0 Security Best Current Practice OAUTH2-BCP for client authentication. </ins> 5.  References
Original text:
2.3. This specification does not define authorization server discovery.  A <del> client MAY contact the resource and leverage the WWW-Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. </del>  2.4. The client performs token exchange as defined in RFC8693 with the <del> authorization server for its own domain (e.g.  Domain A), in order to </del>  obtain an authorization grant that can be used with the authorization <del> server of a different domain (e.g.  Domain B) as specified in section </del>  1.3 of RFC6749. 2.4.1.

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
2.3. This specification does not define authorization server discovery.  A  <ins> client MAY contact the resource server and leverage the WWW- Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. </ins> 2.4. The client performs token exchange as defined in RFC8693 with the  <ins> authorization server for its own domain (e.g., Domain A) in order to </ins> obtain an authorization grant that can be used with the authorization  <ins> server of a different domain (e.g., Domain B) as specified in section </ins> 1.3 of RFC6749. 2.4.1.
Original text:
between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT <del> require a certain format or parse the authorization grant (for instance in caes of JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </del>  Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT  <ins> require a certain format or parse the authorization grant (e.g., if the token is encoded as a JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </ins> Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or
Original text:
2.4.4. All of section 2.2 of RFC8693 applies.  In addition, the following <del> applies to specification that conform to this specification. </del>  <del> Returned authorization grant MUST be audienced to the requested </del>  authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients <del> from presenting their access tokens as an authorization grant to an authorization server in a different domain. </del>  The returned authorization grant MAY be audienced to multiple authorization servers, provided that trust relationships exist with them (e.g. through federation).  It is RECOMMENDED that only one audience is used to prevent an authorization server in one <del> domain from presenting the client's authorization grant to another authorization in another trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </del>  2.4.5.

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
2.4.4. All of section 2.2 of RFC8693 applies.  In addition, the following  <ins> applies to implementations that conform to this specification. </ins>  <ins> Returned authorization grants MUST be audienced to the requested </ins> authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients  <ins> from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins> The returned authorization grant MAY be audienced to multiple authorization servers, provided that trust relationships exist with them (e.g. through federation).  It is RECOMMENDED that only one audience is used to prevent an authorization server in one  <ins> domain from presenting the client's authorization grant to an authorization server in a different trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </ins> 2.4.5.
Original text:
authorization server in its own domain and presents it to the authorization server in the domain of the resources server it wants to access as defined in the "Assertion Framework for OAuth 2.0 Client <del> Authentication and Auhorization Grants" RFC7521. </del>  2.5.1.

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
authorization server in its own domain and presents it to the authorization server in the domain of the resources server it wants to access as defined in the "Assertion Framework for OAuth 2.0 Client  <ins> Authentication and Authorization Grants" RFC7521. </ins> 2.5.1.
Original text:
All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules: <del> The request MUST be denied presented authorization grant is not audienced to the authorization server that processes the request </del>  The authorization server SHOULD deny the request if it is not able to identify the subject

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules:  <ins> The request MUST be denied if the presented authorization grant is not audienced to the authorization server that processes the request </ins> The authorization server SHOULD deny the request if it is not able to identify the subject
Original text:
2.6. Authorization servers MAY transcribe claims when either producing <del> authorization grant at the token exchange flow or access tokens at </del>  the assertion flow. : Subject identifier can differ between the parties involved.  For instance: A user is known at domain A by "johndoe@a.org" but in <del> domain B by "doe.john".  The mapping from one identifier to the other MAY either happen in the token exchange step and updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </del> 

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
2.6. Authorization servers MAY transcribe claims when either producing  <ins> authorization grants in the token exchange flow or access tokens in </ins> the assertion flow. : Subject identifier can differ between the parties involved.  For instance: A user is known at domain A by "johndoe@a.org" but in  <ins> domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </ins>
Original text:
: The authorization server performing the assertion flow MAY leverage claims from the presented authorization grant and include <del> it in the access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </del>  The representation of transcribed claims and their format is not defined in this specification.

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
: The authorization server performing the assertion flow MAY leverage claims from the presented authorization grant and include  <ins> them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </ins> The representation of transcribed claims and their format is not defined in this specification.
Original text:
authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. <del> A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </del> 2.1.

Reviewer comments:
Removes a duplicated section from the introduction
Feedback from Brian Campbell: Section 2 repeats itself with the text "A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange. The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B. The client in domain A may be a resource server, or it may be the authorization server itself." occurring twice.

Revised text:
authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself.  2.1.
Original text:
The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in <del> domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). </del>  2.5.

Reviewer comments:
Replaces examples and add response examples
Feedback from Brian Campbell Seeing curl commands in the examples is sort of unexpected. Typically these kinds of drafts try to show the "on the wire" HTTP message -something like this [URL] for example or this [URL] or [URL] etc

Revised text:
The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in  <ins> domain A (https://as.a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://as.b.org/ auth). </ins> 2.5.
Original text:
The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B <del> (https://b.org/auth) to receive an access token for a protected </del>  resource in trust domain B. 2.6.

Reviewer comments:
Replaces examples and add response examples
Feedback from Brian Campbell Seeing curl commands in the examples is sort of unexpected. Typically these kinds of drafts try to show the "on the wire" HTTP message -something like this [URL] for example or this [URL] or [URL] etc

Revised text:
The example belows shows how the client in trust domain A presents an authorization grant to the authorization server in trust domain B  <ins> (https://as.b.org/auth) to receive an access token for a protected </ins> resource in trust domain B. 2.6.
Original text:
If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" as defined in <del> RFC7521.  Otherwise, the client SHOULD request an access token using </del>  the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the purpose of this specification the following descriptions apply:

Reviewer comments:
Fixes RFC7523 reference (was RFC7521)
Feedback from Brian Campbell The reference in the first sentence of [URL] would be 7523 rather than 7521 (I got rather confused reading that paragraph :-) ).

Revised text:
If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" as defined in  <ins> RFC7523.  Otherwise, the client SHOULD request an access token using </ins> the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the purpose of this specification the following descriptions apply: