jiebi/TextFlow huggingface dataset:
Original text:
In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding.  9. The privacy principles of ISO.29100 should be adhered to.

Reviewer comments:
Thanks, editorial comments taken.
Whether this format is JWT or JWT-like, the considerations in the still apply. Please consider adding a claim. cc NAME
Explicit typing via the header can and should be done by specific applications or types of SD-JWT. But this SD-JWT draft is defining the general JWT-like construct and explicit typing of the generic thing isn't particularly useful or meaningful.
The The next draft will have a media type and structured suffix that can help with specific applications or types of SD-JWT doing explicit typing FWIW URL
I would be open to adding one sentence in the draft saying "applications of SD-JWT SHOULD be explicitly typed". I agree there cannot be only one type for all SD-JWTs.
I'm not quite sure where to add that one sentence. And a bit more context might be needed with it. I'll see what I can figure out. Maybe a small section like 3.11 in rfc8725. But (helpful) suggestions/ideas would be welcome in the meantime.
Add this sentence at the end of 5.1: The header parameter is RECOMMENDED, see Sec. 5.1.4 for more details. And as a new Sec. 5.1.4, "Explicit Typing": A commonly seen attack is for one kind of JWT to be confused for another. Both regular JWTs as well as SD-JWTs are vulnerable to confusion attacks. To prevent these attacks, it is RECOMMENDED to specify an explicit type by including the header parameter when the token is issued, and for Verifiers to check this value. The relevant token's content type can be used, e.g. , but often a more application-specific value is preferred. See Sec. 3.11 of RFC 8725 for more details.
Thanks NAME I took some inspiration from you words in creating PR .
merged PR to close this one
Thanks for preparing this! LGTM, just two small editorial comments.

Revised text:
In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding. <ins> 8.10. Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the header parameter when the SD-JWT is issued, and for Verifiers to check this value. When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.  The definition of in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter. </ins> 9. The privacy principles of ISO.29100 should be adhered to.
Original text:
<del> Selective Disclosure for JWTs (SD-JWT) </del>  draft-ietf-oauth-selective-disclosure-jwt-latest Abstract <del> This document specifies conventions for creating JSON Web Token (JWT) documents that support selective disclosure of JWT claims. </del>  1. <del> The JSON-based RFC8259 representation of claims in a signed JSON Web Token (JWT) RFC7519 is secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </del>  contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all the claims.  Likewise, anyone with the decryption key receiving encrypted JWT can also read

Reviewer comments:
Honestly, I'm not sure about this one. But I said I'd put together a PR for with an update to the title and some qualifying text. So this is that PR as something to discuss anyway. At least these few sentences took me an embarrassingly long time to write :/

Revised text:
 <ins> SD-JWT: Selective Disclosure for JWT and JWS with JSON payloads </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract  <ins> This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure.  It encompasses various applications, including but not limited to the selective disclosure of JSON Web Tokens (JWT) claims. </ins> 1.  <ins> This document specifies conventions for creating JSON Web Signature (JWS) RFC7515 structures with JSON RFC8259 objects as the payload while supporting selective disclosure of individual elements of that JSON.  Because JSON Web Token (JWT) RFC7519 is a very prevalent application of JWS with a JSON payload, the selective disclosure of JWT claims receives primary treatment herein.  However, that does not preclude the mechanism's applicability to other or more general applications of JWS with JSON payloads. The JSON-based representation of claims in a signed JWT is secured against modification using JWS digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </ins> contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all the claims.  Likewise, anyone with the decryption key receiving encrypted JWT can also read
Original text:
, which are unfit for security applications). <del> Furthermore, the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. </del>  8.6.

Reviewer comments:
RIPEMD-160 is usable, but not its predecessors. For this reason this PR removes RIPEMD-160 from the list of the weak algs by saying that only -160 predecessors must not be used.
Thank you!

Revised text:
, which are unfit for security applications).  <ins> Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. </ins> 8.6.
Original text:
The claim indicates the hash algorithm used by the Issuer to generate the <del> digests over the salts and the claim values.  If the </del>  <del> claim is not present, a default value of </del>  <del> is used. </del>  The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash

Reviewer comments:
Text looks good but it's going to clash with the array spec work URL
It's a small change, we can sort that out when merging either.
Now that is allowed at multiple locations in the JSON document, including recursively, I would expect Sec. 5.1.2 to define explicitly where the claim should appear. Once at the top of the document? Can it also appear alongside claims located deeper in the document? Also, please change the section heading from "hash function" to "hash algorithm", for consistency.
Thank you! The intention is that there is only one at the top level. We will clarify.
Concur with NAME
+1

Revised text:
The claim indicates the hash algorithm used by the Issuer to generate the  <ins> digests.  When used, this claim MUST appear at the top level of the SD-JWT payload.  It MUST NOT be used in any object nested within the payload.  If the </ins>  <ins> claim is not present at the top level, a default value of </ins>  <ins> MUST be used. </ins> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash
Original text:
<del> SD-JWT: Selective Disclosure for JWT and JWS with JSON payloads </del>  draft-ietf-oauth-selective-disclosure-jwt-latest Abstract

Reviewer comments:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Revised text:
 <ins> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract
Original text:
the transaction at hand.  SD-JWTs defined in this document enable such selective disclosure of JWT claims. <del> One example of a multi-use JWT is a verifiable credential, an issuer- </del>  signed credential that contains the claims about a subject, and whose authenticity can be cryptographically verified.

