jiebi/CodeConvo huggingface dataset:
Code change:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Related discussion:
text: 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.
Code change:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Related discussion:
text: 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.
Code change:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Related discussion:
text: The following is a non-normative example of the contents of an SD- JWT-R for Example 1: <del> For each claim, an array of the salt and the claim value is contained in the </del> <ins> For each claim, a JSON literal that decodes to an object with the and the claim value (plus optionally the claim name) is contained in the </ins> object.
Code change:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Related discussion:
text: 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.
Code change:
PR for URL
Done, and also cleaned up the intro slightly (repeating 'document' is superfluous there).

Related discussion:
text: 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
Code change:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Related discussion:
text: 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 (
Code change:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Related discussion:
text: . <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
Code change:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Related discussion:
text: 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.
Code change:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Related discussion:
text: 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.
Code change:
added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged

Related discussion:
text: 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
Code change:
reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.

Related discussion:
text: 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> BASE64URL denotes the URL-safe Base64 encoding without padding as defined in RFC7515, Section 2. </del> <ins> denotes the URL-safe base64 encoding without padding defined in Section 2 of RFC7515. </ins> 2.
Code change:
reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.

Related discussion:
text: 4.3. For transporting the SVC together with the SD-JWT from the issuer to <del> the holder, the SVC is BASE64URL encoded and appended to the SD-JWT </del> <ins> the holder, the SVC is base64ur-encoded and appended to the SD-JWT </ins> using as the separator.  For Example 1, the combined format looks as
Code change:
reflecting conversation in Issuer why we are not hiding claim names
I propose to move this to the privacy considerations.
makes sense.
Some use cases may require hiding both claim names and claims. Some schemas are country/jurisdiction-specific and revealing all claims might reveal some additional information. Open questions/remarks since the issuer is known, information about the schema can be guessed hiding the claim names does not hide the structure do use cases really require hiding the claim name?
There have been some discussions about it on the signal group. Just recording them for the transparency purposes hide claim values only hide claim names and claim values Rationale: Some schemas are country/jurisdiction specific and revealing all claims might reveal some additional information. (Something the use-cases still need to clarify is the fact that the issuer is known. Still waiting for some additional feedback.) That's what I thought. Another question would be: For structured claim objects (cf. eKYC & IDA Spec), do we need to hide the structure? The structure itself might be revealing some information. I can imagine the cases where an issuer would be issuing only one type of credentials with fixed structure and claimset. That means, if you know the issuer, you can pretty much find out the structure and claim names in it. So, hiding the structure and claim names would not add much. I would assume that is the default. I agree In ekyc, the structure alone can reveal the type of evidence used, which might leak info about e.g. nationality. But these cases might be rare and I'd also like to keep it simple for now. Right. At the same time, you typically want to know the nationality in the case of EKYC in financial institutions :-) Speaking of that, I was assuming that in a lot of cases, the receiver may need to know the type of credential especially when the issuer was issuing multiple types of credentials at different assurance levels. Is this assumption bogus? That's a valid assumption. Verifier needs to know the level of assurance of the VC and in most cases (I guess) it will need to know under what policies the holder keys are created/stored/... (or if it can trust the wallet where the Verifiable Presentation was created and is shared from)
NAME are you arguing to have both options - to hide and not to hide claim names?
We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.

Related discussion:
text: algorithm is used, i.e., the document is not signed. <del> In any case, the result is encoded as described in RFC7515 (here for </del> <ins> In any case, the result is encoded as described in RFC7519 (here for </ins> Example 1): (Line breaks for presentation only.)
Code change:
addresses issue
The way it is written now does not look like terms and definitions. It would also be a good practice to make it possible to the definition to replace the terms that appear in the main text. With this respect, verbose explanations especially the mechanisms should be done in the "Concepts" section in the main text. In fact, much of the text in the current "terminology" mostly duplicates what is being explained in 3. Concept Also, examples etc. should be added as a note to the definition and not as part of the definition text. Proposes the following as amended text Terms and definitions 2.1 SD-JWT signed JWT ], that supports selective disclosure as defined in this document Note to entry: Signed JWT is JWS. 2.2 release (SD-JWT-R) document that contains a subset of the claim values of an SD-JWT in a verifiable way Note to entry: Holder binding is also possible. 2.3 issuer entity that create SD-JWTs (2.1) 2.4 holder entity that has control over SD-JWTs (2.1) Note to entry: If holder binding is desired, the holder also has the signing key for the verification key contained in the SD-JWT. 2.5 verifier entity that checks and extracts the claims from SSD-JWT-R (2.2)
closing with PR
Currently, it has Conventions and Terminology Terminology Having two "Terminology" as consecutive headings is not good. I propose to change 2 as follows: Terms and Definitions
closing with PR

Related discussion:
text: 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?