jiebi/CodeConvo huggingface dataset:
Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, <del> 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> Pieter Kasselman, Richard Barnes, 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.
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, Richard Barnes, 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, 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.
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, <del> Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat 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. </del> <ins> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat 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.
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, <del> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat 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. </del> <ins> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat 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.
5.1. An SD-JWT has a JWT component that MUST be signed using the Issuer's <del> private key.  It MUST use a JWS asymmetric digital signature algorithm.  It MUST NOT use </del> <ins> private key.  It MUST NOT use the </ins> <del> or an identifier for a symmetric algorithm (MAC). </del> <ins> algorithm. </ins> The payload of an SD-JWT is a JSON object according to the following rules:
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 <del> data_formats. </del> <ins> data_formats.  When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosures for the claims that it wants to reveal to that Verifier. </ins> An SD-JWT MAY also contain clear-text claims that are always disclosed to the Verifier.
5.2.3. <del> For embedding the Disclosures in the SD-JWT, the Disclosures are hashed using the hash algorithm specified in the </del> <ins> For embedding references to the Disclosures in the SD-JWT, each Disclosure is hashed using the hash algorithm specified in the </ins> claim described in hash_function_claim.  The resulting digest is then included in the SD-JWT payload instead of the original claim value, as described next. The digest MUST be taken over the US-ASCII bytes of the base64url- <del> encoded Disclosure.  This follows the convention in JWS RFC7515 and JWE RFC7516.  The bytes of the digest MUST then be base64url-encoded. </del> <ins> encoded value that is the Disclosure.  This follows the convention in JWS RFC7515 and JWE RFC7516.  The bytes of the digest MUST then be base64url-encoded. </ins> It is important to note that:
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) SHOULD be </del> <ins> The Disclosures (both for issuance and presentation) SHOULD be </ins> included in the serialized JWS using the member name at the top-level of the JSON object (the same level as the
Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard <del> 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. </del> <ins> Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
10.3. The security model that conceals the plaintext claims relies on the <del> fact that salts not revealed to an attacker cannot be learned or guessed by the attacker, even if other salts have been revealed.  It is vitally important to adhere to this principle.  As such, each salt MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim independently from other salts.  See Randomness Requirements for </del> <ins> high entropy random data of the salt as additional input to the hash function.  The randomness ensures that the same plaintext claim value does not produce the same digest value.  It also makes it infeasible to guess the preimage of the digest (thereby learning the plaintext claim value) by enumerating the potential value space for a claim into the hash function to search for a matching digest value.  It is therefore vitally important that unrevealed salts cannot be learned or guessed, even if other salts have been revealed.  As such, each salt MUST be created in such a manner that it is cryptographically random, sufficiently long, and has high enough entropy that it is infeasible to guess.  A new salt MUST be chosen for each claim independently of other salts.  See Randomness Requirements for </ins> Security RFC4086 for considerations on generating random values. <del> 10.4. </del> The RECOMMENDED minimum length of the randomly-generated portion of the salt is 128 bits.
split into issuance and presentation. Note: Throughout the examples in this document, line breaks had to be <del> added to JSON strings and base64-encoded strings to adhere to the 72 character limit for lines in RFCs and for readability.  JSON does not allow line breaks within strings. </del> <ins> added to JSON strings and base64-encoded strings to adhere to the 72-character limit for lines in RFCs and for readability.  JSON does not allow line breaks within strings. </ins> 6.1.
split into component parts and the Disclosures can be found in the respective member of the JSON object (or elsewhere). <del> Using a payload similar to that from Example 1 [1], the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. </del> <ins> Using a payload similar to that from the example in main-example, the following is a non-normative example of a JWS JSON serialized SD-JWT from an Issuer with all the respective Disclosures. </ins> Below is a non-normative example of a presentation of the JWS JSON serialized SD-JWT, where the Holder has selected to disclose
The Issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places <del> in the structure of the SD-JWT.  This can be seen in Example 3 in the Appendix, where multiple claims with the name </del> <ins> in the structure of the SD-JWT.  This can be seen in the example in example-complex-structured-sd-jwt, where multiple claims with the name </ins> appear, but each of them has a different salt.
This document also defines a format for SD-JWTs with Key Binding (SD- JWT+KB).  By optionally sending an SD-JWT+KB to a Verifier, the Holder can prove to the Verifier that they hold the private key <del> associated to the SD-JWT (e.g., using the </del> <ins> associated to the SD-JWT (i.e., using the </ins> claim RFC7800).  The strength of the binding is conditional upon the trust in the protection of the private key of the key pair an SD-JWT
5.1.2. If the Issuer wants to enable Key Binding, it includes a public key <del> associated with the Holder, or a reference thereto.  The </del> <ins> associated with the Holder, or a reference thereto, using the </ins> <del> member of the </del> <ins> claim as defined in RFC7800.  The </ins> <del> claim as defined in Section 3.2 of RFC7800 is suggested for doing so, however, other means can be used. </del> <ins> confirmation method, as defined in Section 3.2 of RFC7800, is suggested for doing so, however, other confirmation methods can be used. Note that, as was stated in RFC7800, if an application needs to represent multiple proof-of-possession keys in the same SD-JWT, one way to achieve this is to use other claim names, in addition to , to hold the additional proof-of-possession key information. </ins> It is out of the scope of this document to describe how the Holder key pair is established.  For example, the Holder MAY create a key
presented at the same time, etc. It is important that a Verifier does not make its security policy <del> decisions based on data that can be influenced by an attacker or that can be misinterpreted.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account: </del> <ins> decisions based on data that can be influenced by an attacker.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account whether the Holder has provided an SD-JWT+KB or a bare SD-JWT, since otherwise an attacker could strip the KB-JWT from an SD-JWT+KB and present the resulting SD-JWT. Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether the SD-JWT supports Key Binding or not. </ins> If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey <del> Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
a few different SD-JWT permutations, both with and without various constituent parts. <del> An SD-JWT without Disclosures and without a KB-JWT: </del> <ins> An SD-JWT without Disclosures: </ins> <del> An SD-JWT with Disclosures and without a KB-JWT: </del> <ins> An SD-JWT with Disclosures: </ins> An SD-JWT+KB without Disclosures:
credential to the Issuer.  It is important to note that the timing of such requests could potentially serve as a side-channel. <del> Verifier/Verifier unlinkablility and presentation unlinkablility can be achieved using batch issuance: A batch of credentials based on the </del> <ins> Verifier/Verifier unlinkability and presentation unlinkability can be achieved using batch issuance: A batch of credentials based on the </ins> same claims is issued to the Holder instead of just a single credential.  The Holder can then use a different credential for each Verifier or even for each session with a Verifier.  New key binding
and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. <ins> Special appreciation is extended to Martin Thomson, who wielded his considerable intellect and influence to change a single occurrence of the word "to" to "with" in the midst of a significant proposal that would be integrated into this document six months later. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.
(three dots).  The value MUST be the digest of the Disclosure created as described in hashing_disclosures.  There MUST NOT be any other <del> keys in the object. </del> <ins> keys in the object.  Note that the string was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context. </ins> For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make
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 <del> 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 SD-JWTs, and Issuers and Verifiers may decide to do so as well. </del> <ins> identity service.  For example, in OpenID Connect OpenID.Core, signed ID Tokens can be stored by Relying Parties.  In the case of SD-JWT, Holders have to store SD-JWTs, and Issuers and Verifiers may decide to do so as well. </ins> Not surprisingly, a leak of such data risks revealing private data of End-Users to third parties.  Signed End-User data, the authenticity
6.1. <del> The Issuer is using the following input JWT Claims Set: </del> <ins> The following data about the user comprises the input JWT Claims Set used by the Issuer: </ins> <del> The Issuer in this case made the following decisions: </del> <ins> In this example, the following decisions were made by the Issuer in constructing the SD-JWT: </ins> The following payload is used for the SD-JWT: <del> The following Disclosures are created by the Issuer: </del> <ins> The respective Disclosures are created by the Issuer: </ins> <del> The payload is then signed by the Issuer to create the following JWT: </del> <ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT: </ins> <del> The following is the issued SD-JWT: </del> <ins> Adding the Disclosures produces the SD-JWT: </ins> 6.2.
The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT: <del> If any step fails, the SD-JWT is not valid and processing MUST be aborted. </del> <ins> If any step fails, the SD-JWT is not valid, and processing MUST be aborted.  Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as the processed SD-JWT payload, can be made available to the application to be used for its intended purpose. </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
It may be sufficient to store the result of the verification and any End-User data that is needed for the application. <del> If reliable and secure key rotation and revocation is ensured according to issuer_signature_key_distribution, Issuers 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. </del> 11.3. If the SD-JWT is transmitted over an insecure channel during issuance
The following payload is used for the SD-JWT: <del> The respective Disclosures are created by the Issuer: </del> <ins> The respective Disclosures, created by the Issuer, are listed below. In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:". </ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT:
The same digest value MUST NOT appear more than once in the SD-JWT. <del> Applications of SD-JWT SHOULD be explicitly typed using the header parameter.  See explicit_typing for more details. </del> <ins> Application and profiles of SD-JWT SHOULD be explicitly typed.  See explicit_typing for more details. </ins> It is the Issuer who decides which claims are selectively disclosable and which are not.  End-User claims MAY be included as plaintext as
10.11. <del> 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 </del> <ins> RFC8725 describes the use of explicit typing as one mechanism to prevent confusion attacks (described in RFC8725) in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially subject to such confusion attacks, so in the absence of other techniques, it is RECOMMENDED that application profiles of SD-JWT specify an explicit type by including the </ins> header parameter when the SD-JWT is issued, and for Verifiers to check this value. <del> 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 </del> <ins> When explicit typing using the header 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 </ins> 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> Use of the content type header parameter to indicate the content type of the SD- JWT payload can also be used to distinguish different types of JSON objects, or different kinds of JWT Claim Sets. </ins> 11. The privacy principles of ISO.29100 should be adhered to.
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, Dale Bowie, David Bakker, David <del> Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Michael B.  Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Waite, Dick Hardt, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Michael B. Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> Special appreciation is extended to Martin Thomson, who wielded his considerable intellect and influence to change a single occurrence of
explicit_typing for more details. It is the Issuer who decides which claims are selectively disclosable <del> and which are not.  End-User claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case.  See sd-validity-claims for </del> <ins> by the Holder and which are not.  Claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case.  See sd-validity-claims for </ins> considerations on making validity-controlling claims such as selectively disclosable.