jiebi/TextFlow huggingface dataset:
Original text:
4.4. <del> The following shows the contents of a release document for Example 1: </del>  For each claim, an array of the salt and the claim value is contained in the object. <del> Again, the release document follows the same structure as the </del>  <del> in the SD-JWT.  For Example 2, a release document limiting </del>  to

Reviewer comments:
addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR

Revised text:
4.4.  <ins> The following shows the contents of an SD-JWT-R for Example 1: </ins> For each claim, an array of the salt and the claim value is contained in the object.  <ins> Again, the SD-JWT-R follows the same structure as the </ins>  <ins> in the SD-JWT.  For Example 2, a SD-JWT-R limiting </ins> to
Original text:
only could look as follows: <del> The SD-JWT Release MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </del>  and claims). <del> If holder binding is desired, the SD-JWT Release is signed by the holder.  If no holder binding is to be used, the </del>  algorithm is used, i.e., the document is not signed.

Reviewer comments:
addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR

Revised text:
only could look as follows:  <ins> The SD-JWT-R MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </ins> and claims).  <ins> If holder binding is desired, the SD-JWT-R is signed by the holder. If no holder binding is to be used, the </ins> algorithm is used, i.e., the document is not signed.
Original text:
4.5. <del> The SD-JWT and the SD-JWT Release can be combined into one document using </del>  as a separator (here for Example 1):

Reviewer comments:
addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR

Revised text:
4.5.  <ins> The SD-JWT and the SD-JWT-R can be combined into one document using </ins> as a separator (here for Example 1):
Original text:
1.1.  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP

Reviewer comments:
I think we need a section summarizing what kind of claims SD-JWT can consist of... claims in SD-JWT can all be selectively disclosable claims, or can also include always-disclosed claims claim names in SD-JWT can all be blinded, or can include non-blinded claim names claim structure can be simple or complex and claims in the complex structure can be blinded/not-blinded and disclosable/not-disclosable same claim names can appear within multiple complex claim structures and can be blinded/not-blinded and disclosable/not-disclosable...

Revised text:
1.1. <ins> 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP
Original text:
Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user on the basis of unique values encoded in the SD-JWT (Issuer <del> signature, salts, digests, etc.).  More advanced cryptographic schemes, outside the scope of this specification, can be used to prevent this type of linkability. </del>  9. <del> We would like to thank Alen Horvat, Brian Campbell, Christian Paquin, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Shawn Butterfield, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del>  The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Reviewer comments:
Added an option to do pairwise SD-JWTs to prevent Verifier/Verifier linkability Original feedback. Please re-write section 8.2 in the light of the above suggestions.

Revised text:
Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user on the basis of unique values encoded in the SD-JWT (Issuer  <ins> signature, salts, digests, etc.). To prevent these types of linkability, various methods, including but not limited to the following ones can be used: </ins> 9.  <ins> We would like to thank Alen Horvat, Arjan Geluk, Brian Campbell, Christian Paquin, David Bakker, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Original text:
disclosure (SD-JWT) which would enable sharing only subset of the claims included in the original JWT instead of releasing all the claims to every Verifeir.  This document also defines an optional <del> format for signatures called releases (SD-JWT-R). </del>  One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such use case, there has been no

Reviewer comments:
Fixing the "release" in the sense of a defined term as "SD-JWT Release"
We have fixed the term and definitions but a few still appear in the main text. We need to fix them as well, hopefully before the first individual draft is uploaded. So, s/signatures called releases/signatures called SD-JWT Releases/ s/SD-JWTs and releases/SD-JWTs and SD-JWT Releases/ s/Verifying a Release/Verifying a SD-JWT Release/
Fixed with PR

Revised text:
disclosure (SD-JWT) which would enable sharing only subset of the claims included in the original JWT instead of releasing all the claims to every Verifeir.  This document also defines an optional  <ins> format for signatures called SD-JWT Releases (SD-JWT-R). </ins> One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such use case, there has been no
Original text:
3. <del> In the following section, the concepts of SD-JWTs and releases are described at a conceptual level. </del>  3.1.

