jiebi/TextFlow huggingface dataset:
Original text:
I think. <del> 4.1.1.3. </del>  The SD-JWT payload MAY contain other claims and will typically contain other JWT claims, such as

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:
I think.  <ins> 4.1.1.4. </ins> The SD-JWT payload MAY contain other claims and will typically contain other JWT claims, such as
Original text:
5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's <del> private key.  It MUST use a JWS asymmetric digital signature algorithm.  It MUST NOT use </del>  <del> or an identifier for a symmetric algorithm (MAC). </del>  The payload of an SD-JWT is a JSON object according to the following rules:

Reviewer comments:
This addresses Issue . The rest of the text still refers to asymmetric signatures, but technically, an HMAC is now allowed.
The scope of this PR was intentionally to only remove the explicit prohibition on MAC. Not to explain how it might work or adjust other language about asymmetric signatures or private keys or similar. Just remove the explicit prohibition so that, should some deployment/ecosystem/jurisdiction need to MAC for whatever reason, it's not directly going against a normative must.

Revised text:
5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's  <ins> private key.  It MUST NOT use the </ins>  <ins> algorithm. </ins> The payload of an SD-JWT is a JSON object according to the following rules:
Original text:
cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value.  The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in <del> data_formats. </del>  An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.

Reviewer comments:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Revised text:
cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value.  The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in  <ins> data_formats.  When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosures for the claims that it wants to reveal to that Verifier. </ins> An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.
Original text:
For both the General and Flattened JSON Serialization, the SD-JWT is represented as a JSON object according to Section 7.2 of RFC7515. <del> The disclosures (both for issuance and presentation) SHOULD be </del>  included in the serialized JWS using the member name at the top-level of the JSON object (the same level as the

Reviewer comments:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Revised text:
For both the General and Flattened JSON Serialization, the SD-JWT is represented as a JSON object according to Section 7.2 of RFC7515.  <ins> The Disclosures (both for issuance and presentation) SHOULD be </ins> included in the serialized JWS using the member name at the top-level of the JSON object (the same level as the
Original text:
payload, whereas the Holder includes only the Disclosures selected for the given presentation. <del> Alternative methods for conveying the disclosures MAY be used (such </del>  as including them in a member of an outer JSON structure also containing the JSON Serialized

Reviewer comments:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Revised text:
payload, whereas the Holder includes only the Disclosures selected for the given presentation.  <ins> Alternative methods for conveying the Disclosures MAY be used (such </ins> as including them in a member of an outer JSON structure also containing the JSON Serialized
Original text:
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 and the disclosures can be found in the </del>  respective member of the JSON object (or elsewhere). Using a payload similar to that from Example 1 [1], the following is

Reviewer comments:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Revised text:
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 and the Disclosures can be found in the </ins> respective member of the JSON object (or elsewhere). Using a payload similar to that from Example 1 [1], the following is
Original text:
10.3. The security model that conceals the plaintext claims relies on the <del> fact that salts not revealed to an attacker cannot be learned or guessed by the attacker, even if other salts have been revealed.  It is vitally important to adhere to this principle.  As such, each salt MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim independently from other salts.  See Randomness Requirements for </del>  Security RFC4086 for considerations on generating random values. <del> 10.4. </del> The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits.

Reviewer comments:
Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text

Revised text:
10.3. The security model that conceals the plaintext claims relies on the  <ins> high entropy random data of the salt as additional input to the hash function.  The randomness ensures that the same plaintext claim value does not produce the same digest value.  It also makes it infeasible to guess the preimage of the digest (thereby learning the plaintext claim value) by enumerating the potential value space for a claim into the hash function to search for a matching digest value.  It is therefore vitally important that unrevealed salts cannot be learned or guessed, even if other salts have been revealed.  As such, each salt MUST be created in such a manner that it is cryptographically random, sufficiently long, and has high enough entropy that it is infeasible to guess.  A new salt MUST be chosen for each claim independently of other salts.  See Randomness Requirements for </ins> Security RFC4086 for considerations on generating random values.  The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits.
Original text:
appear, but each of them has a different salt. <del> 10.5. </del>  To ensure privacy of claims that are selectively disclosable, but are not being disclosed in a given presentation, the hash function MUST

Reviewer comments:
Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text

Revised text:
appear, but each of them has a different salt.  <ins> 10.4. </ins> To ensure privacy of claims that are selectively disclosable, but are not being disclosed in a given presentation, the hash function MUST
Original text:
Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and MUST NOT be used. <del> 10.6. </del>  Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the legitimate Holder of the credential.  An SD-JWT with

Reviewer comments:
Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text

Revised text:
Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and MUST NOT be used.  <ins> 10.5. </ins> Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the legitimate Holder of the credential.  An SD-JWT with
Original text:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. <del> 10.7. </del>  SD-JWT ensures that names of claims that are selectively disclosable are always blinded.  This prevents an attacker from learning the

Reviewer comments:
Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text

Revised text:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification.  <ins> 10.6. </ins> SD-JWT ensures that names of claims that are selectively disclosable are always blinded.  This prevents an attacker from learning the
Original text:
claims.  This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT. <del> 10.8. </del>  An Issuer MUST NOT allow any content to be selectively disclosable that is critical for evaluating the SD-JWT's authenticity or

Reviewer comments:
Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text

Revised text:
claims.  This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT.  <ins> 10.7. </ins> An Issuer MUST NOT allow any content to be selectively disclosable that is critical for evaluating the SD-JWT's authenticity or