jiebi/TextFlow huggingface dataset:
Original text:
8.7.  Verifiers MUST decide whether Holder Binding is required for a particular use case or not before verifying a credential.  This decision can be informed by various factors including, but not

Reviewer comments:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Revised text:
8.7. <ins> Holder binding aims to ensure that the presenter of a credential is actually the legitimate Holder of the credential.  There are, in general, two approaches to Holder Binding: Claims-based Holder Binding and Crpytographic Holder Binding. Claims-based Holder Binding means that the Issuer includes claims in the SD-JWT that a Verifier can correlate with the Holder, potentially with the help of other credentials presented at the same time.  For example, in a vaccination certificate, the Issuer can include a claim that contains the Holder's name and birthdate, and a Verifier can correlate this data with the Holder's passport that has to be presented together with the vaccination certificate - either as a digital credential or a physical document. Cryptographic Holder Binding means that the Issuer includes some cryptographic data, usually a public key, belonging to the Holder. The Holder can then sign over some data defined by the Verifier to prove that the Holder is in possession of the private key. Without Holder Binding, a Verifier only gets the proof that the credential was issued by a particular Issuer, but the credential itself can be replayed by anyone who gets access to it.  This means that, for example, after a credential was leaked to an attacker, the attacker can present the credential to any verifier that does not require Holder Binding.  But also a malicious Verifier to which the Holder presented the credential can present the credential to another Verifier if that other Verifier does not require Holder Binding. </ins> Verifiers MUST decide whether Holder Binding is required for a particular use case or not before verifying a credential.  This decision can be informed by various factors including, but not
Original text:
is the actual Holder of the license.  The Verifier (e.g., the software used by the police officer) will ensure that a Holder Binding JWT is present and signed with the Holder's private key.  A rental car agency may want to ensure, for insurance purposes, that all drivers named on the rental contract own a government-issued

Reviewer comments:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Revised text:
is the actual Holder of the license.  The Verifier (e.g., the software used by the police officer) will ensure that a Holder Binding JWT is present and signed with the Holder's private key. <ins> Claims-based Holder Binding may be used as well, e.g., by including a first name, last name and a date of birth that matches that of an insurance policy paper. </ins> A rental car agency may want to ensure, for insurance purposes, that all drivers named on the rental contract own a government-issued
Original text:
If a Verifier has decided that Holder Binding is required for a particular use case and the Holder Binding is not present, does not fulfill the requirements (e.g., on the signing algorithm), or no <del> recognized key reference is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. </del>  8.8.

Reviewer comments:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Revised text:
If a Verifier has decided that Holder Binding is required for a particular use case and the Holder Binding is not present, does not fulfill the requirements (e.g., on the signing algorithm), or no  <ins> recognized Holder Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. </ins> 8.8.
Original text:
Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. <del> 9.2. </del>  The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing

Reviewer comments:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Revised text:
Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel.  <ins> 9.3. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing
Original text:
digests (or whether to use them at all) is a trade-off between the size of the SD-JWT and the privacy of the End-User's data. <del> 9.3. </del>  Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user

Reviewer comments:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Revised text:
digests (or whether to use them at all) is a trade-off between the size of the SD-JWT and the privacy of the End-User's data.  <ins> 9.4. </ins> Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user
Original text:
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 <del> receiving an unencrypted JWT can read all of the claims and likewise, </del>  anyone with the decryption key receiving an encrypted JWT can also <del> read all of the claims. </del>  One of the common use cases of a signed JWT is representing a user's identity.  As long as the signed JWT is one-time use, it typically

Reviewer comments:
for add a bit more context/background to the intro about the indented general applicability of SD-JWT and the relation to JWT and the OAuth WG

Revised text:
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  <ins> receiving an unencrypted JWT can read all the claims and likewise, </ins> anyone with the decryption key receiving an encrypted JWT can also  <ins> read all the claims. </ins> One of the common use cases of a signed JWT is representing a user's identity.  As long as the signed JWT is one-time use, it typically
Original text:
The ability to selectively disclose a subset of these claims depending on the Verifier becomes crucial to ensure minimum disclosure and prevent Verifiers from obtaining claims irrelevant for <del> the transaction at hand. One example of such a multi-use JWT is a verifiable credential, a tamper-evident credential with a cryptographically verifiable authorship that contains claims about a subject.  SD-JWTs defined in this document enable such selective disclosure of claims. </del>  In an SD-JWT, claims can be hidden, but cryptographically protected against undetected modification.  When issuing the SD-JWT to the

Reviewer comments:
for add a bit more context/background to the intro about the indented general applicability of SD-JWT and the relation to JWT and the OAuth WG

Revised text:
The ability to selectively disclose a subset of these claims depending on the Verifier becomes crucial to ensure minimum disclosure and prevent Verifiers from obtaining claims irrelevant for  <ins> the transaction at hand.  One example of such a multi-use JWT is a verifiable credential, a tamper-evident credential with a cryptographically verifiable authorship that contains claims about a subject. SD-JWTs defined in this document enable such selective disclosure of JWT claims. Similar to the JWT specification on which it builds, this document is a product of the Web Authorization Protocol (oauth) working group. However, while both JWT and SD-JWT have potential OAuth 2.0 applications, their utility and application is certainly not constrained to OAuth 2.0.  JWT was developed as a general-purpose token format and has seen widespread usage in a variety of applications.  SD-JWT is a selective disclosure mechanism for JWT and is similarly intended to be general-purpose specification. </ins> In an SD-JWT, claims can be hidden, but cryptographically protected against undetected modification.  When issuing the SD-JWT to the
Original text:
The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash <del> Algorithm" registry IANA.Hash.Algorithms. </del>  To promote interoperability, implementations MUST support the SHA-256 hash algorithm.

