jiebi/CodeConvo huggingface dataset:
Code change:
would
It seems like it could be helpful to implementors, allowing them to quickly validate whether what they have is syntactically an SD-JWT or an SD-JWT with key binding. Something like:
The actual helpfulness of ABNF IMHO really depends on the readers familiarity with ABNF. I don't know that such familiarity is particularity prevalent. But, as long as it's correct, it doesn't hurt to include either. And while I'm not overly familiar with ABNF myself, I know enough to know that that isn't valid ABNF and doesn't quite correctly convey the SD-JWT constructs. I've endeavored to fix it up but am not 100% sure this is correct either: \ with a bit of help from https://author-URL
Looks good to me, thank you! Maybe a small improvement would be to introduce a name for disclosure?
That's a good improvement, thanks!
Looks good to me, and appears valid according to the .
(SD-JWT-KB part of the ABNF depends on another PR)
need to wait after is resolved to do a PR.
maybe add a KB-JWT line to be even more better? a la:
Not my religion, but happy to celebrate anyway.

Related discussion:
text: a few different SD-JWT permutations, both with and without various constituent parts. <ins> As an alternative illustration of the SD-JWT format, for those who celebrate, ABNF RFC5234 for the SD-JWT, SD-JWT+KB, and various constituent parts is provided here: </ins> 5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's
Code change:
More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

Related discussion:
text: This document also defines a format for SD-JWTs with Key Binding (SD- JWT+KB).  By optionally sending an SD-JWT+KB to a Verifier, the Holder can prove to the Verifier that they hold the private key <del> associated to the SD-JWT (e.g., using the </del> <ins> associated to the SD-JWT (i.e., using the </ins> claim RFC7800).  The strength of the binding is conditional upon the trust in the protection of the private key of the key pair an SD-JWT
Code change:
More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

Related discussion:
text: 5.1.2. If the Issuer wants to enable Key Binding, it includes a public key <del> associated with the Holder, or a reference thereto.  The </del> <ins> associated with the Holder, or a reference thereto, using the </ins> <del> member of the </del> <ins> claim as defined in RFC7800.  The </ins> <del> claim as defined in Section 3.2 of RFC7800 is suggested for doing so, however, other means can be used. </del> <ins> confirmation method, as defined in Section 3.2 of RFC7800, is suggested for doing so, however, other confirmation methods can be used. Note that, as was stated in RFC7800, if an application needs to represent multiple proof-of-possession keys in the same SD-JWT, one way to achieve this is to use other claim names, in addition to , to hold the additional proof-of-possession key information. </ins> It is out of the scope of this document to describe how the Holder key pair is established.  For example, the Holder MAY create a key
Code change:
More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

Related discussion:
text: Note: The examples throughout this document use the <del> claim to include the raw public key by value in SD-JWT. </del> <ins> claim with the member to include the raw public key by value in SD-JWT. </ins> 5.2.
Code change:
More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

Related discussion:
text: presented at the same time, etc. It is important that a Verifier does not make its security policy <del> decisions based on data that can be influenced by an attacker or that can be misinterpreted.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account: </del> <ins> decisions based on data that can be influenced by an attacker.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account whether the Holder has provided an SD-JWT+KB or a bare SD-JWT, since otherwise an attacker could strip the KB-JWT from an SD-JWT+KB and present the resulting SD-JWT. Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether the SD-JWT supports Key Binding or not. </ins> If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or
Code change:
Mr. Heenan suspects he should probably be listed in the SD-JWT acknowledgements section and I don't disagree

Related discussion:
text: 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, Jacob Ward, Jeffrey <del> Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Code change:
to
I was not completely sure either and that's why I posted only the issue and no PR first. I still think that in chapter 5. the extra mentions are confusing as the text and the ABNF are separating the SD-JWT and SD-JWT+KB formats. In contrast, similar explicit mention in the verification section is clarifying to me.
I wasn't sure when first looking at it and actually thing it's okay either way but have come to think it's more okay this way.
The distinguishing of SD-JWT from SD-JWT+KB is a good clarifying change in -09. Some extra mentions of KB-JWT still remain that could probably removed: In : >An SD-JWT without Disclosures and without a KB-JWT and >An SD-JWT with Disclosures and without a KB-JWT The "and without a KB-JWT" could be removed as there are separate examples for SD-JWT+KB and SD-JWT is now defined not to include KB-JWT.
Thanks NAME PR does exactly what you've suggested.
approved the PR () too.
I am not sure these are actually extraneous, but ok looks good

Related discussion:
text: a few different SD-JWT permutations, both with and without various constituent parts. <del> An SD-JWT without Disclosures and without a KB-JWT: </del> <ins> An SD-JWT without Disclosures: </ins> <del> An SD-JWT with Disclosures and without a KB-JWT: </del> <ins> An SD-JWT with Disclosures: </ins> An SD-JWT+KB without Disclosures:
Code change:
BTW NAME please do a quick PR adding yourself to the Acknowledgements section, if you;'d like.
Thanks NAME !

Related discussion:
text: credential to the Issuer.  It is important to note that the timing of such requests could potentially serve as a side-channel. <del> Verifier/Verifier unlinkablility and presentation unlinkablility can be achieved using batch issuance: A batch of credentials based on the </del> <ins> Verifier/Verifier unlinkability and presentation unlinkability can be achieved using batch issuance: A batch of credentials based on the </ins> same claims is issued to the Holder instead of just a single credential.  The Holder can then use a different credential for each Verifier or even for each session with a Verifier.  New key binding
Code change:
Acknowledge Martin Thomson for his contribution: URL
Open for one week. No approvals. No objections. One minor editorial change applied. Will continue to wait.
If this is this acceptable, I love it

Related discussion:
text: and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. <ins> Special appreciation is extended to Martin Thomson, who wielded his considerable intellect and influence to change a single occurrence of the word "to" to "with" in the midst of a significant proposal that would be integrated into this document six months later. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Code change:
Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw. if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition

Related discussion:
text: 6.1. <del> The Issuer is using the following input JWT Claims Set: </del> <ins> The following data about the user comprises the input JWT Claims Set used by the Issuer: </ins> <del> The Issuer in this case made the following decisions: </del> <ins> In this example, the following decisions were made by the Issuer in constructing the SD-JWT: </ins> The following payload is used for the SD-JWT: <del> The following Disclosures are created by the Issuer: </del> <ins> The respective Disclosures are created by the Issuer: </ins> <del> The payload is then signed by the Issuer to create the following JWT: </del> <ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT: </ins> <del> The following is the issued SD-JWT: </del> <ins> Adding the Disclosures produces the SD-JWT: </ins> 6.2.
Code change:
Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw. if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition

Related discussion:
text: have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB. <ins> After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> 7. Being JSON, an object in an SD-JWT payload MAY contain name/value