jiebi/TextFlow huggingface dataset:
Original text:
must contain information about key material controlled by the holder: Note: How the public key is included in SD-JWT is out of scope of <del> this document.  It can be passed by value or by reference.  Examples in this document use Claim to include raw public key by value in SD-JWT. </del>  With holder binding, the

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
must contain information about key material controlled by the holder: Note: How the public key is included in SD-JWT is out of scope of  <ins> this document.  It can be passed by value or by reference. </ins> With holder binding, the
Original text:
4.4.  A verifier checks that The detailed algorithm is described below.

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
4.4. <ins> If claim name blinding is used, is created as follows: is a placeholder used instead of the original claim name, chosen such that it does not leak information about the claim name (e.g., randomly). The contents of are modified as follows: Note that blinded and unblinded claim names can be mixed in and accordingly in . 4.5. </ins> A verifier checks that The detailed algorithm is described below.
Original text:
guess.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. <del> The issuer MUST build the digests by hashing over a string that is formed by JSON-encoding an ordered array containing the salt and the claim value, e.g.: </del>  <del> . The digest value is then base64url-encoded.  Note that the precise JSON encoding can vary, and therefore, the JSON encodings MUST be sent to the holder along with the SD-JWT, as described below. </del>  5.1.1.1.

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
guess.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value.  <ins> The issuer MUST build the digests by hashing over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following contents: The following is an example for a JSON literal without claim name blinding: </ins>  <ins> The following is an example for a JSON literal with claim name blinding: IMPORTANT: JSON encoding according to RFC8259 allows for white space characters and other variations in the encoded representation.  To ensure that issuer and verifier produce the same hash digest, the issuer therefore sends the JSON literal to the holder along with the SD-JWT, as described below. The claim contains an object where claim names are mapped to the respective digests.  If a claim name is to be blinded, the digests MUST contain the key as described above and the claim name in MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the SVC and SD-JWT-R described below. </ins> 5.1.1.1.
Original text:
pair to the issuer, the issuer MAY create the key pair for the holder, or holder and issuer MAY use pre-established key material. <del> Note: need to define how holder public key is included, right now examples are using </del>  <del> I think. </del>  5.2.

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
pair to the issuer, the issuer MAY create the key pair for the holder, or holder and issuer MAY use pre-established key material.  <ins> Note: Examples in this document use </ins>  <ins> Claim defined in RFC7800 to include raw public key by value in SD- JWT. </ins> 5.2.
Original text:
The SVC for Example 1 is as follows: Important: As described above, hash digests are calculated over the <del> string formed by serializing a JSON array containing the salt and the claim value.  This ensures that issuer and verifier use the same input to their hash functions and avoids issues with canonicalization of JSON values that would lead to different hash digests.  The SVC therefore maps claim names to JSON-encoded arrays. </del>  5.5.

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
The SVC for Example 1 is as follows: Important: As described above, hash digests are calculated over the  <ins> JSON literal formed by serializing an object containing the salt, the claim value, and optionally the claim name.  This ensures that issuer and verifier use the same input to their hash functions and avoids issues with canonicalization of JSON values that would lead to different hash digests.  The SVC therefore maps claim names to JSON- encoded arrays. </ins> 5.5.
Original text:
The following is a non-normative example of the contents of an SD- JWT-R for Example 1: <del> For each claim, an array of the salt and the claim value is contained in the </del>  object.

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
The following is a non-normative example of the contents of an SD- JWT-R for Example 1:  <ins> For each claim, a JSON literal that decodes to an object with the and the claim value (plus optionally the claim name) is contained in the </ins> object.
Original text:
TBD  8. 8.1. <del> Claim names are not hashed in the SD-JWT and are used as keys in a key-value pair, where the value is the hash.  This is because SD-JWT already reveals information about the issuer and the schema, and revealing the claim names does not provide any additional information. </del>  8.2.

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
TBD <ins> 7.7. Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim names accordingly.  It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded claim name to the verifier.  It is therefore RECOMMENDED to ensure that the order is shuffled or otherwise hidden (e.g., alphabetically ordered using the blinded claim names). </ins> 8. 8.1.  <ins> By default, claim names are not blinded in an SD-JWT.  In this case, even when the claim's value is not known to a verifier, the claim name can disclose some information to the verifier.  For example, if the SD-JWT contains a claim named , the verifier might assume that the end-user is a member of the Super Secret Club. Blinding claim names can help to avoid this potential privacy issue. In many cases, however, verifiers can already deduce this or similar information just from the identification of the issuer and the schema used for the SD-JWT.  Blinding claim names might not provide additional privacy if this is the case. </ins> 8.2.
Original text:
<del> Selective Disclosure JWT (SD-JWT) </del>  draft-fett-oauth-selective-disclosure-jwt-02 Abstract

Reviewer comments:
PR for URL
Done, and also cleaned up the intro slightly (repeating 'document' is superfluous there).

Revised text:
 <ins> Selective Disclosure for JWTs (SD-JWT) </ins> draft-fett-oauth-selective-disclosure-jwt-02 Abstract
