jiebi/CodeConvo huggingface dataset:
Code change:
update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative

Related discussion:
text: [1] #example-1 [2] #example-1 <ins> [3] #enveloping </ins>
Code change:
as additional explanation in the draft for see it here URL
in this PR might be replaced with depending on how PR goes.
Thanks, LGTM, just one editorial comment.

Related discussion:
text: recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. <ins> 9.6.1. Issuer provided integrity protection of the SD-JWT payload and Disclosures is achieved by the signature on the Issuer-signed JWT that covers the SD-JWT payload including the digest values of the Disclosures as described in sec-is-jwt and sec-disclosures, respectively.  The Key Binding JWT, defined in kb-jwt, serves exclusively as a mechanism for the Holder to demonstrate possession of the private key corresponding to the public key in the SD-JWT payload.  As such, the signature on the Key Binding JWT does not cover other parts of the SD-JWT.  In cases where it's desirable for the Holder's signature to convey more than a proof-of-possession, such as signing over the selected Disclosures to prove those were the Disclosures selected, the SD-JWT to be presented can be embedded in another JWT (as described in Enveloping SD-JWTs [3]) or otherwise signed by the Holder via the application protocol delivering it. </ins> 9.7. SD-JWT ensures that names of claims that are selectively disclosable
Code change:
replaces , addressing issue I also cleaned up example structure, so that it is the same and uses the same language across multiple examples.

Related discussion:
text: 5.5. <del> This example uses the following object as the set of claims that the Issuer is issuing: </del> <ins> In this example, a simple SD-JWT is demonstrated. </ins> <del> The following non-normative example shows a payload of an SD-JWT for this End-User data: </del> <ins> The Issuer is using the following input claim set: </ins> The Issuer in this case made the following decisions: <del> The Issuer creates the following Disclosures: </del> <ins> The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: </ins> The payload is then signed by the Issuer to create a JWT like the following:
Code change:
first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.

Related discussion:
text: Each digest value ensures the integrity of, and maps to, the respective Disclosure.  Digest values are calculated using a hash <del> function over the Disclosures, each of which contains a 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 sd-jwt-structure. </del> <ins> function over the Disclosures, each of which contains a 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 sd-jwt-structure. </ins> An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.
Code change:
first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.

Related discussion:
text: associated with the Holder, or a reference thereto. It is out of the scope of this document to describe how the Holder <del> key pair is established.  For example, the Holder MAY provide a key pair to the Issuer, the Issuer MAY create the key pair for the Holder, or Holder and Issuer MAY use pre-established key material. </del> <ins> key pair is established.  For example, the Holder MAY create a key pair and provide a public key to the Issuer, the Issuer MAY create the key pair for the Holder, or Holder and Issuer MAY use pre- established key material. </ins> Note: The examples in this document use the
Code change:
first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.

Related discussion:
text: instead of including a separate Key Binding JWT in the SD-JWT. The following non-normative example shows an SD-JWT Presentation <del> enveloped in a JWT payload: </del> <ins> enveloped in a JWT: </ins> Here, the SD-JWT is shown as the value of an
Code change:
first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.

Related discussion:
text: Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple <del> such objects into one object, and provides Key Binding using means </del> <ins> such objects into one object, and provide Key Binding using means </ins> other than the Key Binding JWT. 8.
Code change:
first pass at addressing Issue and .
Does this touch all the mentions of random in URL and convey what the feedback was looking for? I'm honestly not sure. But I also think it doesn't really need changes in that area so I'm not too worried about it. So why am I writing this note? Good question. Just trying to "contribute" I guess.
Approved with the proposed changes.

Related discussion:
text: verified. The security of the Issuer-signed JWT depends on the security of the <del> signature algorithm.  Any of the JSON Web Signature and Encryption Algorithms registered in IANA.JWS.Algorithms can be used, including </del> <ins> signature algorithm.  Any of the JWS asymmetric digital signature algorithms registered in IANA.JWS.Algorithms can be used, including </ins> post-quantum algorithms, when they are ready. 9.2.
Code change:
In response to Issue : Changed some words to ensure that the examples are not understood as an exhaustive list of possible structures Added note on non-normativity of examples Removed the word Option in the section titles and the numbers to avoid the notion of an exhaustive list of options

Related discussion:
text: disclosable claims MAY even appear within other Disclosures. The following examples illustrate some of the options an Issuer has. <del> It is up to the Issuer to decide which option to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or ecosystem requirements.  For more examples with nested structures, see example-simple_structured and example-complex-structured-sd-jwt. </del> <ins> It is up to the Issuer to decide which structure to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or ecosystem requirements.  For more examples with nested structures, see example-simple_structured and example-complex-structured-sd-jwt. </ins> The following input claim set is used as an example throughout this section: <del> Important: Throughout the examples in this document, line breaks had to be added to JSON strings and base64-encoded strings (as shown in the next example) to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks in strings. </del> <ins> Important: The following examples of the structures are non-normative and are not intended to represent all possible options.  They are also not meant to define or restrict how can be represented in an SD-JWT. Note: Throughout the examples in this document, line breaks had to be added to JSON strings and base64-encoded strings (as shown in the next example) to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks in strings. </ins> 5.7.1.
Code change:
-Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses

