jiebi/TextFlow huggingface dataset:
Original text:
Note: Examples in this document use the <del> Claim defined in RFC7800 to include the raw public key by value in </del>  SD-JWT. 5.10.

Reviewer comments:
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

Revised text:
Note: Examples in this document use the  <ins> claim defined in RFC7800 to include the raw public key by value in </ins> SD-JWT. 5.10.
Original text:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification.  9.7. SD-JWT ensures that names of claims that are selectively disclosable

Reviewer comments:
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

Revised 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
Original text:
Implementers MUST ensure that the transport protocol provides confidentiality if the privacy of End-User data or correlation <del> attacks by passive observers are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT as the plaintext payload of a JWE) to encrypt the SD-JWT when transmitted over an insecure channel. </del>  10.3.

Reviewer comments:
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

Revised text:
Implementers MUST ensure that the transport protocol provides confidentiality if the privacy of End-User data or correlation  <ins> attacks by passive observers are a concern. To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use JSON Web Encryption (JWE) RFC7516 by nesting the SD-JWT as the plaintext payload of a JWE.  Especially, when an SD-JWT is transmitted via a URL and information may be stored/cached in the browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. </ins> 10.3.
Original text:
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, <del> Matthew Miller, Mike Jones, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del>  The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Reviewer comments:
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

Revised text:
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,  <ins> Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Original text:
[1] #example-1 [2] #example-1 

Reviewer comments:
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

Revised text:
[1] #example-1 [2] #example-1 <ins> [3] #enveloping </ins>
Original text:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification.  9.7. SD-JWT ensures that names of claims that are selectively disclosable

Reviewer comments:
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.

Revised 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
Original text:
5.5. <del> This example uses the following object as the set of claims that the Issuer is issuing: </del>  <del> The following non-normative example shows a payload of an SD-JWT for this End-User data: </del>  The Issuer in this case made the following decisions: <del> The Issuer creates the following Disclosures: </del>  The payload is then signed by the Issuer to create a JWT like the following:

Reviewer comments:
replaces , addressing issue I also cleaned up example structure, so that it is the same and uses the same language across multiple examples.

Revised text:
5.5.  <ins> In this example, a simple SD-JWT is demonstrated. </ins>  <ins> The Issuer is using the following input claim set: </ins> The Issuer in this case made the following decisions:  <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:
Original 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>  An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.

Reviewer comments:
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.

Revised text:
Each digest value ensures the integrity of, and maps to, the respective Disclosure.  Digest values are calculated using a hash  <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.
Original 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>  Note: The examples in this document use the

Reviewer comments:
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.

Revised text:
associated with the Holder, or a reference thereto. It is out of the scope of this document to describe how the Holder  <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
Original 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>  Here, the SD-JWT is shown as the value of an

Reviewer comments:
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.

Revised text:
instead of including a separate Key Binding JWT in the SD-JWT. The following non-normative example shows an SD-JWT Presentation  <ins> enveloped in a JWT: </ins> Here, the SD-JWT is shown as the value of an
Original 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>  other than the Key Binding JWT. 8.

Reviewer comments:
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.

Revised text:
Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple  <ins> such objects into one object, and provide Key Binding using means </ins> other than the Key Binding JWT. 8.
Original 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>  post-quantum algorithms, when they are ready. 9.2.

Reviewer comments:
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.

Revised text:
verified. The security of the Issuer-signed JWT depends on the security of the  <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.
Original 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>  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>  5.7.1.

Reviewer comments:
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

Revised text:
disclosable claims MAY even appear within other Disclosures. The following examples illustrate some of the options an Issuer has.  <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:  <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.
Original 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>  at the top-level of the JSON object (the same level as the

Reviewer comments:
-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

Revised text:
7.  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.  <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