jiebi/TextFlow huggingface dataset:
Original text:
by ecosystem rules, application-specific profile, or the credential format and MAY include claims other than those listed herein. <del> 10.9. </del>  This specification does not define how signature verification keys of Issuers are distributed to Verifiers.  However, it is RECOMMENDED

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:
by ecosystem rules, application-specific profile, or the credential format and MAY include claims other than those listed herein.  <ins> 10.8. </ins> This specification does not define how signature verification keys of Issuers are distributed to Verifiers.  However, it is RECOMMENDED
Original text:
expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method. <del> 10.10. </del>  When Key Binding is not enforced, any entity in possession of an SD- JWT Presentation can forward the contents to third parties.  When

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:
expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method.  <ins> 10.9. </ins> When Key Binding is not enforced, any entity in possession of an SD- JWT Presentation can forward the contents to third parties.  When
Original text:
In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Key Binding. <del> 10.11. </del>  In a Presentation, the Issuer-signed JWT is integrity-protected by the Issuer's signature, and the Disclosures are integrity-protected

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:
In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Key Binding.  <ins> 10.10. </ins> In a Presentation, the Issuer-signed JWT is integrity-protected by the Issuer's signature, and the Disclosures are integrity-protected
Original text:
JWT, besides proving Key Binding, protects the integrity of the set of Disclosures the Holder disclosed. <del> 10.12. </del>  Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for

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:
JWT, besides proving Key Binding, protects the integrity of the set of Disclosures the Holder disclosed.  <ins> 10.11. </ins> Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for
Original text:
split into issuance and presentation. Note: Throughout the examples in this document, line breaks had to be <del> added to JSON strings and base64-encoded strings to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks within strings. </del>  6.1.

Reviewer comments:
for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it

Revised text:
split into issuance and presentation. Note: Throughout the examples in this document, line breaks had to be  <ins> added to JSON strings and base64-encoded strings to adhere to the 72-character limit for lines in RFCs and for readability.  JSON does not allow line breaks within strings. </ins> 6.1.
Original text:
split into component parts and the Disclosures can be found in the respective member of the JSON object (or elsewhere). <del> Using a payload similar to that from Example 1 [1], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. </del>  Below is a non-normative example of a presentation of the JWS JSON serialized SD-JWT, where the Holder has selected to disclose

Reviewer comments:
for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it

Revised text:
split into component parts and the Disclosures can be found in the respective member of the JSON object (or elsewhere).  <ins> Using a payload similar to that from the example in main-example, the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. </ins> Below is a non-normative example of a presentation of the JWS JSON serialized SD-JWT, where the Holder has selected to disclose
Original text:
The Issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places <del> in the structure of the SD-JWT.  This can be seen in Example 3 in the Appendix, where multiple claims with the name </del>  appear, but each of them has a different salt.

Reviewer comments:
for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it

Revised text:
The Issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places  <ins> in the structure of the SD-JWT.  This can be seen in the example in example-complex-structured-sd-jwt, where multiple claims with the name </ins> appear, but each of them has a different salt.
Original text:
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. <del> 14.  References 14.1.  URIs [1] #example-1 </del>

Reviewer comments:
for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it

Revised text:
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.
Original text:
a few different SD-JWT permutations, both with and without various constituent parts.  5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's

Reviewer comments:
would
It seems like it could be helpful to implementors, allowing them to quickly validate whether what they have is syntactically an SD-JWT or an SD-JWT with key binding. Something like:
The actual helpfulness of ABNF IMHO really depends on the readers familiarity with ABNF. I don't know that such familiarity is particularity prevalent. But, as long as it's correct, it doesn't hurt to include either. And while I'm not overly familiar with ABNF myself, I know enough to know that that isn't valid ABNF and doesn't quite correctly convey the SD-JWT constructs. I've endeavored to fix it up but am not 100% sure this is correct either: \ with a bit of help from https://author-URL
Looks good to me, thank you! Maybe a small improvement would be to introduce a name for disclosure?
That's a good improvement, thanks!
Looks good to me, and appears valid according to the .
(SD-JWT-KB part of the ABNF depends on another PR)
need to wait after is resolved to do a PR.
maybe add a KB-JWT line to be even more better? a la:
Not my religion, but happy to celebrate anyway.

