jiebi/TextFlow huggingface dataset:
Original text:
10. <del> We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, John Mattsson, Matthew Miller, Justin Richer, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci 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:
Fixes Issue
Thanks NAME I think the two folks should be acknowledged and the small change around the claim incorporated. Then I think this should be merged and we should publish a -04 as basically a bug fix. The issue NAME URL found kinda undermines the whole point of SD-JWT and we should have a published version out that fixes that.
When decoys are used (_sd members not corresponding to a disclosure are added) the says to I imagine this is not intended and the holder should ignore missing disclosures instead? Same in
Actually the following in doesn't make sense to me at all since the whole point is to selectively not release disclosures.
Good point/catch Filip. I think the intent was to say that if a disclosure is found that isn't referenced by a _sd hash value, that should be a rejection. But the language got turned around somewhat. I think anyway. It needs to be fixed or clarified regardless though.
Processing by the Holder: This seems fine to me. In the context, "the digests" refers to "the digests of the Disclosures". If there is a Disclosure that hashes to a digest not found in any _sd array, the SD-JWT is invalid. Maybe we can clarify by modifying this to: Verification by the Verifier: This is wrong and should read "If no such Disclosure can be found, the digests MUST be ignored." Thanks for bringing this up, Filip!
Don't we then also need something at the end of Verification by the Verifier - that makes sure all of the provided disclosures match a digest in the payload and reject if that is not the case or am I missing something here?
That would force the Holder to act correctly, but would it provide any benefit beyond that?
The changes above are included in PR - please review NAME NAME
PR merged

Revised text:
10.  <ins> We would like to thank Alen Horvat, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci 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:
Security considerations in this section help achieve the following properties:  8.1. The SD-JWT MUST be signed by the Issuer to protect integrity of the

Reviewer comments:
This fixes Issue . The main change is to better describe in which role the adversary acts.
does this one need a doc history entry... ?

Revised text:
Security considerations in this section help achieve the following properties: <ins> An adversary in the role of the Verifier cannot obtain information from an SD-JWT about any claim name or claim value that was not explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT. A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in holder_binding_security, the application of Holder Binding can ensure that the presenter of an SD- JWT credential is the legitimate Holder of the credential. </ins> 8.1. The SD-JWT MUST be signed by the Issuer to protect integrity of the
Original text:
TBD <del> @VC_JWT </del> 

Reviewer comments:
To fix Issue , I found that removing Example 2b is the best way to go. I tried to fixate the nonces used in the examples despite decoys being generated in one of the examples, but that got quite messy and introduces a lot of unsafe code paths into the python code. An alternative would be to manage the example manually, but that is a source for errors, so let's not do that.
The decoy concept is intuitive enough that a separate example isn't needed, I think. And per the separate example that has a completely different set of digests might cause confusion. So removing 2b seems like a good course of action. The change is larger than I'd have expected. Are all the other file changes due to regenerating examples? I think so but it caught my attention. And it seems like and this will be difficult to resolve. But maybe you've already considered that.
Why remove an entire example, if we can add a text clarifying that "Example 2b uses the same data as 2a, but because even for the same claim values, different nonces are used, not just the decoys but all digests are different from those in 2a"?
That was my initial approach, but with that change there's really not that much value to the example: It just shows a bunch of digests, where the number of digests is higher than it was previously. The fact that the digests are different can be confusing for readers at worst and the example is not very helpful at best.
So instead of showing the decoy digests in the examples you propose to list them seperately and not show a complete example with decoy digests?
We agreed on our call to generate a snippet of markdown code to explicitly list the decoy digests to improve the explanation.
I updated the python script and the spec to show the decoy digests: URL
Other than the little nit about the the text that says the decoys in the example are about the address, this looks pretty good.
Do you want to mention something in the doc history?
Good point, done!
NAME Can you please review this?
states that it was created using data from , but adding decoy values. I'd expect its param to be a superset of example 2a's, but it's not the case. Am I missing something?
Example 2b includes different nonces than Example 2a. We try to use deterministic random numbers to generate the examples, but in this case, due to the order in which the decoys and regular salts are created, this approach does not produce the same nonces for the same "real" disclosures.
PR was merged

Revised text:
TBD  <ins> 11.1. This section requests registration of the "application/sd-jwt" media type RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838, which can be used to indicate that the content is an SD-JWT. 11.2. This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry IANA.StructuredSuffix in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT. </ins>
Original text:
not, however, learn any claim values not disclosed in the Disclosures. <del> This document also describes an optional mechanism for Holder </del>  Binding, or the concept of binding an SD-JWT to key material controlled by the Holder.  The strength of the Holder Binding is conditional upon the trust in the protection of the private key of

Reviewer comments:
Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm

Revised text:
not, however, learn any claim values not disclosed in the Disclosures.  <ins> This document also specifies an optional mechanism for Holder </ins> Binding, or the concept of binding an SD-JWT to key material controlled by the Holder.  The strength of the Holder Binding is conditional upon the trust in the protection of the private key of
Original text:
4.3. <del> Holder Binding is an optional feature.  For example, when Cryptographic Holder Binding is required by the use-case, the SD-JWT must contain information about the key material controlled by the Holder. </del>  Note: How the public key is included in SD-JWT is out of scope of this document.  It can be passed by value or by reference. <del> The Holder can then create a signed document, the Holder Binding JWT, using its private key.  This document contains some data provided by the Verifier (out of scope of this document) to ensure the freshness of the signature, for example, a nonce and an indicator of the intended audience for the document. </del>  The Holder Binding JWT can be included in the Combined Format for Presentation and sent to the Verifier along with the SD-JWT and the

