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

Related discussion:
text: TBD <del> @VC_JWT </del> <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>
Code change:
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

Related discussion:
text: not, however, learn any claim values not disclosed in the Disclosures. <del> This document also describes an optional mechanism for Holder </del> <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
Code change:
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

Related discussion:
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> <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. <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> <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
Code change:
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

Related discussion:
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> <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 <del> claim are included to show that the proof is intended for the Verifier and to prevent replay attacks.  How the </del> <ins> . </ins> <del> or other claims are obtained by the Holder is out of scope of this specification. </del> <ins> Below is a non-normative example of a Holder Binding JWT header: </ins> <del> Example Holder Binding JWT payload: </del> <ins> Below is a non-normative example of a Holder Binding JWT payload: </ins> <del> Which is then signed by the Holder to create a JWT like the following: </del> <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
Code change:
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

Related discussion:
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
Code change:
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

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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.
Code change:
to
I think the first paragraph mixes Issuer with Verifier. Old: New:
Thanks for catching that. We'll fix.

Related discussion:
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> <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.
Code change:
to
I think the first paragraph mixes Issuer with Verifier. Old: New:
Thanks for catching that. We'll fix.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
text: In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding. <ins> 8.10. Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the header parameter when the SD-JWT is issued, and for Verifiers to check this value. When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.  The definition of in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter. </ins> 9. The privacy principles of ISO.29100 should be adhered to.
Code change:
Honestly, I'm not sure about this one. But I said I'd put together a PR for with an update to the title and some qualifying text. So this is that PR as something to discuss anyway. At least these few sentences took me an embarrassingly long time to write :/

Related discussion:
text: <del> Selective Disclosure for JWTs (SD-JWT) </del> <ins> SD-JWT: Selective Disclosure for JWT and JWS with JSON payloads </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract <del> This document specifies conventions for creating JSON Web Token (JWT) documents that support selective disclosure of JWT claims. </del> <ins> This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure.  It encompasses various applications, including but not limited to the selective disclosure of JSON Web Tokens (JWT) claims. </ins> 1. <del> The JSON-based RFC8259 representation of claims in a signed JSON Web Token (JWT) RFC7519 is secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </del> <ins> This document specifies conventions for creating JSON Web Signature (JWS) RFC7515 structures with JSON RFC8259 objects as the payload while supporting selective disclosure of individual elements of that JSON.  Because JSON Web Token (JWT) RFC7519 is a very prevalent application of JWS with a JSON payload, the selective disclosure of JWT claims receives primary treatment herein.  However, that does not preclude the mechanism's applicability to other or more general applications of JWS with JSON payloads. The JSON-based representation of claims in a signed JWT is secured against modification using JWS digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </ins> contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all the claims.  Likewise, anyone with the decryption key receiving encrypted JWT can also read
Code change:
RIPEMD-160 is usable, but not its predecessors. For this reason this PR removes RIPEMD-160 from the list of the weak algs by saying that only -160 predecessors must not be used.
Thank you!

Related discussion:
text: , which are unfit for security applications). <del> Furthermore, the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. </del> <ins> Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. </ins> 8.6.
Code change:
Text looks good but it's going to clash with the array spec work URL
It's a small change, we can sort that out when merging either.
Now that is allowed at multiple locations in the JSON document, including recursively, I would expect Sec. 5.1.2 to define explicitly where the claim should appear. Once at the top of the document? Can it also appear alongside claims located deeper in the document? Also, please change the section heading from "hash function" to "hash algorithm", for consistency.
Thank you! The intention is that there is only one at the top level. We will clarify.
Concur with NAME
+1

Related discussion:
text: The claim indicates the hash algorithm used by the Issuer to generate the <del> digests over the salts and the claim values.  If the </del> <ins> digests.  When used, this claim MUST appear at the top level of the SD-JWT payload.  It MUST NOT be used in any object nested within the payload.  If the </ins> <del> claim is not present, a default value of </del> <ins> claim is not present at the top level, a default value of </ins> <del> is used. </del> <ins> MUST be used. </ins> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash