jiebi/CodeConvo huggingface dataset:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by The OAuth 2.0 Authorization Framework RFC6749. </del> <ins> denotes the URL-safe base64 encoding without padding defined in Section 2 of RFC7515. </ins> 2. <ins> Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the actor. Note: noneed to define anymore? </ins> 3. <del> In the following, the concept of SD-JWSs and matching proofs is described on a conceptual level. </del> <ins> In the following section, the concepts of SD-JWTs and releases are described at a conceptual level. </ins> 3.1. <del> An SD-JWS, at its core, is a signed document containing some metadata, the holder's public key, and hashed and salted claims.  It is signed using the issuer's private key. </del> <ins> An SD-JWS, at its core, is a digitally signed document containing hashes over the claim values with unique salts, optionally the holder's public key and other metadata.  It is digitally signed using the issuer's private key. </ins> <del> is usually a simple object with claim names mapped to salted and hashed claim values: </del> <ins> is usually a simple object with claim names mapped to hashes over the claim values with unique salts: </ins> can also be nested deeper to capture more complex objects, as will be shown later. <ins> The SD-JWT is sent from the issuer to the holder, together with the mapping of the plain-text claim values, the salt values, and potentially some other information. </ins> 3.2. <del> For a proof, a holder releases a document such as the following to the verifier: </del> <ins> To release to a verifier a subset of SD-JWT claim values, a holder creates a JWS such as the following: Note that the signature over is optional and required if, and only if, holder binding is desired. </ins> is usually a simple object with claim names mapped to values and salts:
7.1. <ins> ToDo: add text explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT: - create a test suite that forces hash computation by the Verifiers, and includes negative test cases in test vectors - use only implementations/libraries that are compliant to the test suite - etc. 7.2. </ins> The SD-JWT MUST be signed by the issuer to protect integrity of the issued claims.  An attacker can modify or add claims if an SD-JWT is not signed (e.g., change the "email" attribute to take over the
it is not practical for the attacker to guess.  Each salt value MUST be unique. <del> 7.3. </del> <ins> 7.4. </ins> The length of the randomly-generated portion of the salt MUST be at least 128 bits. <del> 7.4. </del> <ins> 7.5. </ins> For the security of this scheme, the hash function is required to be preimage and collision resistant, i.e., it is infeasible to calculate
9. <del> We would like to thank ... </del> <ins> We would like to thank Alen Horvat, Brian Campbell, Christian Paquin, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway. </ins> 10.
pair to the issuer, the issuer MAY create the key pair for the holder, or holder and issuer MAY use pre-established key material. <del> Note: need to define how holder public key is included, right now examples are using </del> <ins> Note: Examples in this document use </ins> <del> I think. </del> <ins> Claim defined in RFC7800 to include raw public key by value in SD- JWT. </ins> 5.2.
guess.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. <del> The issuer MUST build the digests by hashing over a string that is formed by JSON-encoding an ordered array containing the salt and the claim value, e.g.: </del> <ins> The issuer MUST build the digests by hashing over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following contents: The following is an example for a JSON literal without claim name blinding: </ins> <del> . The digest value is then base64url-encoded.  Note that the precise JSON encoding can vary, and therefore, the JSON encodings MUST be sent to the holder along with the SD-JWT, as described below. </del> <ins> The following is an example for a JSON literal with claim name blinding: IMPORTANT: JSON encoding according to RFC8259 allows for white space characters and other variations in the encoded representation.  To ensure that issuer and verifier produce the same hash digest, the issuer therefore sends the JSON literal to the holder along with the SD-JWT, as described below. The claim contains an object where claim names are mapped to the respective digests.  If a claim name is to be blinded, the digests MUST contain the key as described above and the claim name in MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the SVC and SD-JWT-R described below. </ins> 5.1.1.1.
The SVC for Example 1 is as follows: Important: As described above, hash digests are calculated over the <del> string formed by serializing a JSON array containing the salt and the claim value.  This ensures that issuer and verifier use the same input to their hash functions and avoids issues with canonicalization of JSON values that would lead to different hash digests.  The SVC therefore maps claim names to JSON-encoded arrays. </del> <ins> JSON literal formed by serializing an object containing the salt, the claim value, and optionally the claim name.  This ensures that issuer and verifier use the same input to their hash functions and avoids issues with canonicalization of JSON values that would lead to different hash digests.  The SVC therefore maps claim names to JSON- encoded arrays. </ins> 5.5.
TBD <ins> 7.7. Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim names accordingly.  It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded claim name to the verifier.  It is therefore RECOMMENDED to ensure that the order is shuffled or otherwise hidden (e.g., alphabetically ordered using the blinded claim names). </ins> 8. 8.1. <del> Claim names are not hashed in the SD-JWT and are used as keys in a key-value pair, where the value is the hash.  This is because SD-JWT already reveals information about the issuer and the schema, and revealing the claim names does not provide any additional information. </del> <ins> By default, claim names are not blinded in an SD-JWT.  In this case, even when the claim's value is not known to a verifier, the claim name can disclose some information to the verifier.  For example, if the SD-JWT contains a claim named , the verifier might assume that the end-user is a member of the Super Secret Club. Blinding claim names can help to avoid this potential privacy issue. In many cases, however, verifiers can already deduce this or similar information just from the identification of the issuer and the schema used for the SD-JWT.  Blinding claim names might not provide additional privacy if this is the case. </ins> 8.2.
1. <del> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </del> <ins> The JSON-based 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 contents of the token have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> This document describes a format for signed JWTs that supports selective disclosure (SD-JWT), enabling sharing only a subset of the
4.1. An SD-JWT, at its core, is a digitally signed document containing <del> hash digests over the claim values with unique random salts and other </del> <ins> hash digests over the claim values with random salts and other </ins> metadata.  It MUST be digitally signed using the issuer's private key. <del> can be a simple object with claim names mapped to hash digests over the claim values with unique random salts: </del> <ins> is an object with claim names mapped to the digests over the claim values with random salts calculated using digest derivation function such as hash function, HMAC, or other: </ins> The claim name (
. <del> The issuer MUST choose a unique and cryptographically random salt value for each claim value.  Each salt value SHOULD contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be encoded as a string.  It is </del> <ins> The issuer MUST choose a cryptographically random salt value for each claim value.  The salt value MUST then be encoded as a string.  It is </ins> RECOMMENDED to base64url-encode the salt value. The issuer MUST build the digests by hashing over a JSON literal
The claim <del> indicates the hash algorithm used by the Issuer to generate the hashes of the salted claim values.  The hash algorithm identifier MUST be a value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry [IANA.Hash.Algorithms].  SD-JWTs with hash algorithm identifiers not found in this registry are not considered valid and MUST NOT be accepted by verifiers. </del> <ins> indicates the hash algorithm function used by the Issuer to generate the hashes over the random values and the claim values. The hash algorithm identifier MUST be a value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry [IANA.Hash.Algorithms] or HMAC algorithms in "Algorithmn Name" column in the IANA "JSON Web Signature and Encryption Algorithms" registry [IANA.JWS.Algorithms]. </ins> To promote interoperability, implementations MUST support the SHA-256 <del> hash algorithm. </del> <ins> hash algorithm.  Other specifications and/or profiles of this specification may register additional algorithm identifiers. See security_considerations for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash function. </ins> 5.1.3.
guessed by the attacker.  It is vitally important to adhere to this principle.  As such, the salt MUST be created in such a manner that it is cryptographically random, long enough and has high entropy that <del> it is not practical for the attacker to guess.  Each salt value MUST be unique. </del> <ins> it is not practical for the attacker to guess.  A new random value MUST be chosen for each claim. </ins> 7.4. <del> The length of the randomly-generated portion of the salt MUST be at least 128 bits. </del> <ins> The RECOMMENDED length of the randomly-generated portion of the salt is at least 128 bits. </ins> 7.5.
Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim <del> names accordingly.  It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. </del> <ins> names accordingly. It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. </ins> The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded
1. <del> The JSON-based content of signed JSON Web Token (JWT) as defined in RFC7515 is secured against modification using digital signatures.  A consumer of a JWT that has checked the document's signature can safely assume that the content has not been modified.  However, anyone receiving a JWT can read the actual content of the document if not encrypted. </del> <ins> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> This document describes a format for JWT that supports selective disclosure (SD-JWT) which would enable sharing only subset of the
MUST be used by the issuer to include digests of the salted claim values for any claim that is intended to be selectively disclosable. <del> The issuer MUST choose a cryptographically random salt value for each claim value.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. </del> <ins> The issuer MUST choose a random salt value for each claim.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See salt-minlength for further requirements. </ins> The issuer MUST generate the digests over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following
key as described above and the claim name in <del> MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the II-Disclosures and HS-Disclosures described below. </del> <ins> MUST be replaced by a placeholder name that does not leak information about the claim's original name.  The same placeholder name will be used in the II-Disclosures ( ) and HS-Disclosures ( ) described below. To this end, the issuer MUST choose a random placeholder name for each claim that is to be blinded.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See blinding- claim-names for further requirements. </ins> 5.2.1.1.
7.4. <del> The RECOMMENDED length of the randomly-generated portion of the salt is at least 128 bits. </del> <ins> The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits. </ins> Note that minimum 128 bits would be necessary when SHA-256, HMAC- SHA256, or a function of similar strength is used, but a smaller salt size might achieve similar level of security if a stronger iterative derivation function is used. <ins> The issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT.  This can be seen in Example 3 in the Appendix, where multiple claims with the name appear, but each of them has a different salt. </ins> 7.5. For the security of this scheme, the digest derivation algorithm is
7.7. <del> Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim names accordingly. </del> <ins> It is RECOMMENDED to use cryptographically random numbers with at least 128 bits of entropy as placeholder claim names. With the approach chosen in this specification, claim names of objects that are not themselves selectively disclosable are not blinded.  This can be seen in Example 6 in the Appendix, where even in the blinded SD-JWT, </ins> <del> It is RECOMMENDED to use cryptographically salts with at least 128 bits of entropy as placeholder claim names. </del> <ins> and are visible.  This limitation needs to be taken into account by issuers when creating the structure of the SD-JWT. The issuer MUST ensure that a new random placeholder name is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT.  This can be seen in Example 6 in the Appendix, where multiple claims with same name appear below and , but each of them has a different blinded claim name.  For each credential issued, new random placeholder names MUST be chosen by the issuer. </ins> The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded
2. <ins> 2.1. A JWT RFC7515 created by the issuer, which can be signed as a JWS RFC7515, that supports selective disclosure as defined in this document. 2.2. A JSON object created by the issuer that contains mapping between raw claim values that contained in the SD-JWT and the salts for each claim value. 2.3. A JWT created by the holder that contains a subset of the claim values of an SD-JWT in a verifiable way. 2.4. Ability of the holder to prove legitimate possession of SD-JWT by proving control over the same private key during the issuance and presentation.  SD-JWT signed by the issuer contains a public key or a reference to a public key that matches to the private key controlled by the holder. 2.5. An entity that creates SD-JWTs (2.1). 2.6. An entity that received SD-JWTs (2.1) from the issuer and has control over them. 2.7. An entity that 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 actor. <del> Note: noneed to define </del> <ins> Note: no need to define </ins> anymore?
4.4. <del> The following shows the contents of a release document for Example 1: </del> <ins> The following shows the contents of an SD-JWT-R for Example 1: </ins> For each claim, an array of the salt and the claim value is contained in the object. <del> Again, the release document follows the same structure as the </del> <ins> Again, the SD-JWT-R follows the same structure as the </ins> <del> in the SD-JWT.  For Example 2, a release document limiting </del> <ins> in the SD-JWT.  For Example 2, a SD-JWT-R limiting </ins> to
only could look as follows: <del> The SD-JWT Release MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </del> <ins> The SD-JWT-R MAY contain further claims, for example, to ensure a binding to a concrete transaction (in the example the </ins> and claims). <del> If holder binding is desired, the SD-JWT Release is signed by the holder.  If no holder binding is to be used, the </del> <ins> If holder binding is desired, the SD-JWT-R is signed by the holder. If no holder binding is to be used, the </ins> algorithm is used, i.e., the document is not signed.
Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user on the basis of unique values encoded in the SD-JWT (Issuer <del> signature, salts, digests, etc.).  More advanced cryptographic schemes, outside the scope of this specification, can be used to prevent this type of linkability. </del> <ins> signature, salts, digests, etc.). To prevent these types of linkability, various methods, including but not limited to the following ones can be used: </ins> 9. <del> We would like to thank Alen Horvat, Brian Campbell, Christian Paquin, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Shawn Butterfield, and Torsten Lodderstedt 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, Brian Campbell, Christian Paquin, David Bakker, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt 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.
disclosure (SD-JWT) which would enable sharing only subset of the claims included in the original JWT instead of releasing all the claims to every Verifeir.  This document also defines an optional <del> format for signatures called releases (SD-JWT-R). </del> <ins> format for signatures called SD-JWT Releases (SD-JWT-R). </ins> One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such use case, there has been no
verifier.  However, when a signed JWT is intended to be multi-use, the ability to selectively disclose a subset of the claims depending on the verifier becomes crucial to ensure minimum disclosure and <del> prevent verifier from obtaining claims irrelevant for the use case at hand. </del> <ins> prevent verifier from obtaining claims irrelevant for the transaction at hand. </ins> One example of such a multi-use JWT is a verifiable credential, or a tamper-evident credential with a cryptographically verifiable
The issuer MUST choose a unique salt value for each claim value. Each salt value MUST contain at least 128 bits of pseudorandom data, making it hard for an attacker to guess.  The salt value MUST then be <del> encoded as a string.  It is RECOMMENDED to base64url encode at least </del> <ins> encoded as a string.  It is RECOMMENDED to base64url-encode at least </ins> 16 pseudorandom bytes. The issuer MUST build the hashes by hashing over a string that is
10. We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin, <del> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, 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. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.