jiebi/TextFlow huggingface dataset:
Original text:
Disclosure as described in creating_disclosures.  The Issuer includes a Disclosure for each selectively disclosable claim of the SD-JWT payload, whereas the Holder includes only the Disclosures selected <del> for the given presentation.  Additionally, for presentation with a Key Binding, the Holder adds the key </del>  <del> at the top-level of the serialized JWS with a string value containing the Key Binding JWT as described in kb-jwt. </del>  Verification of the JWS JSON serialized SD-JWT follows the same rules defined in verification, except that the SD-JWT does not need to be <del> split into component parts, but disclosures and (if applicable) a Key Binding JWT can be found in the respective members of the JSON object. </del>  Using a payload similar to that from Example 1 [2], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. Below is a non-normative example of a presentation of the JWS JSON <del> serialized SD-JWT, where the Holder includes a Key Binding JWT and has selected to disclose </del>  ,

Reviewer comments:
-Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses

Revised text:
Disclosure as described in creating_disclosures.  The Issuer includes a Disclosure for each selectively disclosable claim of the SD-JWT payload, whereas the Holder includes only the Disclosures selected  <ins> for the given presentation. Alternative methods for conveying the disclosures MAY be used (such as including them in a </ins>  <ins> member of an outer JSON structure also containing the JSON Serialized SD-JWT) as dictated by a specific application or transport protocol. However, the details of such approaches fall outside the scope of this specification. </ins> Verification of the JWS JSON serialized SD-JWT follows the same rules defined in verification, except that the SD-JWT does not need to be  <ins> split into component parts, the disclosures can be found in the respective member of the JSON object (or elsewhere), and Key Binding (if applicable) will be provided by means not specifically defined in this specification. </ins> Using a payload similar to that from Example 1 [2], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. Below is a non-normative example of a presentation of the JWS JSON  <ins> serialized SD-JWT, where the Holder has selected to disclose </ins> ,
Original text:
.  9. Security considerations in this section help achieve the following

Reviewer comments:
-Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses

Revised text:
. <ins> 8. In some applications or transport protocols, it is desirable to encapsulate an SD-JWT into an outer JWT container.  For example, an implementation may enclose multiple credentials and presentations, independent of their format, in a JWT to enable application-layer encryption during transport. For such use cases, a compact serialized SD-JWT SHOULD be included as a single string value and a JSON serialized SD-JWT SHOULD be included as a JSON object value.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT. The following non-normative example payload shows a compact serialized SD-JWT Presentation enveloped in a JWT.  The SD-JWT is shown as the value of an claim where is the Issuer-signed JWT and is a Disclosure.  The SD-JWT does not contain a Key Binding JWT as the outer container can be signed instead. This next non-normative example payload shows a JSON serialized SD- JWT enveloped in a JWT.  The JSON serialized SD-JWT appears as the value of an claim and the disclosures are included separately as a top-level claim.  Key Binding is achieved by the signature on the enclosing JWT. Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple such SD-JWTs into one object and provide Key Binding using means other than the Key Binding JWT. </ins> 9. Security considerations in this section help achieve the following
Original text:
12. <del> TBD </del> 12.1.  This section requests registration of the "application/sd-jwt" media type RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Reviewer comments:
Added JWT claims registration requests to IANA (to fix issue ) URL
This was meant as a placeholder/reminder for JWT Claims Registration requests to IANA that would be needed eventually. The and claims should be registered. I'm not sure about to be honest, which is ironic b/c I'm supposed to know about such things (see the so-called experts ). But it's somewhat different than the other claims in the registry. But, I dunno, requesting registration is probably the way to go w/ .
I share your unsureness, and agree that requesting registration is the way to go. btw in the spec, we have a text registered claim, so if we decide not to register it, that text needs to be updated.
Wait... really, where?
PR has been merged.

Revised text:
12.  12.1. <ins> This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry IANA.JWT established by RFC7519. 12.2. </ins> This section requests registration of the "application/sd-jwt" media type RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.
Original text:
To indicate that the content is a Key Binding JWT: <del> 12.2. </del>  This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry

Reviewer comments:
Added JWT claims registration requests to IANA (to fix issue ) URL
This was meant as a placeholder/reminder for JWT Claims Registration requests to IANA that would be needed eventually. The and claims should be registered. I'm not sure about to be honest, which is ironic b/c I'm supposed to know about such things (see the so-called experts ). But it's somewhat different than the other claims in the registry. But, I dunno, requesting registration is probably the way to go w/ .
I share your unsureness, and agree that requesting registration is the way to go. btw in the spec, we have a text registered claim, so if we decide not to register it, that text needs to be updated.
Wait... really, where?
PR has been merged.

