jiebi/CodeConvo huggingface dataset:
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
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
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.
claims.  This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT. <ins> 8.9. This specification does not define how signature verification keys of Issuers are distributed to Verifiers.  However, it is RECOMMENDED that Issuers publish their keys in a way that allows for efficient and secure key rotation and revocation, for example, by publishing keys at a predefined location using the JSON Web Key Set (JWKS) format RFC7517.  Verifiers need to ensure that they are not using expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method. </ins> 9. 9.1. <ins> Wherever End-User data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national identity service.  For example, in OpenID Connect, signed ID Tokens can be stored by Relying Parties.  In the case of SD-JWT, Holders have to store signed SD-JWTs and associated Disclosures, and Issuers and Verifiers may decide to do so as well. Not surprisingly, a leak of such data risks revealing private data of End-Users to third parties.  Signed End-User data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in holder_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Holder Binding is enforced and the attacker does not have access to the Holder's cryptographic keys.  Altogether, leaked SD-JWT credentials may have a high monetary value on black markets. Due to these risks, systems implementing SD-JWT SHOULD be designed to minimize the amount of data that is stored.  All involved parties SHOULD store SD-JWTs only for as long as needed, including in log files. Issuers SHOULD NOT store SD-JWTs after issuance. Holders SHOULD store SD-JWTs and associated Disclosures only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Holder Binding key. Decentralized storage of data, e.g., on End-User devices, SHOULD be preferred for End-User credentials over centralized storage.  Expired SD-JWTs SHOULD be deleted as soon as possible. Verifiers SHOULD NOT store SD-JWTs after verification.  It may be sufficient to store the result of the verification and any End-User data that is needed for the application. If reliable and secure key rotation and revocation is ensured according to issuer_signature_key_distribution, Issuers may MAY opt to publish expired or revoked private signing keys (after a grace period that ensures that the keys are not cached any longer at any Verifier).  This reduces the value of any leaked credentials as the signatures on them can no longer be trusted to originate from the Issuer. 9.2. </ins> If the SD-JWT and associated Disclosures are transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the End-User's personal data or correlate
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
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
5.2.1.4. An SD-JWT is a JWT that MUST be signed using the Issuer's private <del> key. </del> <ins> key.  It MUST use a JWS asymmetric digital signature algorithm and MUST NOT use or an identifier for a symmetric algorithm (MAC). </ins> An SD-JWT MAY contain both selectively disclosable claims and non- selectively disclosable claims, i.e., claims that are always
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.
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
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.
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,
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
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.
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
expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method. <ins> 8.9. When Holder Binding is not enforced, any entity in possession of a Combined Format for Presentation can forward the contents to third parties.  When doing so, that entity may remove Disclosures such that the receiver learns only a subset of the claims contained in the original Combined Format for Presentation. For example, a device manufacturer might produce an SD-JWT containing information about upstream and downstream supply chain contributors. Each supply chain party can verify only the claims that were selectively disclosed to them by an upstream party, and they can choose to further reduce the disclosed claims when presenting to a downstream party. In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding. </ins> 9. The privacy principles of ISO.29100 should be adhered to.
TBD <del> @VC_JWT </del> <ins> 11.1. This section requests registration of the "application/sd-jwt" media type RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838, which can be used to indicate that the content is an SD-JWT. 11.2. This section requests registration of the "+sd-jwt" structured syntax suffix in the "Structured Syntax Suffix" registry IANA.StructuredSuffix in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT. </ins>
4.3. <del> Holder Binding is an optional feature.  For example, when Cryptographic Holder Binding is required by the use-case, the SD-JWT must contain information about the key material controlled by the Holder. </del> <ins> Holder Binding is an optional feature.  When Cryptographic Holder Binding is required by the use-case, the SD-JWT MUST contain information about the key material controlled by the Holder. </ins> Note: How the public key is included in SD-JWT is out of scope of this document.  It can be passed by value or by reference. <del> The Holder can then create a signed document, the Holder Binding JWT, using its private key.  This document contains some data provided by the Verifier (out of scope of this document) to ensure the freshness of the signature, for example, a nonce and an indicator of the intended audience for the document. </del> <ins> The Holder can then create a signed document, the Holder Binding JWT as defined in hb-jwt, using its private key.  This document contains some data provided by the Verifier such as a nonce to ensure the freshness of the signature, and audience to indicate the intended audience for the document. </ins> The Holder Binding JWT can be included in the Combined Format for Presentation and sent to the Verifier along with the SD-JWT and the
5.4.1. The Holder MAY add an optional JWT to prove Holder Binding to the <del> Verifier.  The precise contents of the JWT are out of scope of this specification.  Usually, a </del> <ins> Verifier. 5.4.1.1. This section defines the contents of the Holder Binding JWT. The JWT MUST contain the following elements: * in the JOSE header, * : REQUIRED.  MUST be , which explicitly types the Holder Binding JWT as recommended in Section 3.11 of RFC8725.  * : REQUIRED.  A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry.  MUST NOT be or an identifier for a symmetric algorithm (MAC).  * in the JWT body, * : REQUIRED.  The value of this claim MUST be the time at which the Holder Binding JWT was issued using the syntax defined in RFC7519.  * : REQUIRED.  The intended receiver of the Holder Binding JWT.  How the value is represented is up to the protocol used and out of scope of this specification.  * : REQUIRED.  Ensures the freshness of the signature.  The value type of this claim MUST be a string.  How this value is obtained is up to the protocol used and out of scope of this specification. To validate the signature on the Holder Binding JWT, the Verifier MUST use the key material in the SD-JWT.  If it is not clear from the SD-JWT, HB-JWT MUST specify which key material the Verifier needs to use to validate HB-JWT using JOSE header parameters such as </ins> and <del> claim are included to show that the proof is intended for the Verifier and to prevent replay attacks.  How the </del> <ins> . </ins> <del> or other claims are obtained by the Holder is out of scope of this specification. </del> <ins> Below is a non-normative example of a Holder Binding JWT header: </ins> <del> Example Holder Binding JWT payload: </del> <ins> Below is a non-normative example of a Holder Binding JWT payload: </ins> <del> Which is then signed by the Holder to create a JWT like the following: </del> <ins> Below is a non-normative example of a Holder Binding JWT produced by signing a payload in the example above: </ins> Whether to require Holder Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it
8.2. Holders can manipulate the Disclosures by changing the values of the <del> claims before sending them to the Issuer.  The Issuer MUST check the Disclosures to ensure that the values of the claims are correct, </del> <ins> claims before sending them to the Verifier.  The Verifier MUST check the Disclosures to ensure that the values of the claims are correct, </ins> i.e., the digests of the Disclosures are actually present in the signed SD-JWT.
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 <del> 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> 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. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
In some scenarios this behavior could be desirable, but if it is not, Issuers need to support and Verifiers need to enforce Holder Binding. <ins> 8.10. Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the header parameter when the SD-JWT is issued, and for Verifiers to check this value. When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.  The definition of in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter. </ins> 9. The privacy principles of ISO.29100 should be adhered to.
<del> Selective Disclosure for JWTs (SD-JWT) </del> <ins> SD-JWT: Selective Disclosure for JWT and JWS with JSON payloads </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract <del> This document specifies conventions for creating JSON Web Token (JWT) documents that support selective disclosure of JWT claims. </del> <ins> This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure.  It encompasses various applications, including but not limited to the selective disclosure of JSON Web Tokens (JWT) claims. </ins> 1. <del> The JSON-based RFC8259 representation of claims in a signed JSON Web Token (JWT) RFC7519 is secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </del> <ins> This document specifies conventions for creating JSON Web Signature (JWS) RFC7515 structures with JSON RFC8259 objects as the payload while supporting selective disclosure of individual elements of that JSON.  Because JSON Web Token (JWT) RFC7519 is a very prevalent application of JWS with a JSON payload, the selective disclosure of JWT claims receives primary treatment herein.  However, that does not preclude the mechanism's applicability to other or more general applications of JWS with JSON payloads. The JSON-based representation of claims in a signed JWT is secured against modification using JWS digital signatures.  A consumer of a signed JWT that has checked the signature can safely assume that the </ins> contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all the claims.  Likewise, anyone with the decryption key receiving encrypted JWT can also read
The claim indicates the hash algorithm used by the Issuer to generate the <del> digests over the salts and the claim values.  If the </del> <ins> digests.  When used, this claim MUST appear at the top level of the SD-JWT payload.  It MUST NOT be used in any object nested within the payload.  If the </ins> <del> claim is not present, a default value of </del> <ins> claim is not present at the top level, a default value of </ins> <del> is used. </del> <ins> MUST be used. </ins> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash