jiebi/TextFlow huggingface dataset:
Original text:
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- <del> selective-disclosure-jwt format.  It can be used when there are no </del>  selective disclosable claims, too. 1.

Reviewer comments:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Revised text:
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth-  <ins> selective-disclosure-jwt format.  It can be used without any </ins> selective disclosable claims, too. 1.
Original text:
1.4. This specification uses the terms "Holder", "Issuer", "Verifier", <del> defined by I-D.ietf-oauth-selective-disclosure-jwt. </del>  2.

Reviewer comments:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Revised text:
1.4. This specification uses the terms "Holder", "Issuer", "Verifier",  <ins> "Key Binding JWT" defined by I-D.ietf-oauth-selective-disclosure-jwt. </ins> 2.
Original text:
4.2. <del> SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. </del>  <del> 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. </del>  4.2.1.

Reviewer comments:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Revised text:
4.2.  <ins> SD-JWT VCs MUST be encoded using the SD-JWT format defined in Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation of an SD-JWT VC MAY contain a Key Binding JWT. </ins>  <ins> Note that in some cases, an SD-JWT VC MAY have no selectively disclosable claims, and therefore the encoded SD-JWT will not contain any Disclosures. </ins> 4.2.1.
Original text:
6.1. <del> A presentation of an SD-JWT VC MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of I- D.ietf-oauth-selective-disclosure-jwt. A presentation of an SD-JWT VC MAY contain a Key Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. 6.1.1. </del> If the presentation of the SD-JWT VC includes a Key Binding JWT, the following claims are used within the Key Binding JWT:

Reviewer comments:
I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm

Revised text:
6.1.  If the presentation of the SD-JWT VC includes a Key Binding JWT, the following claims are used within the Key Binding JWT:
Original text:
4.4. <del> The recipient of the SD-JWT VC MUST process and verify an SD-JWT VC as follows: </del>  Any claims used that are not understood MUST be ignored.

Reviewer comments:
We currently have two section describing verification by Verifiers. This commit consolidates both sections. Importantly, this commit fixes the description of the key binding check to ensure that removing a KB JWT from the presentation does not allow circumventing KB.
thank you! great improvement.

Revised text:
4.4.  <ins> The recipient (Holder or Verifier) of an SD-JWT VC MUST process and verify an SD-JWT VC as described in Section 6 of I-D.ietf-oauth- selective-disclosure-jwt. If Key Binding is required (refer to the security considerations in Section 9.6 of I-D.ietf-oauth-selective-disclosure-jwt), the Verifier MUST verify the Key Binding JWT according to Section 6 of I-D.ietf- oauth-selective-disclosure-jwt.  To verify the Key Binding JWT, the claim of the SD-JWT MUST be used. For the verification, the claim in the SD-JWT MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in jwt-issuer-metadata) of the SD-JWT VC issuer.  Alternative methods MAY be used to obtain the public key to verify the signature of the SD-JWT. If there are no selectively disclosable claims, there is no need to process the claim nor any Disclosures. If is present in the verified payload of the SD-JWT, the status SHOULD be checked.  It depends on the Verifier policy to reject or accept a presentation of a SD-JWT VC based on the status of the Verifiable Credential. </ins> Any claims used that are not understood MUST be ignored.
Original text:
The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: <del> 6.3. The Verifier MUST process and verify a presentation of SD-JWT VC as follows: </del> 7. TBD: Verifier provided

Reviewer comments:
We currently have two section describing verification by Verifiers. This commit consolidates both sections. Importantly, this commit fixes the description of the key binding check to ensure that removing a KB JWT from the presentation does not allow circumventing KB.
thank you! great improvement.

Revised text:
The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT:  7. TBD: Verifier provided
Original text:
3.2.2.1.  This specification defines the JWT claim . The value MUST be a case-sensitive <del> 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 </del>  values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims

Reviewer comments:
URL
I found several minor issues here: The spec has the following headlines: 4.2.2 Claims Comparing this to RFC7519 JWT these should be: JOSE Header JWT Claims Set Also, in 4.2.2.1 type claim is never explained. This should be added to the Terminology. Its also missing a link to the Annex A.1.
Additionally, headline 4.2.2.1 would better fit saying "New JWT Claims"?

Revised text:
3.2.2.1. <ins> 3.2.2.1.1. </ins> This specification defines the JWT claim . The value MUST be a case-sensitive  <ins> (see RFC7519) 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 </ins> values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims
Original text:
6. <del> TBD: Verifier provided . </del>  7.

Reviewer comments:
Add reference to Security Considerations in SD-JWT
E.g.: SSRF with Issuer URI

Revised text:
6.  <ins> The Security Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following security considerations need to be taken into account when using SD-JWT VCs: 6.1. The JWT Issuer Metadata configuration is retrieved from the JWT Issuer by the Holder or Verifier.  Similar to other metadata endpoints, the URL for the retrieval MUST be considered an untrusted value and could be a vector for Server-Side Request Forgery (SSRF) attacks. Before making a request to the JWT Issuer Metadata endpoint, the Holder or Verifier MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources.  This requires, in particular, ensuring that the host part of the URL does not address an internal service (by IP address or an internal host name) and that, if an external DNS name is used, the resolved DNS name does not point to an internal IPv4 or IPv6 address. When retrieving the metadata, the Holder or Verifier MUST ensure that the request is made in a time-bound and size-bound manner to prevent denial of service attacks.  The Holder or Verifier MUST also ensure that the response is a valid JWT Issuer Metadata configuration document before processing it. Additional considerations can be found in OWASP_SSRF. </ins> 7.
Original text:
Abstract <del> This document specifies Verifiable Credentials based on Selective Disclosure JSON Web Tokens (SD-JWT) with JSON payloads. </del>  1. <del> TBD: why? - simplicity - JWTs are well-known, popular but doesn't work best with three-party-model - Also no selective disclosure, which impacts costs and security. This specification describes data formats, validation and processing rules for SD-JWT expresing Verifiable Credentials. </del>  1.1.

Reviewer comments:
NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that

Revised text:
Abstract  <ins> This specification describes data formats, validation and processing rules to express Verifiable Credentials based on the SD-JWT format (TBD: see oauth-selective-disclosure-jwt) using JSON payloads. </ins> 1.  <ins> Todo: Discuss VCs, introduce terminology. Signed JSON Web Tokens (JWTs) RFC7519 can in principle be used to express 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 only a subset of the claims contained in the JWT.  This is a common problem in the so-called three-party model: An Issuer creates a Verifiable Credential for some End-User (Holder), who then presents this credential to multiple Verifiers.  A 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 signed 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. 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 suitable for Verifiable Credentials. SD-JWT itself does not define the claims that must be used within the payload of the token or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. Todo: Explain the 'plain JSON' part </ins> 1.1.
Original text:
5.2. SD-JWT-VCs as defined in this specification can use any claim <del> registered in the "JSON Web Token Claims" registry as defined in RFC 7519. </del>  Some of the claims in a VC MUST NOT be selectively disclosed as they are always required for processing on the verifier side.  All other

Reviewer comments:
NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that

