jiebi/CodeConvo huggingface dataset:
6.1. <del> The Holder MUST perform the following (or equivalent) steps when receiving a Combined Format for Issuance: </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT: If any step fails, the SD-JWT is not valid and processing MUST be aborted. </ins> It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed. <ins> 6.2. If a Key Binding JWT is received by a Holder, the SD-JWT SHOULD be rejected. </ins> For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: <del> 6.2. </del> <ins> 6.3. </ins> <del> Upon receiving a Presentation, Verifiers MUST ensure that </del> <ins> Upon receiving a Presentation, in addition to the checks outlined in sd_jwt_verification, Verifiers MUST ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):
We would like to thank Alen Horvat, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, <del> Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
The resulting Disclosure would be: <del> Note that the JSON encoding of the object is not canonicalized, so variations in white space, encoding of Unicode characters, and ordering of object properties are allowed.  For example, the following strings are all valid and encode the same claim value "Moebius": </del> <ins> Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed in the JSON representation and no canonicalization needs be performed before base64url-encoding.  For example, the following strings are all valid and encode the same claim value "Moebius": </ins> See disclosure_format_considerations for some further considerations on the Disclosure format approach.
string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT. <del> The claim SHOULD be used when transporting an SD-JWT unless the application or protocol defines a different claim name. </del> The following non-normative example shows an SD-JWT Presentation enveloped in a JWT payload: <del> Here, the SD-JWT is shown where </del> <ins> Here, the SD-JWT is shown as the value of an claim where </ins> represents the Issuer-signed JWT and
5.5. <del> This example uses the following object as the set of claims that the Issuer is issuing: </del> <ins> In this example, a simple SD-JWT is demonstrated. </ins> <del> The following non-normative example shows a payload of an SD-JWT for this End-User data: </del> <ins> The Issuer is using the following input claim set: </ins> The Issuer in this case made the following decisions: <del> The Issuer creates the following Disclosures: </del> <ins> The following payload is used for the SD-JWT: The following Disclosures are created by the Issuer: </ins> The payload is then signed by the Issuer to create a JWT like the following:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. <ins> 9.6.1. Issuer provided integrity protection of the SD-JWT payload and Disclosures is achieved by the signature on the Issuer-signed JWT that covers the SD-JWT payload including the digest values of the Disclosures as described in sec-is-jwt and sec-disclosures, respectively.  The Key Binding JWT, defined in kb-jwt, serves exclusively as a mechanism for the Holder to demonstrate possession of the private key corresponding to the public key in the SD-JWT payload.  As such, the signature on the Key Binding JWT does not cover other parts of the SD-JWT.  In cases where it's desirable for the Holder's signature to convey more than a proof-of-possession, such as signing over the selected Disclosures to prove those were the Disclosures selected, the SD-JWT to be presented can be embedded in another JWT (as described in Enveloping SD-JWTs [3]) or otherwise signed by the Holder via the application protocol delivering it. </ins> 9.7. SD-JWT ensures that names of claims that are selectively disclosable
Implementers MUST ensure that the transport protocol provides confidentiality if the privacy of End-User data or correlation <del> attacks by passive observers are a concern.  Implementers MAY define an envelope format (such as described in enveloping or nesting the SD-JWT as the plaintext payload of a JWE) to encrypt the SD-JWT when transmitted over an insecure channel. </del> <ins> attacks by passive observers are a concern. To encrypt the SD-JWT when transmitted over an insecure channel, implementers MAY use JSON Web Encryption (JWE) RFC7516 by nesting the SD-JWT as the plaintext payload of a JWE.  Especially, when an SD-JWT is transmitted via a URL and information may be stored/cached in the browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. </ins> 10.3.
We would like to thank Alen Horvat, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, <del> Matthew Miller, Mike Jones, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
Each digest value ensures the integrity of, and maps to, the respective Disclosure.  Digest values are calculated using a hash <del> function over the Disclosures, each of which contains a random salt, the claim name (only when the claim is an object property), and the claim value.  The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in sd-jwt-structure. </del> <ins> function over the Disclosures, each of which contains a cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value.  The Disclosures are sent to the Holder as part of the SD-JWT in the format defined in sd-jwt-structure. </ins> An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.
associated with the Holder, or a reference thereto. It is out of the scope of this document to describe how the Holder <del> key pair is established.  For example, the Holder MAY provide a key 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> <ins> key pair is established.  For example, the Holder MAY create a key pair and provide a public key to the Issuer, the Issuer MAY create the key pair for the Holder, or Holder and Issuer MAY use pre- established key material. </ins> Note: The examples in this document use the
verified. The security of the Issuer-signed JWT depends on the security of the <del> signature algorithm.  Any of the JSON Web Signature and Encryption Algorithms registered in IANA.JWS.Algorithms can be used, including </del> <ins> signature algorithm.  Any of the JWS asymmetric digital signature algorithms registered in IANA.JWS.Algorithms can be used, including </ins> post-quantum algorithms, when they are ready. 9.2.
Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn <del> Butterfield, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> 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.
disclosable claims MAY even appear within other Disclosures. The following examples illustrate some of the options an Issuer has. <del> It is up to the Issuer to decide which option to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or ecosystem requirements.  For more examples with nested structures, see example-simple_structured and example-complex-structured-sd-jwt. </del> <ins> It is up to the Issuer to decide which structure to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or ecosystem requirements.  For more examples with nested structures, see example-simple_structured and example-complex-structured-sd-jwt. </ins> The following input claim set is used as an example throughout this section: <del> Important: Throughout the examples in this document, line breaks had to be added to JSON strings and base64-encoded strings (as shown in the next example) to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks in strings. </del> <ins> Important: The following examples of the structures are non-normative and are not intended to represent all possible options.  They are also not meant to define or restrict how can be represented in an SD-JWT. Note: Throughout the examples in this document, line breaks had to be added to JSON strings and base64-encoded strings (as shown in the next example) to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks in strings. </ins> 5.7.1.
7. <del> In some applications or transport protocols, it is desirable to put an SD-JWT into an outer JWT container.  For example, an implementation may envelope multiple credentials and presentations, independent of their format, in a JWT to enable application-layer encryption during transport. For such use cases, the SD-JWT SHOULD be transported as a single string.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT in the SD-JWT. The following non-normative example shows an SD-JWT Presentation enveloped in a JWT: Here, the SD-JWT is shown as the value of an claim where represents the Issuer-signed JWT and represents a Disclosure.  The SD-JWT does not contain a Key Binding JWT as the outer container can be signed instead. Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple such objects into one object and provide Key Binding using means other than the Key Binding JWT. 8. </del> This section describes an optional alternate format for SD-JWT using the JWS JSON Serialization from RFC7515. For both the General and Flattened JSON Serialization, the SD-JWT is represented as a JSON object according to Section 7.2 of RFC7515. <del> The disclosures (both for issuance and presentation) are included in the serialized JWS using the key </del> <ins> The disclosures (both for issuance and presentation) SHOULD be included in the serialized JWS using the member name </ins> at the top-level of the JSON object (the same level as the
Disclosure as described in creating_disclosures.  The Issuer includes a Disclosure for each selectively disclosable claim of the SD-JWT payload, whereas the Holder includes only the Disclosures selected <del> for the given presentation.  Additionally, for presentation with a Key Binding, the Holder adds the key </del> <ins> for the given presentation. Alternative methods for conveying the disclosures MAY be used (such as including them in a </ins> <del> at the top-level of the serialized JWS with a string value containing the Key Binding JWT as described in kb-jwt. </del> <ins> member of an outer JSON structure also containing the JSON Serialized SD-JWT) as dictated by a specific application or transport protocol. However, the details of such approaches fall outside the scope of this specification. </ins> Verification of the JWS JSON serialized SD-JWT follows the same rules defined in verification, except that the SD-JWT does not need to be <del> split into component parts, but disclosures and (if applicable) a Key Binding JWT can be found in the respective members of the JSON object. </del> <ins> split into component parts, the disclosures can be found in the respective member of the JSON object (or elsewhere), and Key Binding (if applicable) will be provided by means not specifically defined in this specification. </ins> Using a payload similar to that from Example 1 [2], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. Below is a non-normative example of a presentation of the JWS JSON <del> serialized SD-JWT, where the Holder includes a Key Binding JWT and has selected to disclose </del> <ins> serialized SD-JWT, where the Holder has selected to disclose </ins> ,
. <ins> 8. In some applications or transport protocols, it is desirable to encapsulate an SD-JWT into an outer JWT container.  For example, an implementation may enclose multiple credentials and presentations, independent of their format, in a JWT to enable application-layer encryption during transport. For such use cases, a compact serialized SD-JWT SHOULD be included as a single string value and a JSON serialized SD-JWT SHOULD be included as a JSON object value.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT. The following non-normative example payload shows a compact serialized SD-JWT Presentation enveloped in a JWT.  The SD-JWT is shown as the value of an claim where is the Issuer-signed JWT and is a Disclosure.  The SD-JWT does not contain a Key Binding JWT as the outer container can be signed instead. This next non-normative example payload shows a JSON serialized SD- JWT enveloped in a JWT.  The JSON serialized SD-JWT appears as the value of an claim and the disclosures are included separately as a top-level claim.  Key Binding is achieved by the signature on the enclosing JWT. Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple such SD-JWTs into one object and provide Key Binding using means other than the Key Binding JWT. </ins> 9. Security considerations in this section help achieve the following
11. <del> 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, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, 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> 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, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, 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.
In an SD-JWT, claims can be hidden, but cryptographically protected against undetected modification.  "Claims" here refers to both object <del> properties (key-value pairs) as well as array elements.  When issuing the SD-JWT to the Holder, the Issuer includes the cleartext </del> <ins> properties (name-value pairs) as well as array elements.  When issuing the SD-JWT to the Holder, the Issuer includes the cleartext </ins> counterparts of all hidden claims, the so-called Disclosures, outside the signed part of the SD-JWT.
11.5. <del> For the security of this scheme, the hash algorithm is required to be 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" </del> <ins> To ensure privacy of claims that are selectively disclosable, but are not being disclosed in a given presentation, the hash function MUST ensure that it is infeasible to calculate any portion of the three elements (salt, claim name, claim value) from a particular digest. This implies the hash function MUST be preimage resistant, but should also not allow an observer to infer any partial information about the undisclosed content.  In the terminology of cryptographic commitment schemes, the hash function MUST be computationally hiding. To ensure the integrity of selectively disclosable claims, the hash function MUST be second-preimage resistant.  That is, for any combination of salt, claim name and claim value, it is infeasible to find a different combination of salt, claim name and claim value that result in the same digest. The hash function SHOULD also be collision resistant.  Although not essential to the anticipated uses of SD-JWT, without collision resistance an Issuer may be able to find multiple disclosures that have the same hash value.  In which case, the signature over the SD- JWT would not then commit the Issuer to the contents of the JWT.  The collision resistance of the hash function used to generate digests SHOULD match the collision resistance of the hash function used by the signature scheme.  For example, use of the ES512 signature algorithm would require a disclosure hash function with at least 256-bit collision resistance, such as SHA-512. Note that inclusion in the "Named Information Hash Algorithm" </ins> 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
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, Mike Prorock, Nat <del> Sakimura, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, 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> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, 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.
An SD-JWT is composed of the following: <del> The individual parts will be explained in the following subsections. </del> <ins> The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in iss-signed-jwt, creating_disclosures, and kb-jwt respectively. </ins> The serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows: <del> The order of the tilde separated values MUST be the Issuer-signed JWT, followed by any number of Disclosures, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </del> <ins> The order of the concatenated parts MUST be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT.  In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted. </ins> The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures.  For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send <del> Disclosures or reveal the salt values in any other way. </del> <ins> Disclosures or reveal the salt values in any other way.  A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once. </ins> <del> A Holder MUST NOT send a Disclosure that was not included in the SD- JWT or send a Disclosure more than once. </del> <ins> To further illustrate the SD-JWT format, the following example shows a few different SD-JWT permutations, both with and without various constituent parts. </ins> 5.1.
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, Mike Prorock, Nat <del> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, 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> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, 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.