Code change:
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

Related discussion:
text: Addresses Issue
I also revisited the security recommendations for the salt and made some smaller changes there.
user has 2 SD-JWTs from the same issuer, same blinded claim names can be used to correlate the user. advice to have a fresh blinded claim name for each credential.
Instead of opening a new issue from our conversation this morning - here is the excerpt & suggestion from the document we discussed: First off, maybe it's informational or maybe it's specified - issuers should not include "secrets" in claim labels. If a label for something is actually a secret, it should be treated as such. That said, I get that this scenario must be addressed. Sensitive predicates or graduated disclosure contexts can benefit from this capability. It seems to me that the most useful and easy algorithm to implement is to use the same hash algorithm + salt for the node value to blind the label where: SALTED LABEL = HASHALGO(LABEL + SALT) Of course, this assumes that specific guidance is included for best practice salt generation (fresh entropy gathering for each attribute block salt, sufficient bits of entropy, etc.) for strong cryptographic outcomes. In this representation, the salted hash of the label's value ("name") "9-J2445ap91..." can be addressed directly by the digest "h" value in compact form: Side-note: Informative statements that recommend large sd-jwt claim sets should be 'broken down' into much smaller sets, or individual claims, then wrapped and sealed as a JWP may be better than including too many claims in an sd-jwt.
Right now, it is RECOMMENDED that a random string is chosen for the blinded claim name. HMAC(salt, claim-name) and HASHALGO(LABEL + SALT) would be fine as well, but there's more room for errors, especially as holders/verifiers might expect a specific format and then reject an SD-JWT when, e.g., the issuer chose a wrong encoding or similar. I don't see a real advantage of using HMAC/HASHALGO for the blinded claim name. I therefore propose to stick with the current recommendation. We should stress that a fresh random value must be chosen for each claim in each issued credential.