Related discussion:
text: 7. <del> In some applications or transport protocols, it is desirable to put an SD-JWT into an outer JWT container.  For example, an implementation may envelope multiple credentials and presentations, independent of their format, in a JWT to enable application-layer encryption during transport. For such use cases, the SD-JWT SHOULD be transported as a single string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT. The following non-normative example shows an SD-JWT Presentation enveloped in a JWT: Here, the SD-JWT is shown as the value of an claim where represents the Issuer-signed JWT and represents a Disclosure.  The SD-JWT does not contain a Key Binding JWT as the outer container can be signed instead. Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple such objects into one object and provide Key Binding using means other than the Key Binding JWT. 8. </del> This section describes an optional alternate format for SD-JWT using the JWS JSON Serialization from RFC7515. 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) are included in the serialized JWS using the key </del> <ins> The disclosures (both for issuance and presentation) SHOULD be included in the serialized JWS using the member name </ins> at the top-level of the JSON object (the same level as the
Code change:
-Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses

Related discussion:
text: Disclosure as described in creating_disclosures.  The Issuer includes a Disclosure for each selectively disclosable claim of the SD-JWT payload, whereas the Holder includes only the Disclosures selected <del> for the given presentation.  Additionally, for presentation with a Key Binding, the Holder adds the key </del> <ins> for the given presentation. Alternative methods for conveying the disclosures MAY be used (such as including them in a </ins> <del> at the top-level of the serialized JWS with a string value containing the Key Binding JWT as described in kb-jwt. </del> <ins> member of an outer JSON structure also containing the JSON Serialized SD-JWT) as dictated by a specific application or transport protocol. However, the details of such approaches fall outside the scope of this specification. </ins> Verification of the JWS JSON serialized SD-JWT follows the same rules defined in verification, except that the SD-JWT does not need to be <del> split into component parts, but disclosures and (if applicable) a Key Binding JWT can be found in the respective members of the JSON object. </del> <ins> split into component parts, the disclosures can be found in the respective member of the JSON object (or elsewhere), and Key Binding (if applicable) will be provided by means not specifically defined in this specification. </ins> Using a payload similar to that from Example 1 [2], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. Below is a non-normative example of a presentation of the JWS JSON <del> serialized SD-JWT, where the Holder includes a Key Binding JWT and has selected to disclose </del> <ins> serialized SD-JWT, where the Holder has selected to disclose </ins> ,
Code change:
-Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses

Related discussion:
text: . <ins> 8. In some applications or transport protocols, it is desirable to encapsulate an SD-JWT into an outer JWT container.  For example, an implementation may enclose multiple credentials and presentations, independent of their format, in a JWT to enable application-layer encryption during transport. For such use cases, a compact serialized SD-JWT SHOULD be included as a single string value and a JSON serialized SD-JWT SHOULD be included as a JSON object value.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT. The following non-normative example payload shows a compact serialized SD-JWT Presentation enveloped in a JWT.  The SD-JWT is shown as the value of an claim where is the Issuer-signed JWT and is a Disclosure.  The SD-JWT does not contain a Key Binding JWT as the outer container can be signed instead. This next non-normative example payload shows a JSON serialized SD- JWT enveloped in a JWT.  The JSON serialized SD-JWT appears as the value of an claim and the disclosures are included separately as a top-level claim.  Key Binding is achieved by the signature on the enclosing JWT. Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple such SD-JWTs into one object and provide Key Binding using means other than the Key Binding JWT. </ins> 9. Security considerations in this section help achieve the following
Code change:
Added JWT claims registration requests to IANA (to fix issue ) URL
This was meant as a placeholder/reminder for JWT Claims Registration requests to IANA that would be needed eventually. The and claims should be registered. I'm not sure about to be honest, which is ironic b/c I'm supposed to know about such things (see the so-called experts ). But it's somewhat different than the other claims in the registry. But, I dunno, requesting registration is probably the way to go w/ .
I share your unsureness, and agree that requesting registration is the way to go. btw in the spec, we have a text registered claim, so if we decide not to register it, that text needs to be updated.
Wait... really, where?
PR has been merged.

Related discussion:
text: 12. <del> TBD </del> 12.1. <ins> This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry IANA.JWT established by RFC7519. 12.2. </ins> 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.
Code change:
Added JWT claims registration requests to IANA (to fix issue ) URL
This was meant as a placeholder/reminder for JWT Claims Registration requests to IANA that would be needed eventually. The and claims should be registered. I'm not sure about to be honest, which is ironic b/c I'm supposed to know about such things (see the so-called experts ). But it's somewhat different than the other claims in the registry. But, I dunno, requesting registration is probably the way to go w/ .
I share your unsureness, and agree that requesting registration is the way to go. btw in the spec, we have a text registered claim, so if we decide not to register it, that text needs to be updated.
Wait... really, where?
PR has been merged.

Related discussion:
text: To indicate that the content is a Key Binding JWT: <del> 12.2. </del> <ins> 12.3. </ins> This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry
Code change:
based roughly on feedback from Anders to draft-ietf-oauth-selective-disclosure-jwt at URL

Related discussion:
text: non-selectively disclosable and hide only the other sub-claims: <del> There would be no Disclosure for </del> <ins> In this case there would be no Disclosure for </ins> <del> in this case. </del> <ins> since it is provided in the clear. </ins> 5.7.3.
Code change:
based roughly on feedback from Anders to draft-ietf-oauth-selective-disclosure-jwt at URL

Related discussion:
text: 11. <del> We would like to thank Alen Horvat, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, 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> 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, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, 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. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
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: 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.