jiebi/TextFlow huggingface dataset:
Original text:
is used to express a type: <del> 4.1.2.2. </del>  <del> The following are non-selectively disclosable registered JWT claims that SD-JWTs of VC-SD-JWTs contain for specific purposes: </del>  <del> The following are selectively disclosable registered JWT claims that SD-JWTs of VC-SD-JWTs contain for specific purposes: </del>  <del> 4.2. </del>  The following is a non-normative example of a Credential acting as the input for the VC-SD-JWT:

Reviewer comments:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Revised text:
is used to express a type:  <ins> 4.2.2.2. </ins>  <ins> VC-SD-JWTs MAY use any claim registered in the "JSON Web Token Claims" registry as defined in RFC7519. </ins>  <ins> If present, the following registered JWT claims MUST be included in the SD-JWT and MUST NOT be included in the Disclosures, i.e. cannot be selectively disclosed: </ins>  <ins> The following registered JWT claims MAY be contained in the SD-JWT or in the Disclosures and MAY be selectively disclosed: 4.2.2.3. Additional public claims MAY be used in the SD-JWT or in the Disclosures depending on the application. 4.3. </ins> The following is a non-normative example of a Credential acting as the input for the VC-SD-JWT:
Original text:
TBD: add other disclosures. <del> 4.3. </del>  <del> A Verifier MUST validate an VC-SD-JWT as follows: </del>  Additional validation rules MAY apply, but their use is out of the scope of this specification.

Reviewer comments:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Revised text:
TBD: add other disclosures.  <ins> 4.4. The recipient of the VC-SD-JWT MUST process and verify an VC-SD-JWT as follows: </ins>  <ins> Any claims used that are not understood MUST be ignored. </ins> Additional validation rules MAY apply, but their use is out of the scope of this specification.
Original text:
6. <del> This specification defines the media type which describes the VP-SD-JWT with the following components: </del>  6.1. <del> The following is a non-normative example of a VP-SD-JWT without holder binding: </del>  <del> The following is a non-normative example of a VP-SD-JWT with holder binding: </del>  6.2. <del> TBD: same as VC-SD-JWT (-> refer to SD-JWT) + Holder Binding </del>  7. <del> TBD </del>  8. <del> TBD </del>  9.

Reviewer comments:
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.