Original text:
1. <del> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </del>  This document describes a format for signed JWTs that supports selective disclosure (SD-JWT), enabling sharing only a subset of the

Reviewer comments:
PR for URL
Done, and also cleaned up the intro slightly (repeating 'document' is superfluous there).

Revised text:
1.  <ins> The JSON-based 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 contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> This document describes a format for signed JWTs that supports selective disclosure (SD-JWT), enabling sharing only a subset of the
Original text:
4.1. An SD-JWT, at its core, is a digitally signed document containing <del> hash digests over the claim values with unique random salts and other </del>  metadata.  It MUST be digitally signed using the issuer's private key. <del> can be a simple object with claim names mapped to hash digests over the claim values with unique random salts: </del>  The claim name (

Reviewer comments:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Revised text:
4.1. An SD-JWT, at its core, is a digitally signed document containing  <ins> hash digests over the claim values with random salts and other </ins> metadata.  It MUST be digitally signed using the issuer's private key.  <ins> is an object with claim names mapped to the digests over the claim values with random salts calculated using digest derivation function such as hash function, HMAC, or other: </ins> The claim name (
Original text:
. <del> The issuer MUST choose a unique and cryptographically random salt value for each claim value.  Each salt value SHOULD contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be encoded as a string.  It is </del>  RECOMMENDED to base64url-encode the salt value. The issuer MUST build the digests by hashing over a JSON literal

Reviewer comments:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Revised text:
.  <ins> The issuer MUST choose a cryptographically random salt value for each claim value.  The salt value MUST then be encoded as a string.  It is </ins> RECOMMENDED to base64url-encode the salt value. The issuer MUST build the digests by hashing over a JSON literal
Original text:
The claim <del> indicates the hash algorithm used by the Issuer to generate the hashes of the salted claim values.  The hash algorithm identifier MUST be a value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry [IANA.Hash.Algorithms].  SD-JWTs with hash algorithm identifiers not found in this registry are not considered valid and MUST NOT be accepted by verifiers. </del>  To promote interoperability, implementations MUST support the SHA-256 <del> hash algorithm. </del>  5.1.3.

Reviewer comments:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Revised text:
The claim  <ins> indicates the hash algorithm function used by the Issuer to generate the hashes over the random values and the claim values. The hash algorithm identifier MUST be a value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry [IANA.Hash.Algorithms] or HMAC algorithms in "Algorithmn Name" column in the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA.JWS.Algorithms]. </ins> To promote interoperability, implementations MUST support the SHA-256  <ins> hash algorithm.  Other specifications and/or profiles of this specification may register additional algorithm identifiers. See security_considerations for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash function. </ins> 5.1.3.
Original text:
guessed by the attacker.  It is vitally important to adhere to this principle.  As such, the salt MUST be created in such a manner that it is cryptographically random, long enough and has high entropy that <del> it is not practical for the attacker to guess.  Each salt value MUST be unique. </del>  7.4. <del> The length of the randomly-generated portion of the salt MUST be at least 128 bits. </del>  7.5.

Reviewer comments:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Revised text:
guessed by the attacker.  It is vitally important to adhere to this principle.  As such, the salt MUST be created in such a manner that it is cryptographically random, long enough and has high entropy that  <ins> it is not practical for the attacker to guess.  A new random value MUST be chosen for each claim. </ins> 7.4.  <ins> The RECOMMENDED length of the randomly-generated portion of the salt is at least 128 bits. </ins> 7.5.
Original text:
Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim <del> names accordingly.  It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. </del>  The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded

Reviewer comments:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Revised text:
Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim  <ins> names accordingly. It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. </ins> The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded
Original text:
2.  Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the actor. <del> Note: noneed to define </del>  anymore?

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:
2. <ins> 2.1. A JWT RFC7515 created by the issuer, which can be signed as a JWS RFC7515, that supports selective disclosure as defined in this document. 2.2. A JSON object created by the issuer that contains mapping between raw claim values that contained in the SD-JWT and the salts for each claim value. 2.3. A JWT created by the holder that contains a subset of the claim values of an SD-JWT in a verifiable way. 2.4. Ability of the holder to prove legitimate possession of SD-JWT by proving control over the same private key during the issuance and presentation.  SD-JWT signed by the issuer contains a public key or a reference to a public key that matches to the private key controlled by the holder. 2.5. An entity that creates SD-JWTs (2.1). 2.6. An entity that received SD-JWTs (2.1) from the issuer and has control over them. 2.7. An entity that entity that requests, checks and extracts the claims from SSD-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 actor.  <ins> Note: no need to define </ins> anymore?
Original text:
3.2. <del> To release to a verifier a subset of SD-JWT claim values, a holder </del>  creates a JWS such as the following: Note that the signature over

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:
3.2.  <ins> To SD-JWT-R to a verifier a subset of SD-JWT claim values, a holder </ins> creates a JWS such as the following: Note that the signature over
Original text:
can be more complex as well. <del> The Release is sent together with the SD-JWT from the holder to the </del>  verifier. 3.3.

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:
can be more complex as well.  <ins> The SD-JWT-R is sent together with the SD-JWT from the holder to the </ins> verifier. 3.3.