Selective disclosure and predicate proofs: what each one shows
Selective disclosure shows a verifier only the fields it asks for; a predicate check shows only the answer. Essence has built both, and is exact about who sees the value behind each.
Say a venue needs to know that a customer is over 18. The customer holds a credential from an issuer the venue trusts, showing their name, date of birth, address and document number. The venue could be given the whole credential, and would then hold data it never needed. It could be given only the date of birth: less, but still a precise and permanent fact. Or it could be given only the answer.
The second of those is selective disclosure. The third is a predicate check. Both mean sharing less, they show the verifier different things, and Essence has built both.
Showing only the fields asked for
Essence uses SD-JWT for selective disclosure, the format behind SD-JWT verifiable credentials. When a credential is issued, each claim becomes a separate item, mixed with a random value so it cannot be guessed. The signed part of the credential carries only a fingerprint of each item, and the issuer signs the whole set once.
When the holder presents the credential, they choose which items to reveal. The verifier checks each revealed item against its fingerprint and checks the issuer's signature. It learns the claims it was shown and nothing about the rest, and it knows the issuer vouched for what it saw.
In our August release we built this into Essence through OpenID4VCI and OpenID4VP, the OpenID standards for issuing and presenting credentials, with SD-JWT as the credential format the platform accepts.
Tested by trying to over-share
As part of the same release, we ran a full presentation test. A real, signed SD-JWT credential was presented and verified. Then four altered versions were each refused: a tampered signature, a wrong nonce, an unregistered key and an unregistered issuer.
The telling part was a deliberate over-share. The holder revealed a field the verifier had not asked for, and the verifier did not pass it on. Only the requested field came back. That is what a relying organisation needs: what it asked for, with nothing extra landing in its systems by accident.
Showing only the answer
Sometimes one field still says too much. A date of birth answers "over 18" and a good deal else besides. A predicate check returns only the answer, and there are two ways to get one on Essence.
The first uses selective disclosure. An issuer can put a ready-made answer into the credential as a claim of its own, such as an over-18 flag, and the holder reveals that claim alone. The verifier sees the answer and never the date.
The second is a predicate check in the platform's credentials service, in place since June 2026. The service reads the value, works out whether the condition holds and, if it does, returns that answer with a signed commitment to the value. The verifier learns the answer, not the value, and because the answer comes signed, it can check that nothing has been altered.
It is worth being exact about who sees what on that second route. The verifier never sees the date of birth. The platform does, because it does the working out.
Keeping presentations apart
Hiding claims is one half of the job. The other is stopping separate presentations from being joined up. The issuer's signature on an SD-JWT credential is the same every time it is shown, so two verifiers comparing notes could tell they had seen the same credential, even if each saw different fields.
The OpenID4VC requirements in our August release deal with this by issuing credentials in batches of separately signed copies, with a fresh copy used for each presentation, so that each verifier sees a different signature. The batch records have been in the platform's code since that release.
What this means for you
If you ask people for data, ask for the narrowest thing that answers your question. A field is better than a document, and an answer is better than a field, because each step down is less to hold, secure and eventually delete. When you weigh any privacy-preserving check, ask two things: who sees the underlying value, and what does the verifier keep? If you run age checks, eligibility checks or any decision that needs a fact rather than a file, we would be glad to show you how these fit.
Published 17 September 2026