jiebi/CodeConvo huggingface dataset:
Code change:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Related discussion:
text: 8.7. <ins> Holder binding aims to ensure that the presenter of a credential is actually the legitimate Holder of the credential.  There are, in general, two approaches to Holder Binding: Claims-based Holder Binding and Crpytographic Holder Binding. Claims-based Holder Binding means that the Issuer includes claims in the SD-JWT that a Verifier can correlate with the Holder, potentially with the help of other credentials presented at the same time.  For example, in a vaccination certificate, the Issuer can include a claim that contains the Holder's name and birthdate, and a Verifier can correlate this data with the Holder's passport that has to be presented together with the vaccination certificate - either as a digital credential or a physical document. Cryptographic Holder Binding means that the Issuer includes some cryptographic data, usually a public key, belonging to the Holder. The Holder can then sign over some data defined by the Verifier to prove that the Holder is in possession of the private key. Without Holder Binding, a Verifier only gets the proof that the credential was issued by a particular Issuer, but the credential itself can be replayed by anyone who gets access to it.  This means that, for example, after a credential was leaked to an attacker, the attacker can present the credential to any verifier that does not require Holder Binding.  But also a malicious Verifier to which the Holder presented the credential can present the credential to another Verifier if that other Verifier does not require Holder Binding. </ins> Verifiers MUST decide whether Holder Binding is required for a particular use case or not before verifying a credential.  This decision can be informed by various factors including, but not
Code change:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Related discussion:
text: is the actual Holder of the license.  The Verifier (e.g., the software used by the police officer) will ensure that a Holder Binding JWT is present and signed with the Holder's private key. <ins> Claims-based Holder Binding may be used as well, e.g., by including a first name, last name and a date of birth that matches that of an insurance policy paper. </ins> A rental car agency may want to ensure, for insurance purposes, that all drivers named on the rental contract own a government-issued
Code change:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Related discussion:
text: If a Verifier has decided that Holder Binding is required for a particular use case and the Holder Binding is not present, does not fulfill the requirements (e.g., on the signing algorithm), or no <del> recognized key reference is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. </del> <ins> recognized Holder Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. </ins> 8.8.
Code change:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Related discussion:
text: Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. <del> 9.2. </del> <ins> 9.3. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing
Code change:
As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity

Related discussion:
text: digests (or whether to use them at all) is a trade-off between the size of the SD-JWT and the privacy of the End-User's data. <del> 9.3. </del> <ins> 9.4. </ins> Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user
Code change:
for add a bit more context/background to the intro about the indented general applicability of SD-JWT and the relation to JWT and the OAuth WG

Related discussion:
text: Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the contents of the token have not been modified.  However, anyone <del> receiving an unencrypted JWT can read all of the claims and likewise, </del> <ins> receiving an unencrypted JWT can read all the claims and likewise, </ins> anyone with the decryption key receiving an encrypted JWT can also <del> read all of the claims. </del> <ins> read all the claims. </ins> One of the common use cases of a signed JWT is representing a user's identity.  As long as the signed JWT is one-time use, it typically
Code change:
for add a bit more context/background to the intro about the indented general applicability of SD-JWT and the relation to JWT and the OAuth WG

Related discussion:
text: The ability to selectively disclose a subset of these claims depending on the Verifier becomes crucial to ensure minimum disclosure and prevent Verifiers from obtaining claims irrelevant for <del> the transaction at hand. One example of such a multi-use JWT is a verifiable credential, a tamper-evident credential with a cryptographically verifiable authorship that contains claims about a subject.  SD-JWTs defined in this document enable such selective disclosure of claims. </del> <ins> the transaction at hand.  One example of such a multi-use JWT is a verifiable credential, a tamper-evident credential with a cryptographically verifiable authorship that contains claims about a subject. SD-JWTs defined in this document enable such selective disclosure of JWT claims. Similar to the JWT specification on which it builds, this document is a product of the Web Authorization Protocol (oauth) working group. However, while both JWT and SD-JWT have potential OAuth 2.0 applications, their utility and application is certainly not constrained to OAuth 2.0.  JWT was developed as a general-purpose token format and has seen widespread usage in a variety of applications.  SD-JWT is a selective disclosure mechanism for JWT and is similarly intended to be general-purpose specification. </ins> In an SD-JWT, claims can be hidden, but cryptographically protected against undetected modification.  When issuing the SD-JWT to the
Code change:
A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL

