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.
Technical standardReviewed 7 October 2026
Between the wallet and the relying party, when the user shares data.
Issuer
Signs credentials: a member state, university, bank or employer
Issuance
EUDI Wallet
Belongs to the user, who decides what to share
Presentation
Relying party
The service that requests and checks the data
Trust layer: who is allowed to sign, and is it still valid?
Rules: the law and technical framework behind it all
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.
Where you meet it