Revised text:
6.  <ins> This section defines encoding, validation and processing rules for VP-SD-JWTs. </ins> 6.1.  <ins> VP-SD-JWTs compliant with this specification MUST use the media type </ins>  <ins> as defined in {#application-vp-sd-jwt}. </ins> 6.2.  <ins> VP-SD-JWTs MUST be encoded using the SD-JWT Combined Format for Presentation as defined in I-D.ietf-oauth-selective-disclosure-jwt. VP-SD-JWTs MAY contain a Holder Binding JWT as described in I-D.ietf- oauth-selective-disclosure-jwt. 6.2.1. If the VP-SD-JWT includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: The Holder Binding JWT MAY include addtional claims which when not understood MUST be ignored. 6.3. The following is a non-normative example of a VP-SD-JWT without Holder Binding: The following is a non-normative example of a VP-SD-JWT with Holder Binding: 6.4. The Verifier MUST process and verify an VP-SD-JWT as follows: </ins> 7.  <ins> TBD: Verifier provided . </ins> 8.  <ins> TBD: Holder provided nonce via . </ins> 9.
Original text:
Issuer about a Subject of the Verifiable Credential.  Verifiable Credentials are issued to Holders which can present Verifiable Credentials to Verifiers typically in form of Verifiable <del> Presentations which are secure Verifiable Credentials addressed to a </del>  specific audience. These relationships are described by the three-party-model which

Reviewer comments:
Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.

Revised text:
Issuer about a Subject of the Verifiable Credential.  Verifiable Credentials are issued to Holders which can present Verifiable Credentials to Verifiers typically in form of Verifiable  <ins> Presentations which secure Verifiable Credentials addressed to a </ins> specific audience. These relationships are described by the three-party-model which
Original text:
I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and <del> Verifiable Presentations, are further described in [VCDM2.0]. However, this specification focuses on a specific version of the three-party-model which can have different features but will provide a representation of the model described in [VCDM2.0]. </del>  1.2.

Reviewer comments:
Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.

Revised text:
I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and  <ins> Verifiable Presentations, are further described in VC-DATA.  However, this specification focuses on a specific version of the three-party- model which can have different features but will provide a representation of the model described in VC-DATA. </ins> 1.2.
Original text:
This specification registers the media type <del> in the W3C Verifiable Credentials (VC) Directory. </del>  9.1.2. The following is a uni-directional transformation algorithm that takes in a VC-SD-JWT conformant to this specification and maps it to <del> the corresponding properties in the W3C VCDM 2.0 [VCDM2.0] which is </del>  based on a JSON-LD vocabulary.  It includes specific handling for JWT claims used in this specification.  The function returns a Verifiable Credential object in the W3C VCDM 2.0 format. <del> The following is a uni-directional transformation algorithm from a VP-SD-JWT onto W3C Verifiable Presentations in pseudo-code: </del>  <del> #### </del> 

Reviewer comments:
Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.

Revised text:
This specification registers the media type  <ins> in the W3C Verifiable Credentials (VC) Directory VC-DIR. </ins> 9.1.2. The following is a uni-directional transformation algorithm that takes in a VC-SD-JWT conformant to this specification and maps it to  <ins> the corresponding properties in the W3C VCDM 2.0 VC-DATA which is </ins> based on a JSON-LD vocabulary.  It includes specific handling for JWT claims used in this specification.  The function returns a Verifiable Credential object in the W3C VCDM 2.0 format.  <ins> Procedure: 1.  Let </ins>  <ins> be the unsecured payload of the VC-SD-JWT reconstructed from the SD- JWT and Disclosures.  1.  Let be an empty JSON object that represents the transformed Verifiable Credential: - Set the property of to .  1.  If the payload contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from the payload.  1.  If the payload contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from the payload.  1.  If the payload contains the property: - Assign the value of to the property of .  - Remove the claim from the payload.  1.  Set the property of to the value of the property in the payload.  - Remove the claim from the payload.  1.  Set the property of to a String array and set the first array element to . Add the value of the property in the payload as the second array element.  - Remove the claim from the payload.  1.  If the payload contains the property: - Assign the value of as the property of the object in .  - Remove the claim from the payload.  1.  Else if the payload does not have a property, create an empty object.  1.  Add all remaining claims in the payload to the object of and ignore claims that do not have a corresponding representation. 1.  Output which contains the resulting Verifiable Credential. The following is a non-normative example of a pseudocode algorithm: </ins>
Original text:
claims used in this specification.  The function returns a Verifiable Credential object in the W3C VCDM 2.0 format. <del> Procedure: 1.  Let be the unsecured payload of the SD-JWT VC reconstructed from the SD- JWT and Disclosures.  1.  Let be an empty JSON object that represents the transformed Verifiable Credential: - Set the property of to .  1.  If contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from .  1.  If contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from .  1.  If contains the property: - Assign the value of to the property of .  - Remove the claim from .  1.  Set the property of to the value of the property in .  - Remove the claim from .  1.  Set the property of to a String array and set the first array element to . Add the value of the property in as the second array element.  - Remove the claim from .  1.  If contains the property: - Assign the value of as the property of the object in .  - Remove the claim from .  1.  Else if does not have a property, create an empty object.  1.  Add all remaining claims in to the object of and ignore claims that do not have a corresponding representation. 1.  Output which contains the resulting Verifiable Credential. </del>  The following is a non-normative example of a pseudocode algorithm:

Reviewer comments:
In the rendered HTML, the entire algo appears in one paragraph. The mmark is probably broken and has to be fixed.
lgtm, thank you!

Revised text:
claims used in this specification.  The function returns a Verifiable Credential object in the W3C VCDM 2.0 format.  <ins> Procedure: </ins> The following is a non-normative example of a pseudocode algorithm:
Original text:
I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and <del> Verifiable Presentations, are further described in VC-DATA.  However, this specification focuses on a specific version of the three-party- model which can have different features but will provide a representation of the model described in VC-DATA. </del>  1.2.

Reviewer comments:
As agreed on the editor's call (5/23), the following ... should become ...
I'm still confused why we need this text at all. What people will basically get is "this spec deviates from the VCDM 2.0".

Revised text:
I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and  <ins> Verifiable Presentations, is also described in VC-DATA.  However, this specification provides a specific format of Verifiable Credentials which deviates from the format described in VC-DATA to create Verifiable Credentials based on SD-JWT and JSON payloads but a translation algorithm is provided in this specification. </ins> 1.2.
Original text:
Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWTs do not support selective disclosure, i.e., the ability to disclose <del> only a subset of the claims contained in the JWT, in the three-party- model as described above.  This is a common problem in the three- party model: An Issuer creates a Verifiable Credential for some End- User (Holder), who then can presents this credential to multiple Verifiers.  A Verifiable Credential might contain a large number of claims, but the Holder typically only wants to disclose a subset of these claims to a Verifier.  In this case, the Holder would have to receive a new JWT from the Issuer, containing only the claims that should be disclosed, for each interaction with a new Verifier.  This is inefficient, costly, and the necessary interaction with the Issuer introduces additional privacy risks. </del>  Selective Disclosure JWT (SD-JWT) [SD-JWT] is a specification that introduces conventions to support selective disclosure for JWTs: For

Reviewer comments:
fix:
in the three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers. A Verifiable Credential might contain a large number of claims, but the Holder We should short this as suggested by NAME Originally posted by NAME in URL
Relates to

Revised text:
Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWTs do not support selective disclosure, i.e., the ability to disclose  <ins> only a subset of the claims contained in the JWT, which is a requirement to implement the three-party-model efficiently. </ins> Selective Disclosure JWT (SD-JWT) [SD-JWT] is a specification that introduces conventions to support selective disclosure for JWTs: For
Original text:
scheme, host and, optionally, port number and path components, but no query or fragment components. <del> The following is a non-normative example of the URL of the JWT Issuer Metadata configuration when </del>  is set to : <del> The following is a non-normative example of the URL of the JWT Issuer Metadata configuration when </del>  is set to : <del> The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the </del>  content type.  This specification defines the following JWT Issuer Metadata <del> parameters: </del>  JWT Issuer Metadata MUST include either

Reviewer comments:
The rules for obtaining the issuer metadata needs to be extended to cope with paths as well. I suggest to use the text from URL
The following example is already supported ... NAME is this what you had in mind, or is there anything missing? In that case, we could add an example that makes it more visible that this use case is supported.
URL needs to be URL have a look at URL
Ok, makes sense. Will create a PR to fix that.

Revised text:
scheme, host and, optionally, port number and path components, but no query or fragment components.  <ins> 5.1. A JWT Issuer Metadata configuration MUST be queried using an HTTP request at the path defined in jwt-issuer-metadata. The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when </ins> is set to :  <ins> If the value contains a path component, any terminating MUST be removed before inserting and the well-known URI suffix between the host component and the path component. The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when </ins> is set to :  <ins> 5.2. A successful response MUST use the and return the JWT Issuer Metadata configuration using the </ins> content type. <ins> An error response uses the applicable HTTP status code value. </ins> This specification defines the following JWT Issuer Metadata  <ins> configuration parameters: </ins> JWT Issuer Metadata MUST include either
Original text:
JWK Set included by value or referenced in the JWT Issuer Metadata. The following is a non-normative example of a JWT Issuer Metadata <del> including </del>  : The following is a non-normative example of a JWT Issuer Metadata <del> including </del>  :  6. This section defines encoding, validation and processing rules for

Reviewer comments:
The rules for obtaining the issuer metadata needs to be extended to cope with paths as well. I suggest to use the text from URL
The following example is already supported ... NAME is this what you had in mind, or is there anything missing? In that case, we could add an example that makes it more visible that this use case is supported.
URL needs to be URL have a look at URL
Ok, makes sense. Will create a PR to fix that.

Revised text:
JWK Set included by value or referenced in the JWT Issuer Metadata. The following is a non-normative example of a JWT Issuer Metadata  <ins> configuration including </ins> : The following is a non-normative example of a JWT Issuer Metadata  <ins> configuration including </ins> : <ins> Additional JWT Issuer Metadata configuration parameters MAY also be used. 5.3. The value returned MUST be identical to the value of the JWT.  If these values are not identical, the data contained in the response MUST NOT be used. </ins> 6. This section defines encoding, validation and processing rules for
Original text:
4.3. <del> The following is a non-normative example of an unsecured input payload of an SD-JWT VC. </del>  <del> The following is a non-normative example of how the Credential above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable: </del>  Note that a

Reviewer comments:
NAME can we merge this now?
Try to find a new term.
Introduce and use the term "unsecured payload" instead of payload or credential to refer to the input JSON document. We cannot use payload because it would lead to confusion since the payload of the SD-JWT might not even contain all the claims and only the hashes.

Revised text:
4.3.  <ins> The following is a non-normative example of an unsecured payload of an SD-JWT VC. </ins>  <ins> The following is a non-normative example of how the unsecured payload of the SD-JWT VC above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable: </ins> Note that a
Original text:
contained in the JWT, which is a requirement to implement the three- party-model efficiently. <del> Selective Disclosure JWT (SD-JWT) [SD-JWT] is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).  This format is therefore perfectly suited for Verifiable Credentials and Verifiable Presentations. </del>  SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how

