Salted hash disclosure is the mechanism behind SD-JWT selective disclosure. The issuer signs hashes of salted claim values rather than the values, and the holder reveals a claim by sending the salt and value so the verifier can recompute the hash.
Each claim gets combined with a random salt before hashing. The salt is what stops a verifier guessing withheld values. Without it, an undisclosed age_over_18 claim would have two possible hashes and fall over immediately.
The issuer signs the set of hashes once, at issuance. The holder picks which disclosures to send at presentation, and the verifier confirms each disclosed value hashes to something the issuer signed. Everything undisclosed stays an opaque hash.
mdoc does the same thing with different plumbing. Each data element carries its own random value, the Mobile Security Object holds the digests, and the ARF calls the two mechanisms conceptually identical.
Defined in
IETF RFC 9901 section 9.3; SD-JWT VC (draft-ietf-oauth-sd-jwt-vc); ARF v3.0.0 Annex 2 Topic 10
This is why "we only received the claims we asked for" is a cryptographic statement rather than a trust assumption. Worth understanding before you write a data protection impact assessment.
Authbound handles the protocols, formats, trust lists and revocation checks behind these terms. See what people build with them.
