Code change:
More explicitly state that SD-JWTs have to be signed asymmetrically (no MAC and no ) One item out of John Mattsson's review: URL Thanks for the review John. I've tried to reply to the comments inline below. MUST be signed using the Issuer's private key" in sec 5.2 .) but I think you're right that it should be explicit. I assume it would be a claim. Is there something that suggests otherwise to you? That "HOLDER-PUBLIC-KEY" only shows up in section 4.3 , which is supposed to be a somewhat abstract discussion about it. And I think it's separate from SD-CLAIMS and NON-SD-CLAIMS there to call attention to it. But not to suggest that it's not a claim. More generally (as sec 5.2.3. Holder Public Key Claim tries to describe) the specific way that holder public key binding is established by the issuer and represented in the JWT is out of scope. A "cnf" claim is used in examples for what it's worth. But the specific details of a holder public key binding claim are left to applications using or profiling SD-JWT. the hash input so as to make it infeasible to "reverse" the hash value by enumerating potential claim name/values into the hash function. Correspondingly a salt value is included in the disclosure structure directly alongside a claim name and value. I think using the word secret to talk about salt values would be problematic and potentially confusing. The salt values of undisclosed claims need to be hidden from parties to whom the claim isn't being disclosed. But the salts are sent from the issuer to the holder. And salts of disclosed claims are sent from the holder to the verifier. That's different from a typical secret (as I think of a secret anyway). We can look to add text or clarify text about not revealing salt values to unintended parties. that the "Issuer MUST ensure that a new salt value is chosen for each claim" and a "new salt MUST be chosen for each claim" in section 8.4 . I think that's what you mean by salts being independent of each other? Sec 8.5 has a 128-bit minimum length as RECOMMENDED. As I recall, there was some desire to allow for shorter salts when used with a more computationally expensive digest function and the RECOMMENDED would allow for that situation by basically saying to use at least 128 unless you have a good reason to do otherwise and understand the implications. I think "key" or "secret" are definitely not the right name and would be more prone to mislead or confuse. It's a random value that's included in the hash input (that otherwise has a more predictable value space) to make it infeasible to guess/confirm the claim name and value from the hash value. And ensure that the hash output will vary when hashing the same claim name/value more than once. disclosure structure (containing the claim name & value as well as the salt) is hashed and the digest value is placed in the "sd" claim of the signed JWT. Each (signed via inclusion in the JWT) digest value is an integrity check on, and reference to, the corresponding disclosure. Length extension attacks aren't applicable to this kind of use of the hash value. Any change to the disclosure content breaks the integrity check and any change to the hash value breaks the signature. Cheers, CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._

Related discussion:
text: 5.2.1.4. An SD-JWT is a JWT that MUST be signed using the Issuer's private <del> key. </del> <ins> key.  It MUST use a JWS asymmetric digital signature algorithm and MUST NOT use or an identifier for a symmetric algorithm (MAC). </ins> An SD-JWT MAY contain both selectively disclosable claims and non- selectively disclosable claims, i.e., claims that are always