Related discussion:
text: The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash <del> Algorithm" registry IANA.Hash.Algorithms. </del> <ins> Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the SHA-256 hash algorithm.
Code change:
A bit more in security considerations for Choice of a Hash Algorithm (1st & 2nd preimage resistant and not majorly truncated) for issue
While looking at this I noticed URL only allows hash algs from the registry. URL removed the JOSE HMAC stuff but also removed allowing the hash alg to be "a value defined in another specification and/or profile of this specification" which I thought we wanted to have - for Christian's type use cases and extensibility in general. This isn't the right place for a discussion but wanted to note it somewhere before our call.
I think we intentionally removed “a value defined in another specification and/or profile of this specification” Because using that would require a separate profile and not just defining an identifier.
from this PR URL

Related discussion:
text: 8.6. For the security of this scheme, the hash algorithm is required to be <del> preimage and collision resistant, i.e., it is infeasible to calculate the salt and claim value that result in a particular digest, and it is infeasible to find a different salt and claim value pair that result in a matching digest, respectively. </del> <ins> preimage resistant and second-preimage resistant, i.e., it is infeasible to calculate the salt and claim value that result in a particular digest, and, for any salt and claim value pair, it is infeasible to find a different salt and claim value pair that result in the same digest, respectively. Hash algorithms that do not meet the aforementioned requirements MUST NOT be used.  Inclusion in the "Named Information Hash Algorithm" registry IANA.Hash.Algorithms alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several heavily truncated digests, such as </ins> <del> Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 </del> <ins> and , which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 </ins> revealed fundamental weaknesses and they MUST NOT be used. 8.7.
Code change:
Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.

Related discussion:
text: This document describes a format for JWTs that support selective disclosure (SD-JWT), enabling sharing only a subset of the claims included in the original JWT instead of releasing all the claims to <del> every verifier.  This document also defines a format for so-called SD-JWT Releases (SD-JWT-R). </del> <ins> every verifier.  During issuance, an SD-JWT is sent from the issuer to the holder alongside an SD-JWT Salt/Value Container (SVC), a JSON object that contains the mapping between raw claim values contained in the SD-JWT and the salts for each claim value. This document also defines a format for SD-JWT Releases (SD-JWT-R), which conveys a subset of the claim values of an SD-JWT that the holder is selectively releasing to the verifier.  During presentation, SD-JWT-R and SD-JWT are both sent to the verifier from the holder.  To verify claim values received in SD-JWT-R, verifier uses salts in SD-JWT-R to compute the hashes of the claim values and compare them to the hashes in SD-JWT. </ins> One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such a use case, there has been no
Code change:
Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.

Related discussion:
text: 2.2. A JSON object created by the issuer that contains mapping between raw <del> claim values that contained in the SD-JWT and the salts for each claim value. </del> <ins> claim values contained in the SD-JWT and the salts for each claim value. </ins> 2.3.
Code change:
Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.

Related discussion:
text: 2.7. <del> An entity that entity that requests, checks and extracts the claims from SD-JWT-R (2.2) </del> <ins> An entity that requests, checks and extracts the claims from SSD- JWT-R (2.2) </ins> Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the
Code change:
When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL

Related discussion:
text: 9. <ins> The privacy principles of ISO.29100 should be adhered to. </ins> 9.1. Wherever End-User data is stored, it represents a potential target
Code change:
When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL

Related discussion:
text: any encryption mechanism. Implementers MUST ensure that the transport protocol provides <del> confidentiality, if the privacy of End-User data or correlation attacks are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT Combined Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. </del> <ins> confidentiality if the privacy of End-User data or correlation attacks by passive observers are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT Combined Format as the plaintext payload of a JWE) to encrypt the SD-JWT and associated Disclosures when transmitted over an insecure channel. </ins> 9.3.
Code change:
When merged, this PR replaces PR and closes Issue . I am not sure what value reference to ISO 27551 brings (+1 to remove it). Unlinkability pairs defined in ISO27551 do not really apply to Issuer-Holder-Verifier model, since they are modelled after User Agent-RP model. and anonymity of the User is out of scope for SD-JWT IMO, but adding one subsection on "User identifier should be chosen to guarantee user anonymity and not only pseudonymity". but feels redundant since SD-JWT is not only for natural persons.. Some of the notions in PR 93 were outdated since claim names are now blinded by default. "Issuer Issuing One Type of SD-JWT" section might be valuable, also confirming with Smart health card community.
the "build" for this PR isn't working URL

