Code change:
11.5. <del> For the security of this scheme, the hash algorithm is required to be preimage resistant and second-preimage resistant, i.e., it is infeasible to calculate the salt and claim value that result in a particular digest, and, for any salt and claim value pair, it is infeasible to find a different salt and claim value pair that result in the same digest, respectively. Hash algorithms that do not meet the aforementioned requirements MUST NOT be used.  Inclusion in the "Named Information Hash Algorithm" </del> <ins> To ensure privacy of claims that are selectively disclosable, but are not being disclosed in a given presentation, the hash function MUST ensure that it is infeasible to calculate any portion of the three elements (salt, claim name, claim value) from a particular digest. This implies the hash function MUST be preimage resistant, but should also not allow an observer to infer any partial information about the undisclosed content.  In the terminology of cryptographic commitment schemes, the hash function MUST be computationally hiding. To ensure the integrity of selectively disclosable claims, the hash function MUST be second-preimage resistant.  That is, for any combination of salt, claim name and claim value, it is infeasible to find a different combination of salt, claim name and claim value that result in the same digest. The hash function SHOULD also be collision resistant.  Although not essential to the anticipated uses of SD-JWT, without collision resistance an Issuer may be able to find multiple disclosures that have the same hash value.  In which case, the signature over the SD- JWT would not then commit the Issuer to the contents of the JWT.  The collision resistance of the hash function used to generate digests SHOULD match the collision resistance of the hash function used by the signature scheme.  For example, use of the ES512 signature algorithm would require a disclosure hash function with at least 256-bit collision resistance, such as SHA-512. Note that inclusion in the "Named Information Hash Algorithm" </ins> registry IANA.Hash.Algorithms alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several heavily truncated digests, such as

Related discussion:
text: for and based largely on text suggested on list by Neil Madden
from this thread URL Neil Madden has suggested the following for "Choice of a Hash Algorithm" section. I think (with maybe some minor tweaks) the text works and it would also address issue .
Saying something about matching the strength of hash function and signature algorithm would probably be worthwhile. resulting from this thread URL / URL etc "... indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms."
How to actually write this in an appropriate way for a draft RFC feels kinda tricky though. JWE has some text about using that I was hopping to borrow from but the context is (unsurprisingly) different enough that using text straight from it doesn't quite work. Maybe adding a very general statement in would be sufficient.
At IETF 118 Tuesday meeting, Orie proposed locking the hash to the one committed to by the Issuer. Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden wrote: Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want. verification and processing rules (this one specifically ). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft. A more sophisticated version of this “attack” illustrates the need for prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use.