jiebi/CodeConvo huggingface dataset:
Code change:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Related discussion:
text: <del> SD-JWT: Selective Disclosure for JWT and JWS with JSON payloads </del> <ins> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract
Code change:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Related discussion:
text: the transaction at hand.  SD-JWTs defined in this document enable such selective disclosure of JWT claims. <del> One example of a multi-use JWT is a verifiable credential, an issuer- </del> <ins> One example of a multi-use JWT is a verifiable credential, an Issuer- </ins> signed credential that contains the claims about a subject, and whose authenticity can be cryptographically verified.
Code change:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Related discussion:
text: 6.1. <del> The Holder MUST perform the following (or equivalent) steps when receiving a Combined Format for Issuance: </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT: If any step fails, the SD-JWT is not valid and processing MUST be aborted. </ins> It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed. <ins> 6.2. If a Key Binding JWT is received by a Holder, the SD-JWT SHOULD be rejected. </ins> For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: <del> 6.2. </del> <ins> 6.3. </ins> <del> Upon receiving a Presentation, Verifiers MUST ensure that </del> <ins> Upon receiving a Presentation, in addition to the checks outlined in sd_jwt_verification, Verifiers MUST ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):
Code change:
changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.

Related discussion:
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, Orie Steele, Pieter 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. </del> <ins> Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, 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:
This solves Issue by moving away from an example that wasn't ideal anyway (it encoded a different bytestring for the value Möbius). The Disclosure JSON should be:
"it shows as is there any way to change that..? (this is not the change introduced in this PR)" on the text in the doc at URL "A different way to encode the umlaut (two dots &; placed over the letter):" Originally posted by NAME in URL
Not sure why this broke now. I created a PR because the example wasn't ideal anyway: URL
I just noticed that the PR does not fully solve the problem. We have the same problem somewhere else as well: !
it's seems to have been an issue at least back to -01 URL and/or -02 URL (so basically since inception). I'm sure we could fight with the tool chain to fix it. But at what cost? I'm inclined to just reword that "The two representations... " part to make the issue go away. Which I did with this 48efde35a81ca3520eb30ceea6c43d62e8cd96f8 update to URL
PR merged

Related discussion:
text: <del> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </del> <ins> Selective Disclosure for JWTs (SD-JWT) </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract
Code change:
This solves Issue by moving away from an example that wasn't ideal anyway (it encoded a different bytestring for the value Möbius). The Disclosure JSON should be:
"it shows as is there any way to change that..? (this is not the change introduced in this PR)" on the text in the doc at URL "A different way to encode the umlaut (two dots &; placed over the letter):" Originally posted by NAME in URL
Not sure why this broke now. I created a PR because the example wasn't ideal anyway: URL
I just noticed that the PR does not fully solve the problem. We have the same problem somewhere else as well: !
it's seems to have been an issue at least back to -01 URL and/or -02 URL (so basically since inception). I'm sure we could fight with the tool chain to fix it. But at what cost? I'm inclined to just reword that "The two representations... " part to make the issue go away. Which I did with this 48efde35a81ca3520eb30ceea6c43d62e8cd96f8 update to URL
PR merged

Related discussion:
text: The resulting Disclosure would be: <del> Note that the JSON encoding of the object is not canonicalized, so variations in white space, encoding of Unicode characters, and ordering of object properties are allowed.  For example, the following strings are all valid and encode the same claim value "Moebius": </del> <ins> Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed in the JSON representation and no canonicalization needs be performed before base64url-encoding.  For example, the following strings are all valid and encode the same claim value "Moebius": </ins> See disclosure_format_considerations for some further considerations on the Disclosure format approach.
Code change:
I've seen the "new" title from 332ded8faf20d528c5c05e04cebed28aab1a0d33 a few times in context now and it is really awkward.
yup, that updated intro and abstract text stays
as long as the intro text itself stays as we updated it, this makes sense to me.

Related discussion:
text: <del> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </del> <ins> Selective Disclosure for JWTs (SD-JWT) </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract
Code change:
I noticed that the consolidation of SD-JWT terminology in c6a27373dee13cc7c3f70a8b7fd374e62306f5a0 introduced a mistake in the "Enveloping" section title by including the word "Presentation" while the section talks about enveloping either issued or presented SD-JWTs. While fixing that, I decided to remove the SHOULD recommending the use of an unregistered claim name . I also tried to align the example enveloping payload a bit with a move minimal set of claims similar to those used in key binding. I realize I probably should have just fixed the section title and not expanded the scope of the changes. But there I was and these few little changes were so inviting... See it here: URL

Related discussion:
text: string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT. <del> The claim SHOULD be used when transporting an SD-JWT unless the application or protocol defines a different claim name. </del> The following non-normative example shows an SD-JWT Presentation enveloped in a JWT payload: <del> Here, the SD-JWT is shown where </del> <ins> Here, the SD-JWT is shown as the value of an claim where </ins> represents the Issuer-signed JWT and
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: 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:
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: Note: Examples in this document use the <del> Claim defined in RFC7800 to include the raw public key by value in </del> <ins> claim defined in RFC7800 to include the raw public key by value in </ins> SD-JWT. 5.10.
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: 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:
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: 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> <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.
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: 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> <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.