jiebi/CodeConvo huggingface dataset:
Code change:
to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!

Related discussion:
text: The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send <del> Disclosures or reveal the salt values in any other way. </del> <ins> Disclosures or reveal the salt values in any other way.  A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. </ins> <del> A Holder MUST NOT send a Disclosure that was not included in the SD- JWT or send a Disclosure more than once. </del> <ins> To further illustrate the SD-JWT format, the following example shows a few different SD-JWT permutations, both with and without various constituent parts. </ins> 5.1.
Code change:
to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!

Related discussion:
text: 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, Mike Prorock, Nat <del> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, 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> <ins> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, 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.
Code change:
In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.

Related discussion:
text: An SD-JWT is composed of the following: <del> The individual parts will be explained in the following subsections. </del> <ins> The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in iss-signed-jwt, creating_disclosures, and kb-jwt respectively. </ins> The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows: <del> The order of the tilde separated values MUST be the Issuer-signed JWT, followed by any number of Disclosures, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </del> <ins> The order of the concatenated parts MUST be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </ins> The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.
Code change:
In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.

Related discussion:
text: The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send <del> Disclosures or reveal the salt values in any other way. </del> <ins> Disclosures or reveal the salt values in any other way.  A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. </ins> <del> A Holder MUST NOT send a Disclosure that was not included in the SD- JWT or send a Disclosure more than once. </del> <ins> To further illustrate the SD-JWT format, the following example shows a few different SD-JWT permutations, both with and without various constituent parts. </ins> 5.1.
Code change:
In an attempt at addressing URL see it live here URL
Approved with a minor editorial fix.

Related discussion:
text: 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, Mike Prorock, Nat <del> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Richard Barnes, Ryosuke Abe, 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> <ins> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, 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.
Code change:
adding SD-JWT claim Note: need to update the examples to include it once we agree this claim is needed (cc NAME )
We need to say in the checking algorithm that verifiers MUST check the alg and MUST only accept hash_algs they understand and deem secure.
information about the hash function should probably be included inside SD-JWT. Based on NAME 's comment to the PR URL
Yes, needed indeed. This and more details about hash formatting (how to transform inputs into byte arrays to be passed to the hash function).
The alternative is to use the same hash function as was used for the signature. This is done in OpenID Connect Core at URL in the definition (as well as in the definition. The language is:
You might want to use a different hash function to reduce the SD-JWT size (e.g., SHA-256 truncated to 128 bit), or decide on a stronger hash function with iteration to reduce the size of the salt (again, to minimize the size of the artefact). Bottom line, choosing the hash function independently might be useful.
As discussed in the call, if we allow different hashes to be used, we may want to make a recommendation that for simplicity an implementor may want to use the same hash algorithm to minimise implementation errors.
Assuming we're not going to use the trick that OpenID Connect uses to determine the hash algorithm implicitly, then I approve of this approach.

Related discussion:
text: 4.1.1.2. <ins> 4.1.1.3. </ins> If the issuer wants to enable holder binding, it includes a public key associated with the holder, or a reference thereto.
Code change:
adding SD-JWT claim Note: need to update the examples to include it once we agree this claim is needed (cc NAME )
We need to say in the checking algorithm that verifiers MUST check the alg and MUST only accept hash_algs they understand and deem secure.
information about the hash function should probably be included inside SD-JWT. Based on NAME 's comment to the PR URL
Yes, needed indeed. This and more details about hash formatting (how to transform inputs into byte arrays to be passed to the hash function).
The alternative is to use the same hash function as was used for the signature. This is done in OpenID Connect Core at URL in the definition (as well as in the definition. The language is:
You might want to use a different hash function to reduce the SD-JWT size (e.g., SHA-256 truncated to 128 bit), or decide on a stronger hash function with iteration to reduce the size of the salt (again, to minimize the size of the artefact). Bottom line, choosing the hash function independently might be useful.
As discussed in the call, if we allow different hashes to be used, we may want to make a recommendation that for simplicity an implementor may want to use the same hash algorithm to minimise implementation errors.
Assuming we're not going to use the trick that OpenID Connect uses to determine the hash algorithm implicitly, then I approve of this approach.

Related discussion:
text: I think. <del> 4.1.1.3. </del> <ins> 4.1.1.4. </ins> The SD-JWT payload MAY contain other claims and will typically contain other JWT claims, such as
Code change:
This addresses Issue . The rest of the text still refers to asymmetric signatures, but technically, an HMAC is now allowed.
The scope of this PR was intentionally to only remove the explicit prohibition on MAC. Not to explain how it might work or adjust other language about asymmetric signatures or private keys or similar. Just remove the explicit prohibition so that, should some deployment/ecosystem/jurisdiction need to MAC for whatever reason, it's not directly going against a normative must.

Related discussion:
text: 5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's <del> private key.  It MUST use a JWS asymmetric digital signature algorithm.  It MUST NOT use </del> <ins> private key.  It MUST NOT use the </ins> <del> or an identifier for a symmetric algorithm (MAC). </del> <ins> algorithm. </ins> The payload of an SD-JWT is a JSON object according to the following rules:
Code change:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Related discussion:
text: cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value.  The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in <del> data_formats. </del> <ins> data_formats.  When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosures for the claims that it wants to reveal to that Verifier. </ins> An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.
Code change:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Related discussion:
text: 5.2.3. <del> For embedding the Disclosures in the SD-JWT, the Disclosures are hashed using the hash algorithm specified in the </del> <ins> For embedding references to the Disclosures in the SD-JWT, each Disclosure is hashed using the hash algorithm specified in the </ins> claim described in hash_function_claim.  The resulting digest is then included in the SD-JWT payload instead of the original claim value, as described next. The digest MUST be taken over the US-ASCII bytes of the base64url- <del> encoded Disclosure.  This follows the convention in JWS RFC7515 and JWE RFC7516.  The bytes of the digest MUST then be base64url-encoded. </del> <ins> encoded value that is the Disclosure.  This follows the convention in JWS RFC7515 and JWE RFC7516.  The bytes of the digest MUST then be base64url-encoded. </ins> It is important to note that:
Code change:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Related discussion:
text: For both the General and Flattened JSON Serialization, the SD-JWT is represented as a JSON object according to Section 7.2 of RFC7515. <del> The disclosures (both for issuance and presentation) SHOULD be </del> <ins> The Disclosures (both for issuance and presentation) SHOULD be </ins> included in the serialized JWS using the member name at the top-level of the JSON object (the same level as the
Code change:
Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!

Related discussion:
text: payload, whereas the Holder includes only the Disclosures selected for the given presentation. <del> Alternative methods for conveying the disclosures MAY be used (such </del> <ins> Alternative methods for conveying the Disclosures MAY be used (such </ins> as including them in a member of an outer JSON structure also containing the JSON Serialized