Revised text:
a few different SD-JWT permutations, both with and without various constituent parts. <ins> As an alternative illustration of the SD-JWT format, for those who celebrate, ABNF RFC5234 for the SD-JWT, SD-JWT+KB, and various constituent parts is provided here: </ins> 5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's
Original text:
This document also defines a format for SD-JWTs with Key Binding (SD- JWT+KB).  By optionally sending an SD-JWT+KB to a Verifier, the Holder can prove to the Verifier that they hold the private key <del> associated to the SD-JWT (e.g., using the </del>  claim RFC7800).  The strength of the binding is conditional upon the trust in the protection of the private key of the key pair an SD-JWT

Reviewer comments:
More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

Revised text:
This document also defines a format for SD-JWTs with Key Binding (SD- JWT+KB).  By optionally sending an SD-JWT+KB to a Verifier, the Holder can prove to the Verifier that they hold the private key  <ins> associated to the SD-JWT (i.e., using the </ins> claim RFC7800).  The strength of the binding is conditional upon the trust in the protection of the private key of the key pair an SD-JWT
Original text:
Note: The examples throughout this document use the <del> claim to include the raw public key by value in SD-JWT. </del>  5.2.

Reviewer comments:
More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

Revised text:
Note: The examples throughout this document use the  <ins> claim with the member to include the raw public key by value in SD-JWT. </ins> 5.2.
Original text:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey <del> Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del>  The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Reviewer comments:
Mr. Heenan suspects he should probably be listed in the SD-JWT acknowledgements section and I don't disagree

Revised text:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey  <ins> Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, 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:
a few different SD-JWT permutations, both with and without various constituent parts. <del> An SD-JWT without Disclosures and without a KB-JWT: </del>  <del> An SD-JWT with Disclosures and without a KB-JWT: </del>  An SD-JWT+KB without Disclosures:

Reviewer comments:
to
I was not completely sure either and that's why I posted only the issue and no PR first. I still think that in chapter 5. the extra mentions are confusing as the text and the ABNF are separating the SD-JWT and SD-JWT+KB formats. In contrast, similar explicit mention in the verification section is clarifying to me.
I wasn't sure when first looking at it and actually thing it's okay either way but have come to think it's more okay this way.
The distinguishing of SD-JWT from SD-JWT+KB is a good clarifying change in -09. Some extra mentions of KB-JWT still remain that could probably removed: In : >An SD-JWT without Disclosures and without a KB-JWT and >An SD-JWT with Disclosures and without a KB-JWT The "and without a KB-JWT" could be removed as there are separate examples for SD-JWT+KB and SD-JWT is now defined not to include KB-JWT.
Thanks NAME PR does exactly what you've suggested.
approved the PR () too.
I am not sure these are actually extraneous, but ok looks good

Revised text:
a few different SD-JWT permutations, both with and without various constituent parts.  <ins> An SD-JWT without Disclosures: </ins>  <ins> An SD-JWT with Disclosures: </ins> An SD-JWT+KB without Disclosures:
Original text:
credential to the Issuer.  It is important to note that the timing of such requests could potentially serve as a side-channel. <del> Verifier/Verifier unlinkablility and presentation unlinkablility can be achieved using batch issuance: A batch of credentials based on the </del>  same claims is issued to the Holder instead of just a single credential.  The Holder can then use a different credential for each Verifier or even for each session with a Verifier.  New key binding

Reviewer comments:
BTW NAME please do a quick PR adding yourself to the Acknowledgements section, if you;'d like.
Thanks NAME !

Revised text:
credential to the Issuer.  It is important to note that the timing of such requests could potentially serve as a side-channel.  <ins> Verifier/Verifier unlinkability and presentation unlinkability can be achieved using batch issuance: A batch of credentials based on the </ins> same claims is issued to the Holder instead of just a single credential.  The Holder can then use a different credential for each Verifier or even for each session with a Verifier.  New key binding
Original text:
and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations.  The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Reviewer comments:
Acknowledge Martin Thomson for his contribution: URL
Open for one week. No approvals. No objections. One minor editorial change applied. Will continue to wait.
If this is this acceptable, I love it

Revised text:
and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. <ins> Special appreciation is extended to Martin Thomson, who wielded his considerable intellect and influence to change a single occurrence of the word "to" to "with" in the midst of a significant proposal that would be integrated into this document six months later. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.