jiebi/TextFlow huggingface dataset:
Original text:
2.5.2. <del> All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules: </del>  <del> The request MUST be denied if the presented authorization grant does not include an "aud" claim identifying 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:
See
Feedback from Brian Campbell This requirement for the audience [URL] is already a requirement of [URL] (3rd bullet) and also [URL] (also 3rd bullet). But the way it's listed here makes it sound like an additional thing. It might be worthwhile to use the bullet here to be more specific about the aud value (it's been a bit of an interop pain point w/ JWT client auth fwiw) and say that it has to be the token endpoint or AS issuer identifier.

Revised text:
2.5.2.  <ins> All of Section 5.2 RFC7521 applies, in addition to the following processing rules: </ins>  <ins> The "aud" claim MUST identify the Authorization Server as a valid intended audience of the assertion using either the token endpoint as described Section 3 RFC7523 or the issuer identifier as defined in Section 2 of RFC8414. </ins> The authorization server SHOULD deny the request if it is not able to identify the subject.
Original text:
trust domains. A client in trust domain A that needs to access a resource server in <del> 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:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
trust domains. A client in trust domain A that needs to access a resource server in  <ins> trust domain B requests a JWT 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. </ins> 2.1.
Original text:
server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of <del> its own domain (Domain A) for an authorization grant that can be used at the authorization server in Domain B.  See token-exchange. </del>  (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with the </del>  authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation).

Reviewer comments:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of  <ins> its own domain (Domain A) for a JWT authorization grant that can be used at the authorization server in Domain B.  See token- exchange. </ins> (C) The authorization server of Domain A processes the request and  <ins> returns a JWT authorization grant that the client can use with the </ins> authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation).
Original text:
(D) The client presents the authorization grant to the authorization server of Domain B.  See access-token-request. <del> (E) Authorization server of Domain B validates the authorization grant and returns an access token. </del>  (F) The client now possesses an access token to access the protected resource in Domain B.

Reviewer comments:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
(D) The client presents the authorization grant to the authorization server of Domain B.  See access-token-request.  <ins> (E) Authorization server of Domain B validates the JWT authorization grant and returns an access token. </ins> (F) The client now possesses an access token to access the protected resource in Domain B.
Original text:
The client performs token exchange as defined in RFC8693 with the 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 server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </del>  2.4.1.

Reviewer comments:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
The client performs token exchange as defined in RFC8693 with the authorization server for its own domain (e.g., Domain A) in order to  <ins> obtain a JWT authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </ins> 2.4.1.
Original text:
All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification. <del> The "aud" claim in the returned authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </del>  <del> The "aud" claim included in the returned authorization grant MAY identify multiple authorization servers, provided that trust </del>  relationships exist with them (e.g. through federation).  It is RECOMMENDED that the "aud" claim is restricted to a single authorization server to prevent an authorization server in one

Reviewer comments:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification.  <ins> The "aud" claim in the returned JWT authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins>  <ins> The "aud" claim included in the returned JWT authorization grant MAY identify multiple authorization servers, provided that trust </ins> relationships exist with them (e.g. through federation).  It is RECOMMENDED that the "aud" claim is restricted to a single authorization server to prevent an authorization server in one
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://as.a.org/auth) to receive an authorization grant </del>  for the authorization server in trust domain B (https://as.b.org/ auth). 2.5. <del> The client presents the token it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </del>  2.5.1.

Reviewer comments:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

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 a JWT authorization grant </ins> for the authorization server in trust domain B (https://as.b.org/ auth). 2.5.  <ins> The client presents the JWT authorization grant it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </ins> 2.5.1.
Original text:
2.6. <del> Authorization servers MAY transcribe claims when either producing </del>  authorization grants in the token exchange flow or access tokens in the assertion flow.

Reviewer comments:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
2.6.  <ins> Authorization servers MAY transcribe claims when either producing JWT </ins> authorization grants in the token exchange flow or access tokens in the assertion flow.
Original text:
instance: A user is known at domain A by "johndoe@a.org" but in 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 <del> updated identifier 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:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
instance: A user is known at domain A by "johndoe@a.org" but in 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  <ins> updated identifier is reflected in returned JWT 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 <del> leverage claims from the presented authorization grant and include them in the returned 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:
when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant

Revised text:
: The authorization server performing the assertion flow MAY  <ins> leverage claims from the presented JWT authorization grant and include 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:
JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public <del> and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del>  1.3.

Reviewer comments:
Issue
Can you give an example where this is relevant? With excluding private claims we make sure all claims are uniquely identifiable across all parties of the three-party-model.
claims we make sure all claims are uniquely identifiable across all parties of the three-party-model. I dont believe this PR discourages public claims it simply reflects that there are bunch of scenarios where VC ecosystems what to interoperate on claims that are perhaps not general enough to register as public claims.
Please merge

Revised text:
JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public  <ins> and private claims.  This specification aims to express metadata of the properties of the Verifiable Credentials utilizing registered JWT claims, while allowing Issuers to use other registered, public, or private claims to make statements about the Subject of the Verifiable Credential. </ins> 1.3.
Original text:
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of Verifiable Credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </del>  This specification defines Verifiable Credentials based on the SD-JWT format with a JWT Claim Set.

Reviewer comments:
Status Provider should be either 4th party or issuer (not verifier).
Merging this since multiple approvals.
lgtm, thank you!

Revised text:
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt.  <ins> To support revocation of Verifiable Credentials, revocation information can optionally be retrieved from a Status Provider.  The role of a Status Provider can be fulfilled by either a fourth party or by the Issuer. </ins> This specification defines Verifiable Credentials based on the SD-JWT format with a JWT Claim Set.
Original text:
SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC) <del> draft-terbu-sd-jwt-vc-latest </del>  Abstract This specification describes data formats as well as validation and <del> processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </del>  1.