Reviewer comments:
A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL

Revised text:
The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash  <ins> Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the SHA-256 hash algorithm.
Original text:
8.6. For the security of this scheme, the hash algorithm is required to be <del> preimage and collision resistant, i.e., it is infeasible to calculate the salt and claim value that result in a particular digest, and it is infeasible to find a different salt and claim value pair that result in a matching digest, respectively. </del>  <del> Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 </del>  revealed fundamental weaknesses and they MUST NOT be used. 8.7.

Reviewer comments:
A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL

Revised text:
8.6. For the security of this scheme, the hash algorithm is required to be  <ins> preimage resistant and second-preimage resistant, i.e., it is infeasible to calculate the salt and claim value that result in a particular digest, and, for any salt and claim value pair, it is infeasible to find a different salt and claim value pair that result in the same digest, respectively. Hash algorithms that do not meet the aforementioned requirements MUST NOT be used.  Inclusion in the "Named Information Hash Algorithm" registry IANA.Hash.Algorithms alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several heavily truncated digests, such as </ins>  <ins> and , which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 </ins> revealed fundamental weaknesses and they MUST NOT be used. 8.7.
Original text:
This document describes a format for JWTs that support selective disclosure (SD-JWT), enabling sharing only a subset of the claims included in the original JWT instead of releasing all the claims to <del> every verifier.  This document also defines a format for so-called SD-JWT Releases (SD-JWT-R). </del>  One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such a use case, there has been no

Reviewer comments:
Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.

Revised text:
This document describes a format for JWTs that support selective disclosure (SD-JWT), enabling sharing only a subset of the claims included in the original JWT instead of releasing all the claims to  <ins> every verifier.  During issuance, an SD-JWT is sent from the issuer to the holder alongside an SD-JWT Salt/Value Container (SVC), a JSON object that contains the mapping between raw claim values contained in the SD-JWT and the salts for each claim value. This document also defines a format for SD-JWT Releases (SD-JWT-R), which conveys a subset of the claim values of an SD-JWT that the holder is selectively releasing to the verifier.  During presentation, SD-JWT-R and SD-JWT are both sent to the verifier from the holder.  To verify claim values received in SD-JWT-R, verifier uses salts in SD-JWT-R to compute the hashes of the claim values and compare them to the hashes in SD-JWT. </ins> One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such a use case, there has been no
Original text:
2.2. A JSON object created by the issuer that contains mapping between raw <del> claim values that contained in the SD-JWT and the salts for each claim value. </del>  2.3.

Reviewer comments:
Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.

Revised text:
2.2. A JSON object created by the issuer that contains mapping between raw  <ins> claim values contained in the SD-JWT and the salts for each claim value. </ins> 2.3.
Original text:
2.7. <del> An entity that entity that requests, checks and extracts the claims from SD-JWT-R (2.2) </del>  Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the

Reviewer comments:
Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.

Revised text:
2.7.  <ins> An 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
Original text:
9.  9.1. Wherever End-User data is stored, it represents a potential target

Reviewer comments:
When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL

Revised text:
9. <ins> The privacy principles of ISO.29100 should be adhered to. </ins> 9.1. Wherever End-User data is stored, it represents a potential target
Original text:
any encryption mechanism. Implementers MUST ensure that the transport protocol provides <del> confidentiality, if the privacy of End-User data or correlation attacks are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT Combined Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. </del>  9.3.

Reviewer comments:
When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL

Revised text:
any encryption mechanism. Implementers MUST ensure that the transport protocol provides  <ins> confidentiality if the privacy of End-User data or correlation attacks by passive observers are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT Combined Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. </ins> 9.3.
Original text:
To prevent these types of linkability, various methods, including but not limited to the following ones can be used:  10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin,

Reviewer comments:
When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL

Revised text:
To prevent these types of linkability, various methods, including but not limited to the following ones can be used: <ins> 9.5. An Issuer issuing only one type of SD-JWT might have privacy implications, because if the Holder has an SD-JWT issued by that Issuer, its type and claim names can be determined. For example, if the National Cancer Institute only issued SD-JWTs with cancer registry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient. Moreover, the issuer identifier alone may reveal information about the user. For example, when a military organization or a drug rehabilitation center issues a vaccine credential, verifiers can deduce that the holder is a military member or may have a substance use disorder. To mitigate this issue, a group of issuers may elect to use a common Issuer identifier.  A group signature scheme outside the scope of this specification may also be used, instead of an individual signature. </ins> 10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin,
Original text:
belongs to. Other ways of proving Holder Binding MAY be used when supported by <del> the Verifier, e.g., when the Combined Format for Presentation is itself embedded in a signed JWT.  See enveloping for details. </del>  If no Holder Binding JWT is included, the Combined Format for Presentation ends with the

Reviewer comments:
Addresses issue . enveloping in a single signed JWT more than one Combined Format for Presentation without a Holder Binding JWT.

Revised text:
belongs to. Other ways of proving Holder Binding MAY be used when supported by  <ins> the Verifier, e.g., when the Combined Format for Presentation without a Holder Binding JWT is itself embedded in a signed JWT.  See enveloping for details. </ins> If no Holder Binding JWT is included, the Combined Format for Presentation ends with the
Original text:
not contain a Holder Binding JWT as the outer container can be signed instead.  8. Security considerations in this section help achieve the following

Reviewer comments:
Addresses issue . enveloping in a single signed JWT more than one Combined Format for Presentation without a Holder Binding JWT.

Revised text:
not contain a Holder Binding JWT as the outer container can be signed instead. <ins> Other specifications or profiles of this specification may define alternative formats for transporting the Combined Format for Presentation that envelopes multiple such objects into one object, and provides Holder Binding using means other than Holder Binding JWT. </ins> 8. Security considerations in this section help achieve the following