jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: 3.2. <del> To release to a verifier a subset of SD-JWT claim values, a holder </del> <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
Code change:
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

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

Related discussion:
text: 4.4. <del> The following shows the contents of a release document for Example 1: </del> <ins> The following shows the contents of an SD-JWT-R for Example 1: </ins> For each claim, an array of the salt and the claim value is contained in the object. <del> Again, the release document follows the same structure as the </del> <ins> Again, the SD-JWT-R follows the same structure as the </ins> <del> in the SD-JWT.  For Example 2, a release document limiting </del> <ins> in the SD-JWT.  For Example 2, a SD-JWT-R limiting </ins> to
Code change:
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

Related discussion:
text: only could look as follows: <del> The SD-JWT Release MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </del> <ins> The SD-JWT-R MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </ins> and claims). <del> If holder binding is desired, the SD-JWT Release is signed by the holder.  If no holder binding is to be used, the </del> <ins> If holder binding is desired, the SD-JWT-R is signed by the holder. If no holder binding is to be used, the </ins> algorithm is used, i.e., the document is not signed.
Code change:
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

Related discussion:
text: 4.5. <del> The SD-JWT and the SD-JWT Release can be combined into one document using </del> <ins> The SD-JWT and the SD-JWT-R can be combined into one document using </ins> as a separator (here for Example 1):
Code change:
I think we need a section summarizing what kind of claims SD-JWT can consist of... claims in SD-JWT can all be selectively disclosable claims, or can also include always-disclosed claims claim names in SD-JWT can all be blinded, or can include non-blinded claim names claim structure can be simple or complex and claims in the complex structure can be blinded/not-blinded and disclosable/not-disclosable same claim names can appear within multiple complex claim structures and can be blinded/not-blinded and disclosable/not-disclosable...

Related discussion:
text: 1.1. <ins> 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP
Code change:
Added an option to do pairwise SD-JWTs to prevent Verifier/Verifier linkability Original feedback. Please re-write section 8.2 in the light of the above suggestions.

Related discussion:
text: Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user on the basis of unique values encoded in the SD-JWT (Issuer <del> signature, salts, digests, etc.).  More advanced cryptographic schemes, outside the scope of this specification, can be used to prevent this type of linkability. </del> <ins> signature, salts, digests, etc.). To prevent these types of linkability, various methods, including but not limited to the following ones can be used: </ins> 9. <del> We would like to thank Alen Horvat, Brian Campbell, Christian Paquin, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Shawn Butterfield, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> We would like to thank Alen Horvat, Arjan Geluk, Brian Campbell, Christian Paquin, David Bakker, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt 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.
Code change:
Fixing the "release" in the sense of a defined term as "SD-JWT Release"
We have fixed the term and definitions but a few still appear in the main text. We need to fix them as well, hopefully before the first individual draft is uploaded. So, s/signatures called releases/signatures called SD-JWT Releases/ s/SD-JWTs and releases/SD-JWTs and SD-JWT Releases/ s/Verifying a Release/Verifying a SD-JWT Release/
Fixed with PR

Related discussion:
text: disclosure (SD-JWT) which would enable sharing only subset of the claims included in the original JWT instead of releasing all the claims to every Verifeir.  This document also defines an optional <del> format for signatures called releases (SD-JWT-R). </del> <ins> format for signatures called SD-JWT Releases (SD-JWT-R). </ins> One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such use case, there has been no
Code change:
Fixing the "release" in the sense of a defined term as "SD-JWT Release"
We have fixed the term and definitions but a few still appear in the main text. We need to fix them as well, hopefully before the first individual draft is uploaded. So, s/signatures called releases/signatures called SD-JWT Releases/ s/SD-JWTs and releases/SD-JWTs and SD-JWT Releases/ s/Verifying a Release/Verifying a SD-JWT Release/
Fixed with PR

Related discussion:
text: 3. <del> In the following section, the concepts of SD-JWTs and releases are described at a conceptual level. </del> <ins> In the following section, the concepts of SD-JWTs and SD-JWT Releases are described at a conceptual level. </ins> 3.1.
Code change:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Related discussion:
text: verifier.  However, when a signed JWT is intended to be multi-use, the ability to selectively disclose a subset of the claims depending on the verifier becomes crucial to ensure minimum disclosure and <del> prevent verifier from obtaining claims irrelevant for the use case at hand. </del> <ins> prevent verifier from obtaining claims irrelevant for the transaction at hand. </ins> One example of such a multi-use JWT is a verifiable credential, or a tamper-evident credential with a cryptographically verifiable
Code change:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Related discussion:
text: Note: so far agreed to define holder binding (user's public key contained inside an SD-JWT) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general <del> mechanism of selective disclosure we are trying to define here. </del> <ins> mechanism of selective disclosure defined here. </ins> 1.1.
Code change:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Related discussion:
text: 2.7. An entity that entity that requests, checks and extracts the claims <del> from SSD-JWT-R (2.2) </del> <ins> from SD-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
Code change:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Related discussion:
text: The issuer MUST choose a unique salt value for each claim value. Each salt value MUST contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be <del> encoded as a string.  It is RECOMMENDED to base64url encode at least </del> <ins> encoded as a string.  It is RECOMMENDED to base64url-encode at least </ins> 16 pseudorandom bytes. The issuer MUST build the hashes by hashing over a string that is
Code change:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Related discussion:
text: values that are contained in the SD-JWT, along with the precise input to the hash calculation, and the salts.  There MAY be other information the issuer needs to communicate to the holder, such as a <del> private key key if the issuer selected the holder key pair. </del> <ins> private key if the issuer selected the holder key pair. </ins> 4.2.1.
Code change:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Related discussion:
text: 4.3. For transporting the SVC together with the SD-JWT from the issuer to <del> the holder, the SVC is base64ur-encoded and appended to the SD-JWT using </del> <ins> the holder, the SVC is base64url-encoded and appended to the SD-JWT using a period character </ins> as the separator.  For Example 1, the combined format looks as follows:
Code change:
Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM

Related discussion:
text: 4.5. The SD-JWT and the SD-JWT-R can be combined into one document using <ins> period character </ins> as a separator (here for Example 1):
Code change:
Add Justin to Acknowledgements (he suggested the array for _sd in sid…e meeting) and fix the commas + and in that list of names

Related discussion:
text: 10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin, <del> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, 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. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.