Reviewer comments:
This just fixes typos and references.
This just fixes typos and references. No review required at this stage.

Revised text:
contained in the JWT, which is a requirement to implement the three- party-model efficiently.  <ins> Selective Disclosure JWT (SD-JWT) I-D.ietf-oauth-selective- disclosure-jwt is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).  This format is therefore perfectly suited for Verifiable Credentials and Verifiable Presentations. </ins> SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how
Original text:
4.2. SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for <del> Issuance as defined in I-D.ietf-oauth-selective-disclosure-jwt. </del>  SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT <del> component except for Decoy Digests as per section 5.1.1.3. of I- </del>  D.ietf-oauth-selective-disclosure-jwt. 4.2.1.

Reviewer comments:
Only minor editorial changes such as typos.
Only minor editorial changes such as typos -> no peer-review required at this stage.

Revised text:
4.2. SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for  <ins> Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. </ins> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT  <ins> component except for Decoy Digests as per Section 5.1.1.3. of I- </ins> D.ietf-oauth-selective-disclosure-jwt. 4.2.1.
Original text:
6.1. SD-JWT VPs MUST be encoded using the SD-JWT Combined Format for <del> Presentation as defined in I-D.ietf-oauth-selective-disclosure-jwt. </del>  <del> SD-JWT VPs MAY contain a Holder Binding JWT as described in I-D.ietf- oauth-selective-disclosure-jwt. </del>  6.1.1.

Reviewer comments:
Only minor editorial changes such as typos.
Only minor editorial changes such as typos -> no peer-review required at this stage.

Revised text:
6.1. SD-JWT VPs MUST be encoded using the SD-JWT Combined Format for  <ins> Presentation as defined in Section 5.4. of I-D.ietf-oauth-selective- disclosure-jwt. </ins>  <ins> SD-JWT VPs MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure-jwt. </ins> 6.1.1.