Reviewer comments:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Revised text:
the transaction at hand.  SD-JWTs defined in this document enable such selective disclosure of JWT claims.  <ins> One example of a multi-use JWT is a verifiable credential, an Issuer- </ins> signed credential that contains the claims about a subject, and whose authenticity can be cryptographically verified.
Original text:
6.1. <del> The Holder MUST perform the following (or equivalent) steps when receiving a Combined Format for Issuance: </del>  It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed.  For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: <del> 6.2. </del>  <del> Upon receiving a Presentation, Verifiers MUST ensure that </del>  To this end, Verifiers MUST follow the following steps (or equivalent):

Reviewer comments:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Revised text:
6.1.  <ins> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT: If any step fails, the SD-JWT is not valid and processing MUST be aborted. </ins> It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed. <ins> 6.2. If a Key Binding JWT is received by a Holder, the SD-JWT SHOULD be rejected. </ins> For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps:  <ins> 6.3. </ins>  <ins> Upon receiving a Presentation, in addition to the checks outlined in sd_jwt_verification, Verifiers MUST ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):
Original text:
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, <del> Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, 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:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Revised text:
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,  <ins> Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, 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:
<del> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </del>  draft-ietf-oauth-selective-disclosure-jwt-latest Abstract

Reviewer comments:
This solves Issue by moving away from an example that wasn't ideal anyway (it encoded a different bytestring for the value Möbius). The Disclosure JSON should be:
"it shows as is there any way to change that..? (this is not the change introduced in this PR)" on the text in the doc at URL "A different way to encode the umlaut (two dots &; placed over the letter):" Originally posted by NAME in URL
Not sure why this broke now. I created a PR because the example wasn't ideal anyway: URL
I just noticed that the PR does not fully solve the problem. We have the same problem somewhere else as well: !
it's seems to have been an issue at least back to -01 URL and/or -02 URL (so basically since inception). I'm sure we could fight with the tool chain to fix it. But at what cost? I'm inclined to just reword that "The two representations... " part to make the issue go away. Which I did with this 48efde35a81ca3520eb30ceea6c43d62e8cd96f8 update to URL
PR merged

Revised text:
 <ins> Selective Disclosure for JWTs (SD-JWT) </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract
Original text:
The resulting Disclosure would be: <del> Note that the JSON encoding of the object is not canonicalized, so variations in white space, encoding of Unicode characters, and ordering of object properties are allowed.  For example, the following strings are all valid and encode the same claim value "Moebius": </del>  See disclosure_format_considerations for some further considerations on the Disclosure format approach.

Reviewer comments:
This solves Issue by moving away from an example that wasn't ideal anyway (it encoded a different bytestring for the value Möbius). The Disclosure JSON should be:
"it shows as is there any way to change that..? (this is not the change introduced in this PR)" on the text in the doc at URL "A different way to encode the umlaut (two dots &; placed over the letter):" Originally posted by NAME in URL
Not sure why this broke now. I created a PR because the example wasn't ideal anyway: URL
I just noticed that the PR does not fully solve the problem. We have the same problem somewhere else as well: !
it's seems to have been an issue at least back to -01 URL and/or -02 URL (so basically since inception). I'm sure we could fight with the tool chain to fix it. But at what cost? I'm inclined to just reword that "The two representations... " part to make the issue go away. Which I did with this 48efde35a81ca3520eb30ceea6c43d62e8cd96f8 update to URL
PR merged

Revised text:
The resulting Disclosure would be:  <ins> Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed in the JSON representation and no canonicalization needs be performed before base64url-encoding.  For example, the following strings are all valid and encode the same claim value "Moebius": </ins> See disclosure_format_considerations for some further considerations on the Disclosure format approach.
Original text:
<del> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </del>  draft-ietf-oauth-selective-disclosure-jwt-latest Abstract

Reviewer comments:
I've seen the "new" title from 332ded8faf20d528c5c05e04cebed28aab1a0d33 a few times in context now and it is really awkward.
yup, that updated intro and abstract text stays
as long as the intro text itself stays as we updated it, this makes sense to me.

Revised text:
 <ins> Selective Disclosure for JWTs (SD-JWT) </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract
Original text:
string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT. <del> The claim SHOULD be used when transporting an SD-JWT unless the application or protocol defines a different claim name. </del> The following non-normative example shows an SD-JWT Presentation enveloped in a JWT payload: <del> Here, the SD-JWT is shown where </del>  represents the Issuer-signed JWT and

Reviewer comments:
I noticed that the consolidation of SD-JWT terminology in c6a27373dee13cc7c3f70a8b7fd374e62306f5a0 introduced a mistake in the "Enveloping" section title by including the word "Presentation" while the section talks about enveloping either issued or presented SD-JWTs. While fixing that, I decided to remove the SHOULD recommending the use of an unregistered claim name . I also tried to align the example enveloping payload a bit with a move minimal set of claims similar to those used in key binding. I realize I probably should have just fixed the section title and not expanded the scope of the changes. But there I was and these few little changes were so inviting... See it here: URL

Revised text:
string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT.  The following non-normative example shows an SD-JWT Presentation enveloped in a JWT payload:  <ins> Here, the SD-JWT is shown as the value of an claim where </ins> represents the Issuer-signed JWT and
Original text:
5.5. <del> This example uses the following object as the set of claims that the Issuer is issuing: </del>  <del> The following non-normative example shows a payload of an SD-JWT for this End-User data: </del>  The Issuer in this case made the following decisions: <del> The Issuer creates the following Disclosures: </del>  The payload is then signed by the Issuer to create a JWT like the following:

Reviewer comments:
update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative

Revised text:
5.5.  <ins> In this example, a simple SD-JWT is demonstrated. </ins>  <ins> The Issuer is using the following input claim set: </ins> The Issuer in this case made the following decisions:  <ins> The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: </ins> The payload is then signed by the Issuer to create a JWT like the following: