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: The current wording of section 11.6 says: “Verifiers MUST NOT take into account […] whether Key Binding data is present in the SD-JWT or not[…]” While 11.8 says: "Verifiers therefore MUST ensure that all claims they deem necessary for checking the validity of the SD-JWT are present (or disclosed, respectively) before checking the validity and accepting the SD-JWT" I think these constraints do rule out the migration path that I described. I don’t see how a service could incrementally and securely roll-out support for Key Binding (for example) over time—starting from a base ecosystem that isn’t using Key Binding. Either they would have to suddenly require Key Binding, and therefore start rejecting clients that haven’t updated yet, or they may have the situation where a stolen key-bound SD-JWT can be treated as a simple bearer token by not selectively-disclosing the cnf claim. Concretely, I think these phrases and section 8.4 should be removed/re-written. How about the following: — An Issuer MUST NOT allow any security-critical claim to be selectively disclosable. The exact list of “security-critical” claims will depend on the application, and SHOULD be listed by any application-specific profile of SD-JWT. The following is a list of standard claim names that SHOULD be considered as security-critical by any SD-JWT Issuer: “iss” (Issuer) “aud” (Audience), although issuers may want to allow individual entries in the array to be selectively-disclosable “exp” (Expiration Time) “nbf” (Not Before) “iat” (Issued At) “jti” (JWT ID) In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively disclosable. Best wishes, Neil
I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed. Are we concerned about Holders and Issuers colluding? For example, now that claim names are blinded an Issuer can add the same claim multiple times with different, potentially contradictory, values and then the Holder can selectively release one disclosure to one Verifier and a completely different one to another Verifier.