Related discussion:
text: To prevent these types of linkability, various methods, including but not limited to the following ones can be used: <ins> 9.5. An Issuer issuing only one type of SD-JWT might have privacy implications, because if the Holder has an SD-JWT issued by that Issuer, its type and claim names can be determined. For example, if the National Cancer Institute only issued SD-JWTs with cancer registry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient. Moreover, the issuer identifier alone may reveal information about the user. For example, when a military organization or a drug rehabilitation center issues a vaccine credential, verifiers can deduce that the holder is a military member or may have a substance use disorder. To mitigate this issue, a group of issuers may elect to use a common Issuer identifier.  A group signature scheme outside the scope of this specification may also be used, instead of an individual signature. </ins> 10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin,
Code change:
Addresses issue . enveloping in a single signed JWT more than one Combined Format for Presentation without a Holder Binding JWT.

Related discussion:
text: belongs to. Other ways of proving Holder Binding MAY be used when supported by <del> the Verifier, e.g., when the Combined Format for Presentation is itself embedded in a signed JWT.  See enveloping for details. </del> <ins> the Verifier, e.g., when the Combined Format for Presentation without a Holder Binding JWT is itself embedded in a signed JWT.  See enveloping for details. </ins> If no Holder Binding JWT is included, the Combined Format for Presentation ends with the
Code change:
Addresses issue . enveloping in a single signed JWT more than one Combined Format for Presentation without a Holder Binding JWT.

Related discussion:
text: not contain a Holder Binding JWT as the outer container can be signed instead. <ins> Other specifications or profiles of this specification may define alternative formats for transporting the Combined Format for Presentation that envelopes multiple such objects into one object, and provides Holder Binding using means other than Holder Binding JWT. </ins> 8. Security considerations in this section help achieve the following
Code change:
Fixes Issue
Thanks NAME I think the two folks should be acknowledged and the small change around the claim incorporated. Then I think this should be merged and we should publish a -04 as basically a bug fix. The issue NAME URL found kinda undermines the whole point of SD-JWT and we should have a published version out that fixes that.
When decoys are used (_sd members not corresponding to a disclosure are added) the says to I imagine this is not intended and the holder should ignore missing disclosures instead? Same in
Actually the following in doesn't make sense to me at all since the whole point is to selectively not release disclosures.
Good point/catch Filip. I think the intent was to say that if a disclosure is found that isn't referenced by a _sd hash value, that should be a rejection. But the language got turned around somewhat. I think anyway. It needs to be fixed or clarified regardless though.
Processing by the Holder: This seems fine to me. In the context, "the digests" refers to "the digests of the Disclosures". If there is a Disclosure that hashes to a digest not found in any _sd array, the SD-JWT is invalid. Maybe we can clarify by modifying this to: Verification by the Verifier: This is wrong and should read "If no such Disclosure can be found, the digests MUST be ignored." Thanks for bringing this up, Filip!
Don't we then also need something at the end of Verification by the Verifier - that makes sure all of the provided disclosures match a digest in the payload and reject if that is not the case or am I missing something here?
That would force the Holder to act correctly, but would it provide any benefit beyond that?
The changes above are included in PR - please review NAME NAME
PR merged

Related discussion:
text: 10. <del> We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, John Mattsson, Matthew Miller, Justin Richer, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> 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, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Code change:
This fixes Issue . The main change is to better describe in which role the adversary acts.
does this one need a doc history entry... ?

Related discussion:
text: Security considerations in this section help achieve the following properties: <ins> An adversary in the role of the Verifier cannot obtain information from an SD-JWT about any claim name or claim value that was not explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT. A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in holder_binding_security, the application of Holder Binding can ensure that the presenter of an SD- JWT credential is the legitimate Holder of the credential. </ins> 8.1. The SD-JWT MUST be signed by the Issuer to protect integrity of the