Reviewer comments:
Fixing the "release" in the sense of a defined term as "SD-JWT Release"
We have fixed the term and definitions but a few still appear in the main text. We need to fix them as well, hopefully before the first individual draft is uploaded. So, s/signatures called releases/signatures called SD-JWT Releases/ s/SD-JWTs and releases/SD-JWTs and SD-JWT Releases/ s/Verifying a Release/Verifying a SD-JWT Release/
Fixed with PR

Revised text:
3.  <ins> In the following section, the concepts of SD-JWTs and SD-JWT Releases are described at a conceptual level. </ins> 3.1.
Original text:
verifier.  However, when a signed JWT is intended to be multi-use, the ability to selectively disclose a subset of the claims depending on the verifier becomes crucial to ensure minimum disclosure and <del> prevent verifier from obtaining claims irrelevant for the use case at hand. </del>  One example of such a multi-use JWT is a verifiable credential, or a tamper-evident credential with a cryptographically verifiable

Reviewer comments:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Revised text:
verifier.  However, when a signed JWT is intended to be multi-use, the ability to selectively disclose a subset of the claims depending on the verifier becomes crucial to ensure minimum disclosure and  <ins> prevent verifier from obtaining claims irrelevant for the transaction at hand. </ins> One example of such a multi-use JWT is a verifiable credential, or a tamper-evident credential with a cryptographically verifiable
Original text:
Note: so far agreed to define holder binding (user's public key contained inside an SD-JWT) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general <del> mechanism of selective disclosure we are trying to define here. </del>  1.1.

Reviewer comments:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Revised text:
Note: so far agreed to define holder binding (user's public key contained inside an SD-JWT) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general  <ins> mechanism of selective disclosure defined here. </ins> 1.1.
Original text:
2.7. An entity that entity that requests, checks and extracts the claims <del> from SSD-JWT-R (2.2) </del>  Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the

Reviewer comments:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Revised text:
2.7. An entity that entity that requests, checks and extracts the claims  <ins> from SD-JWT-R (2.2) </ins> Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the
Original text:
The issuer MUST choose a unique salt value for each claim value. Each salt value MUST contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be <del> encoded as a string.  It is RECOMMENDED to base64url encode at least </del>  16 pseudorandom bytes. The issuer MUST build the hashes by hashing over a string that is

Reviewer comments:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Revised text:
The issuer MUST choose a unique salt value for each claim value. Each salt value MUST contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be  <ins> encoded as a string.  It is RECOMMENDED to base64url-encode at least </ins> 16 pseudorandom bytes. The issuer MUST build the hashes by hashing over a string that is
Original text:
values that are contained in the SD-JWT, along with the precise input to the hash calculation, and the salts.  There MAY be other information the issuer needs to communicate to the holder, such as a <del> private key key if the issuer selected the holder key pair. </del>  4.2.1.

Reviewer comments:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Revised text:
values that are contained in the SD-JWT, along with the precise input to the hash calculation, and the salts.  There MAY be other information the issuer needs to communicate to the holder, such as a  <ins> private key if the issuer selected the holder key pair. </ins> 4.2.1.
Original text:
4.3. For transporting the SVC together with the SD-JWT from the issuer to <del> the holder, the SVC is base64ur-encoded and appended to the SD-JWT using </del>  as the separator.  For Example 1, the combined format looks as follows:

Reviewer comments:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Revised text:
4.3. For transporting the SVC together with the SD-JWT from the issuer to  <ins> the holder, the SVC is base64url-encoded and appended to the SD-JWT using a period character </ins> as the separator.  For Example 1, the combined format looks as follows:
Original text:
4.5. The SD-JWT and the SD-JWT-R can be combined into one document using  as a separator (here for Example 1):

Reviewer comments:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Revised text:
4.5. The SD-JWT and the SD-JWT-R can be combined into one document using <ins> period character </ins> as a separator (here for Example 1):
Original text:
10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin, <del> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del>  The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Reviewer comments:
Add Justin to Acknowledgements (he suggested the array for _sd in sid…e meeting) and fix the commas + and in that list of names

Revised text:
10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin,  <ins> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, Justin Richer, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.