Reviewer comments:
Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm

Revised text:
4.3.  <ins> Holder Binding is an optional feature.  When Cryptographic Holder Binding is required by the use-case, the SD-JWT MUST contain information about the key material controlled by the Holder. </ins> Note: How the public key is included in SD-JWT is out of scope of this document.  It can be passed by value or by reference.  <ins> The Holder can then create a signed document, the Holder Binding JWT as defined in hb-jwt, using its private key.  This document contains some data provided by the Verifier such as a nonce to ensure the freshness of the signature, and audience to indicate the intended audience for the document. </ins> The Holder Binding JWT can be included in the Combined Format for Presentation and sent to the Verifier along with the SD-JWT and the
Original text:
5.4.1. The Holder MAY add an optional JWT to prove Holder Binding to the <del> Verifier.  The precise contents of the JWT are out of scope of this specification.  Usually, a </del>  and <del> claim are included to show that the proof is intended for the Verifier and to prevent replay attacks.  How the </del>  <del> or other claims are obtained by the Holder is out of scope of this specification. </del>  <del> Example Holder Binding JWT payload: </del>  <del> Which is then signed by the Holder to create a JWT like the following: </del>  Whether to require Holder Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it

Reviewer comments:
Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm

Revised text:
5.4.1. The Holder MAY add an optional JWT to prove Holder Binding to the  <ins> Verifier. 5.4.1.1. This section defines the contents of the Holder Binding JWT. The JWT MUST contain the following elements: * in the JOSE header, * : REQUIRED.  MUST be , which explicitly types the Holder Binding JWT as recommended in Section 3.11 of RFC8725.  * : REQUIRED.  A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry.  MUST NOT be or an identifier for a symmetric algorithm (MAC).  * in the JWT body, * : REQUIRED.  The value of this claim MUST be the time at which the Holder Binding JWT was issued using the syntax defined in RFC7519.  * : REQUIRED.  The intended receiver of the Holder Binding JWT.  How the value is represented is up to the protocol used and out of scope of this specification.  * : REQUIRED.  Ensures the freshness of the signature.  The value type of this claim MUST be a string.  How this value is obtained is up to the protocol used and out of scope of this specification. To validate the signature on the Holder Binding JWT, the Verifier MUST use the key material in the SD-JWT.  If it is not clear from the SD-JWT, HB-JWT MUST specify which key material the Verifier needs to use to validate HB-JWT using JOSE header parameters such as </ins> and  <ins> . </ins>  <ins> Below is a non-normative example of a Holder Binding JWT header: </ins>  <ins> Below is a non-normative example of a Holder Binding JWT payload: </ins>  <ins> Below is a non-normative example of a Holder Binding JWT produced by signing a payload in the example above: </ins> Whether to require Holder Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it
Original text:
Security considerations in this section help achieve the following properties:  8.1. The SD-JWT MUST be signed by the Issuer to protect integrity of the

Reviewer comments:
Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm

Revised text:
Security considerations in this section help achieve the following properties: <ins> An adversary in the role of the Verifier cannot obtain information from an SD-JWT about any claim name or claim value that was not explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT. A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in holder_binding_security, the application of Holder Binding can ensure that the presenter of an SD- JWT credential is the legitimate Holder of the credential. </ins> 8.1. The SD-JWT MUST be signed by the Issuer to protect integrity of the
Original text:
8.2. Holders can manipulate the Disclosures by changing the values of the <del> claims before sending them to the Issuer.  The Issuer MUST check the Disclosures to ensure that the values of the claims are correct, </del>  i.e., the digests of the Disclosures are actually present in the signed SD-JWT.

Reviewer comments:
Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm

Revised text:
8.2. Holders can manipulate the Disclosures by changing the values of the  <ins> claims before sending them to the Verifier.  The Verifier MUST check the Disclosures to ensure that the values of the claims are correct, </ins> i.e., the digests of the Disclosures are actually present in the signed SD-JWT.
Original text:
Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter <del> Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci 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:
Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm

Revised text:
Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter  <ins> 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. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Original text:
8.2. Holders can manipulate the Disclosures by changing the values of the <del> claims before sending them to the Issuer.  The Issuer MUST check the Disclosures to ensure that the values of the claims are correct, </del>  i.e., the digests of the Disclosures are actually present in the signed SD-JWT.

Reviewer comments:
to
I think the first paragraph mixes Issuer with Verifier. Old: New:
Thanks for catching that. We'll fix.

Revised text:
8.2. Holders can manipulate the Disclosures by changing the values of the  <ins> claims before sending them to the Verifier.  The Verifier MUST check the Disclosures to ensure that the values of the claims are correct, </ins> i.e., the digests of the Disclosures are actually present in the signed SD-JWT.
Original text:
Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter <del> Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del>  The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Reviewer comments:
to
I think the first paragraph mixes Issuer with Verifier. Old: New:
Thanks for catching that. We'll fix.

Revised text:
Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter  <ins> 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. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Original text:
, etc. as defined or required by the application using SD-JWTs.  5.1.1. For each claim that is to be selectively disclosed, the Issuer

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:
, etc. as defined or required by the application using SD-JWTs. <ins> Applications of SD-JWT SHOULD be explicitly typed using the header parameter.  See explicit_typing for more details. </ins> 5.1.1. For each claim that is to be selectively disclosed, the Issuer