Disclosure Digest

A disclosure digest is the specific hash value that stands in for a hidden claim inside an SD-JWT's signed payload. Where a Disclosure (see Salted Hash Disclosure) is the detached [salt, claim name, claim value] package the issuer hands to the holder, the digest is what's left behind, in public, inside the document the issuer actually signs: a fixed-size hash that proves a claim exists and was signed, without revealing what it is.

The exact construction, per the SD-JWT spec:

digest = base64url( SHA-256( base64url( JSON([salt, claimName, claimValue]) ) ) )

The issuer computes this for every disclosable claim and collects the results into an _sd array inside the signed JWT payload, alongside an _sd_alg field naming which hash function was used (sha-256, in every case Solidus issues today):

{
  "iss": "did:solidus:...",
  "_sd": ["8f2a9c1e...", "b7d4f302...", "e19a6c88..."],
  "_sd_alg": "sha-256"
}

A verifier who receives a disclosed claim recomputes this exact hash over the [salt, name, value] triple it was handed, and checks the result appears somewhere in the _sd array of the JWS payload it already verified the signature of. Match: the claim is genuine, unaltered, and really part of what the issuer signed. No match, reject it.

Where it comes from

Defined inside the IETF SD-JWT specification, edited by Daniel Fett, Kristina Yasuda, and Brian Campbell, the same editorial group behind SD-JWT VC and the Key-Binding JWT. Solidus designed none of this construction.

Solidus status

Shipped, testnet-live, via the @sd-jwt/core library wrapped by @solidus-network/sdk. One specific, worth-naming implementation detail: Solidus's own hasher callback (sdjwt/signer.ts) hard-codes sha-256 and throws on any other algorithm: there's no crypto-agility today, by construction, not as a tunable option a caller has and doesn't use.

It's worth repeating the correlation-risk point already made under SD-JWT VC, specifically here: a digest for an undisclosed field still travels with every presentation of a reused credential. It doesn't leak the value, brute-forcing it back out requires knowing the exact salt, but the digest itself is, in principle, a correlation handle: two colluding verifiers comparing the same undisclosed digest across two presentations can tell they're looking at the same credential. That's a property of the digest construction itself, inherent to the mechanism, not a Solidus-specific defect and not something Solidus's implementation can quietly remove.

Testnet only, unaudited assembly (see Ed25519 / EdDSA), no mainnet exists.

Proof you can run yourself: no Solidus library required for the check itself. Issue a credential (npm i @solidus-network/sdk, issueSdJwtVc), take one disclosure segment from the compact result, SHA-256 its exact base64url string, base64url-encode the result, and compare it to the matching entry in the decoded JWS payload's _sd array, any standard SHA-256 tool will produce the same match.