Reviewer comments:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Revised text:
SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC)  <ins> draft-terbu-oauth-sd-jwt-vc-latest </ins> Abstract This specification describes data formats as well as validation and  <ins> processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- selective-disclosure-jwt format.  It can be used when there are no selective disclosable claims, too. </ins> 1.
Original text:
Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. <del> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I- D.ietf-oauth-selective-disclosure-jwt. </del>  4.2.1.

Reviewer comments:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Revised text:
Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt.  <ins> When there are selectively disclosable claims, SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I-D.ietf-oauth- selective-disclosure-jwt. </ins> 4.2.1.
Original text:
Additional public claims MAY be used in SD-JWT VCs depending on the application.  4.3. The following is a non-normative example of an unsecured payload of

Reviewer comments:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Revised text:
Additional public claims MAY be used in SD-JWT VCs depending on the application. <ins> 4.2.2.4. An SD-JWT VC MAY have no selectively disclosable claims.  In that case, the SD-JWT VC MUST NOT contain the claim in the JWT body.  It also MUST NOT have any Disclosures. </ins> 4.3. The following is a non-normative example of an unsecured payload of
Original text:
described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt.  6.1.1. If the presentation of the SD-JWT VC includes a Holder Binding JWT,

Reviewer comments:
Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.

Revised text:
described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. <ins> When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. </ins> 6.1.1. If the presentation of the SD-JWT VC includes a Holder Binding JWT,
Original text:
1.1. <del> In the so-called Three-Party-Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </del>  cryptographically signed statements about a Subject, typically the Holder.

Reviewer comments:
Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm

Revised text:
1.1.  <ins> In the so-called Issuer-Holder-Verifier Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </ins> cryptographically signed statements about a Subject, typically the Holder.
Original text:
3. <del> TBD: explain use cases of the three-party-model. </del>  TBD: conventional crypt, hardware security, hsm, mobile secure area, compliance with FIPS

Reviewer comments:
Replace "Three-Party-Model" with "Issuer-Holder-Verifier Model"
There are lots of things that could be described as a three-party model (including classic OAuth where this work is aspiring for adoption). The use of "Three-Party-Model" in this document strikes me as somewhat presumptuous and potentially misleading or confusing. Could we instead use "Issuer-Holder-Verifier Model"?
I agree, since there must be always a trusted third party in the model, like a trust anchor or its intermediate
I typically refer to this model as "decentralized identity" or "verifiable credentials applications/solutions/ecosystems", I would be fine with "digital credentials applications/solutions/ecosystems".
I'm suggesting only to replace the 5 or 6 usages of "Three-Party-Model" with "Issuer-Holder-Verifier Model".
That would work for me and I understand that Three-Party-Model is confusing since other architectures also involve 3 parties.
I'm ok with using "Issuer-Holder-Verifier Model".
It seems that this issue is ready for a PR.
is that PR
thanks, lgtm

Revised text:
3.  <ins> TBD: explain use cases of the Issuer-Holder-Verifier Model. </ins> TBD: conventional crypt, hardware security, hsm, mobile secure area, compliance with FIPS
Original text:
<del> SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC) </del>  draft-terbu-oauth-sd-jwt-vc-latest Abstract

Reviewer comments:
As NAME has aptly pointed out, 'the "with JSON payloads" wording is clunky and redundant.'
lgtmI see no reason to have the "with JSON payloads" in the title

Revised text:
 <ins> SD-JWT-based Verifiable Credentials (SD-JWT VC) </ins> draft-terbu-oauth-sd-jwt-vc-latest Abstract
Original text:
. The <del> claim is used to express the type of the JSON object that is secured by the JWT.  The </del> value MUST be a case-sensitive <del> value. </del>  The following is a non-normative example of how is used to express a type:  4.2.2.2. SD-JWT VCs MAY use any claim registered in the "JSON Web Token

Reviewer comments:
I worry about collisions and confusion with (and with ) - those of us that work with this stuff will likely understand the difference, but there is probably a better descriptor we could use than for this reason. Maybe specifying "schema" or "schemaName" or "sn" (for nice short form) would be more useful here
NAME there is a conversation on renaming type claim in Issue URL which should be a separate PR if we agree on an alternative claim name..
lgtm after we applied NAME suggestion

Revised text:
. The  value MUST be a case-sensitive  <ins> value serving as an identifier for the type of the SD-JWT VC.  A type defines which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims and associated rules (e.g., policies for issuing and validating credentials beyond what is defined in this specification). </ins> The following is a non-normative example of how is used to express a type: <ins> For example, a type can be defined such that at least the registered JWT claims , , , and must appear in the Unsecured Payload.  Additionally, the registered JWT claims and , and the private claims , , and may be used.  The type might also indicate that , , , can be selectively disclosable. </ins> 4.2.2.2. SD-JWT VCs MAY use any claim registered in the "JSON Web Token