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: NAME it's not super clear to me how: would alleviate your concerns here: "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" Maybe I'm missing something obvious but I don't see much difference in how holders & verifiers would treat these various approaches. They still have to reconcile with the encoding and/or hashing algorithms expressed in the security envelope.
My point was about the selection of the blinded clame name (or 'placeholder claim name' as it is called in the current draft). We have two options on the table: Select a random string as the placeholder Select the placeholder as some function of the original claim name (the label in your proposal) and the salt What I wanted to express is that I think option 1 is better. From a security perspective, both are equivalent. There is no need to choose the placeholder claim name in a particular way, we just need to ensure that it does not leak information about the original claim name. Just numbering all placeholder claim names would be fine as well (as long as the numbering does not reveal anything, e.g., the position of the original claim in the list of claims.) But for option 2, I see two drawbacks: We need to explain more, in particular how to assemble the input for the function, similar to the discussion we had about the hidden claim values. For example, we need to define how the original claim name and the salt are concatenated such that there can be no prefix collisions. A verifier receiving an SD-JWT with blinded claim names according to option 2 may be tempted to (needlessly) check that the claim name was created in a particular way by recalculating the hash. If the issuer has made a mistake when calculating the hash or the verifier makes a mistake, this check will fail. Since such a check is not needed, it would be better if we don't set this trap in the first place. I see no advantages of option 2 over option 1, so I propose to go for option 1.
I see, thanks for explaining that. I'm fine with option 1 if the goal is to reduce cognitive complexity for the application developers - it makes sense.