Revised text:
5.2. SD-JWT-VCs as defined in this specification can use any claim  <ins> registered in the "JSON Web Token Claims" registry as defined in RFC7519. </ins> Some of the claims in a VC MUST NOT be selectively disclosed as they are always required for processing on the verifier side.  All other
Original text:
A verifier MUST validate an SD-JWT-VC as follows: <del> Additional validation rules MAY apply but their use is out-of-scope of this specification. </del>  6.1. <del> Verifiers processing SD-JWT-VCs MUST verify the signature of the SD- JWT with the public key of the SD-JWT-VC issuer.  This makes sure that the SD-JWT-VC was issued by the SD-JWT-VC issuer and that it has not been tampered with since issuance. The claim in the SD-JWT-VC MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in {#jwt-issuer- metadata}) of the SD-JWT-VC issuer.  A verifier MAY use alternative methods to obtain the public key to verify the signature of the SD- JWT. 6.2. </del> This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the

Reviewer comments:
NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that

Revised text:
A verifier MUST validate an SD-JWT-VC as follows:  <ins> Additional validation rules MAY apply, but their use is out of the scope of this specification. </ins> 6.1.  This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the
Original text:
The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the <del> application/json content type. </del>  This specification defines the following JWT Issuer Metadata parameters:  It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the

Reviewer comments:
NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that

Revised text:
The JWT Issuer Metadata configuration MUST be a JSON document compliant with this specification and MUST be returned using the  <ins> content type. </ins> This specification defines the following JWT Issuer Metadata parameters: <ins> JWT Issuer Metadata MUST include either or in their JWT Issuer Metadata, but not both. </ins> It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the
Original text:
value MUST be a case-sensitive (see RFC7519) value serving as an identifier for the type of the SD- <del> 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 </del>  values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims

Reviewer comments:
Type identifiers MUST be collision-resistant names as defined in RFC7515 Changed the example to a URI

Revised text:
value MUST be a case-sensitive (see RFC7519) value serving as an identifier for the type of the SD-  <ins> JWT VC.  The value MUST be a Collision-Resistant Name as defined in Section 2 of RFC7515. A type is associated with rules defining 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 </ins> values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims
Original text:
, and <del> may be used.  The type might also indicate that , , , can be selectively disclosable. </del>  3.2.2.2.

Reviewer comments:
Type identifiers MUST be collision-resistant names as defined in RFC7515 Changed the example to a URI

Revised text:
, and  <ins> may be used.  The type might also indicate that any of the aforementioned claims can be selectively disclosable. </ins> 3.2.2.2.
Original text:
This specification defines the JWT claim <del> . The </del>  value MUST be a case-sensitive

Reviewer comments:
This PR renames the claim to , as per the discussion in
I oppose against this change. I suggest to use 'vct' instead.
I'm good with . For the record, I think it's important to move away from , because URL uses the claim name, but with a different syntax. Keeping the naming conflict will inevitably lead to grief.
Naming is hard. Regarding dct: isn't it obvious for an internet standard that we refer to digital credentials?
Neither dct nor vct are intuitive for me, so I am pretty unsure. But between dct and vct, I would prefer dct. A term Verifiable credentials got enough feedback that it has strong too strong of an association to W3C VC-DATA-MODEL. And Digital credentials seems to be a term that is acceptable to generalize.
Why is "Verifiable Credential Type" (vct) not intuitive to you? This would match the current definition of . Isn't this what this claim is about? That is why I'm actually in favor of over , .
I meant that abbreviations are not intuitive to me. And "type" is a pretty JSON-LD specific construct AFAIK so I was hoping we could have a deeper discussion on whether it should be called "claimset" or something. If we are to move away from "type" claim name. on dct and vct, as I explained, I prefer something that is not associated to W3C VCDM and digital credentials seems to be pretty well understood.
If the color of the bikeshed is still open for debate, how about just for credential type?
I like 3-letter-names more than 2-letter-names for some reason. Also, is more accurate since the spec is about SD-JWT VCs => Verifiable Credentials. I'd be still in favor of for that reason.
is fine for me. Updated the PR accordingly.
is fine for me too. was just an off-hand idea
Merging this PR since a lot of approvals. We will have a larger conversation on what is inferred by the value in a separate issue.
I suggest to use 'vct'.LGTM. We should address NAME concern in a separate issue.This is an improvement.

Revised text:
This specification defines the JWT claim  <ins> (for verifiable credential type).  The </ins> value MUST be a case-sensitive
Original text:
is used to express a type: <del> For example, a type </del>  can be associated with rules that define that at least the registered JWT claims

Reviewer comments:
This PR renames the claim to , as per the discussion in
I oppose against this change. I suggest to use 'vct' instead.
I'm good with . For the record, I think it's important to move away from , because URL uses the claim name, but with a different syntax. Keeping the naming conflict will inevitably lead to grief.
Naming is hard. Regarding dct: isn't it obvious for an internet standard that we refer to digital credentials?
Neither dct nor vct are intuitive for me, so I am pretty unsure. But between dct and vct, I would prefer dct. A term Verifiable credentials got enough feedback that it has strong too strong of an association to W3C VC-DATA-MODEL. And Digital credentials seems to be a term that is acceptable to generalize.
Why is "Verifiable Credential Type" (vct) not intuitive to you? This would match the current definition of . Isn't this what this claim is about? That is why I'm actually in favor of over , .
I meant that abbreviations are not intuitive to me. And "type" is a pretty JSON-LD specific construct AFAIK so I was hoping we could have a deeper discussion on whether it should be called "claimset" or something. If we are to move away from "type" claim name. on dct and vct, as I explained, I prefer something that is not associated to W3C VCDM and digital credentials seems to be pretty well understood.
If the color of the bikeshed is still open for debate, how about just for credential type?
I like 3-letter-names more than 2-letter-names for some reason. Also, is more accurate since the spec is about SD-JWT VCs => Verifiable Credentials. I'd be still in favor of for that reason.
is fine for me. Updated the PR accordingly.
is fine for me too. was just an off-hand idea
Merging this PR since a lot of approvals. We will have a larger conversation on what is inferred by the value in a separate issue.
I suggest to use 'vct'.LGTM. We should address NAME concern in a separate issue.This is an improvement.

Revised text:
is used to express a type:  <ins> For example, a value of </ins> can be associated with rules that define that at least the registered JWT claims