Revised text:
To indicate that the content is a Key Binding JWT:  <ins> 12.3. </ins> This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry
Original text:
non-selectively disclosable and hide only the other sub-claims: <del> There would be no Disclosure for </del>  <del> in this case. </del>  5.7.3.

Reviewer comments:
based roughly on feedback from Anders to draft-ietf-oauth-selective-disclosure-jwt at URL

Revised text:
non-selectively disclosable and hide only the other sub-claims:  <ins> In this case there would be no Disclosure for </ins>  <ins> since it is provided in the clear. </ins> 5.7.3.
Original text:
11. <del> We would like to thank Alen Horvat, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer 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:
based roughly on feedback from Anders to draft-ietf-oauth-selective-disclosure-jwt at URL

Revised text:
11.  <ins> We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer 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:
An SD-JWT is composed of the following: <del> The individual parts will be explained in the following subsections. </del>  The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows: <del> The order of the tilde separated values MUST be the Issuer-signed JWT, followed by any number of Disclosures, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </del>  The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.

Reviewer comments:
to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!

Revised text:
An SD-JWT is composed of the following:  <ins> The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in iss-signed-jwt, creating_disclosures, and kb-jwt respectively. </ins> The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows:  <ins> The order of the concatenated parts MUST be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </ins> The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.
Original text:
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send <del> Disclosures or reveal the salt values in any other way. </del>  <del> A Holder MUST NOT send a Disclosure that was not included in the SD- JWT or send a Disclosure more than once. </del>  5.1.

Reviewer comments:
to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!

Revised text:
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send  <ins> Disclosures or reveal the salt values in any other way.  A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. </ins>  <ins> To further illustrate the SD-JWT format, the following example shows a few different SD-JWT permutations, both with and without various constituent parts. </ins> 5.1.
Original text:
Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat <del> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer 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:
to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!

Revised text:
Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat  <ins> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer 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:
An SD-JWT is composed of the following: <del> The individual parts will be explained in the following subsections. </del>  The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows: <del> The order of the tilde separated values MUST be the Issuer-signed JWT, followed by any number of Disclosures, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </del>  The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.

Reviewer comments:
In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.

Revised text:
An SD-JWT is composed of the following:  <ins> The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in iss-signed-jwt, creating_disclosures, and kb-jwt respectively. </ins> The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows:  <ins> The order of the concatenated parts MUST be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </ins> The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.
Original text:
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send <del> Disclosures or reveal the salt values in any other way. </del>  <del> A Holder MUST NOT send a Disclosure that was not included in the SD- JWT or send a Disclosure more than once. </del>  5.1.

Reviewer comments:
In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.

Revised text:
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send  <ins> Disclosures or reveal the salt values in any other way.  A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. </ins>  <ins> To further illustrate the SD-JWT format, the following example shows a few different SD-JWT permutations, both with and without various constituent parts. </ins> 5.1.
Original text:
Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat <del> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer 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:
In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.

Revised text:
Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat  <ins> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer 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:
4.1.1.2.  If the issuer wants to enable holder binding, it includes a public key associated with the holder, or a reference thereto.

Reviewer comments:
adding SD-JWT claim Note: need to update the examples to include it once we agree this claim is needed (cc NAME )
We need to say in the checking algorithm that verifiers MUST check the alg and MUST only accept hash_algs they understand and deem secure.
information about the hash function should probably be included inside SD-JWT. Based on NAME 's comment to the PR URL
Yes, needed indeed. This and more details about hash formatting (how to transform inputs into byte arrays to be passed to the hash function).
The alternative is to use the same hash function as was used for the signature. This is done in OpenID Connect Core at URL in the definition (as well as in the definition. The language is:
You might want to use a different hash function to reduce the SD-JWT size (e.g., SHA-256 truncated to 128 bit), or decide on a stronger hash function with iteration to reduce the size of the salt (again, to minimize the size of the artefact). Bottom line, choosing the hash function independently might be useful.
As discussed in the call, if we allow different hashes to be used, we may want to make a recommendation that for simplicity an implementor may want to use the same hash algorithm to minimise implementation errors.
Assuming we're not going to use the trick that OpenID Connect uses to determine the hash algorithm implicitly, then I approve of this approach.

Revised text:
4.1.1.2. <ins> 4.1.1.3. </ins> If the issuer wants to enable holder binding, it includes a public key associated with the holder, or a reference thereto.