Salted Hash Disclosure

Salted hash disclosure is a way to let an issuer sign a claim without forcing it to be revealed every time the signed document is shown, and without needing a separate signature per possible combination of revealed fields. The trick: instead of putting a claim's plaintext value directly inside the document that gets signed, the issuer generates a random salt, hashes the salt together with the claim, and puts only that hash, a digest, inside the signed document. The plaintext value and its salt travel separately, as a detached package the holder decides whether to hand over.

Why the salt matters: without it, anyone who could guess or already knew the possible values of a claim (a country code, a yes/no age check, a small enumerated list) could just hash every candidate value and match it against the published digest, cheaply reversing a supposedly hidden field. A random salt, unique per claim per credential, makes that brute-force matching computationally useless: the digest reveals nothing about the underlying value without also knowing the exact salt that produced it.

This gives a verifier two independent guarantees at once: a claim's plaintext value is genuinely hidden unless explicitly disclosed, and when it is disclosed, the verifier can recompute the same salt-plus-hash and confirm it matches the digest the issuer actually signed, proving the revealed value is exactly what was signed, not something the holder swapped in afterward.

Two standardized instances

This exact pattern shows up, independently, in two specs Solidus's credential formats touch:

• IETF SD-JWT calls the detached [salt, claim name, claim value] package a Disclosure, and the corresponding hash embedded in the signed JWT a digest (see the Disclosure Digest entry for the exact construction).
• ISO/IEC 18013-5's mdoc format does the same thing under a different name: each data element gets its own random value plus a digest, collected into the credential's Mobile Security Object (see the mDoc entry).

Neither invented the underlying idea, salted commitments predate both specs by decades in general cryptography, but each standardized a specific, interoperable wire format for it.

Solidus status

Shipped, testnet-live, for the SD-JWT instance only. @solidus-network/sdk's issueSdJwtVc builds exactly the Disclosure-and-digest construction described above (implemented via the third-party @sd-jwt/core library, not written from scratch by Solidus). The ISO mdoc / Mobile Security Object instance is not implemented anywhere in Solidus's stack, the same CBOR/COSE absence documented directly in the mDoc entry applies here too, since mdoc's version of this pattern is CBOR-encoded. So this entry should be read narrowly: one specific standardized instance of a general pattern is real; the other named instance is not.

Everything here runs on public testnet, with the usual unaudited-assembly caveat (see Ed25519 / EdDSA), no mainnet exists.

Proof you can run yourself: npm i @solidus-network/sdk, issue a credential, and split the compact result on ~. Every disclosure segment is a base64url-encoded JSON array, decode one directly and read the salt and plaintext value yourself, no Solidus-specific tooling required.