When we published Decentralized Professional Credentials in January, the protocol had one deliberate gap, and we said so plainly: presenting a credential meant presenting all of it. You could prove you worked at a company, but only by also handing over your role, your dates, and everything else the credential carried. We named selective disclosure as the next project in the series, and designed the credential format to accommodate it. This is that project.
We’re publishing a companion research paper that adds field-level selective disclosure to the base protocol, with the source code on GitHub. A holder now chooses which individual claims to reveal at presentation time and withholds the rest; the verifier sees the revealed values and nothing more than a count of how many items were held back. It builds directly on the base protocol – which remains required reading – and reuses its Ed25519 signing and did:key identifiers without change.
How It Works
The scheme follows SD-JWT (RFC 9901), the IETF’s standardized approach to selective disclosure for JWTs. At issuance, each disclosable claim is replaced with a salted hash; the issuer signs the credential containing those hashes and hands the holder a set of “disclosures” – the salt-and-value pairs that open them. To present a subset, the holder forwards the signed token plus only the disclosures they want to reveal, and the verifier recomputes the hashes to match them against the signed set.
The part that mattered most for us was leaving the chain untouched. The base protocol anchors a credential by hashing its signed token; we refined that to hash the signed token alone, ignoring any disclosures appended to it. Because that signed token is fixed at issuance and identical in every presentation – no matter which claims are revealed – the anchor never changes. A plain credential with no disclosures hashes exactly as it did before, so existing credentials and the contracts holding them are unaffected. The on-chain registry, both smart contracts, and the verification flow required no changes at all.
We also added an optional holder binding: a short token the holder signs over the specific presentation, a verifier-supplied nonce, and an intended audience. It defends against a presentation being intercepted and replayed to a different verifier, and it’s a per-presentation toggle rather than a requirement.
What We Found
The proof of concept runs end to end on both chains from the base PoC – Ethereum (Solidity) and IOTA Rebased (Move) – across five scenarios, including the two the base paper used to motivate the work: proving employment without revealing dates, and proving a certification without revealing its level. The sharpest demonstration is revocation. Because the anchor is the token hash, the exact same presentation file verifies VALID, then flips to REVOKED once the issuer revokes the underlying credential – with nothing about the presentation itself changing.
On-chain cost is identical to the base protocol. The anchored value is the same 32-byte hash regardless of how many claims are disclosed, so selective disclosure adds no measurable overhead, and the verifier’s disclosure checks are entirely off-chain.
What It Doesn’t Do
The scope is bounded on purpose. This is field-level reveal-or-hide, not a zero-knowledge system: a holder can hide a claim, but cannot prove a property of a hidden value – “at least two years of tenure” without the dates – which needs range proofs we didn’t take on here. Because the issuer’s signature is constant across presentations, two presentations of the same credential are linkable to one another; unlinkability would require a different signature scheme. And the implementation follows SD-JWT’s structure but is self-contained, so it doesn’t claim interoperability with third-party SD-JWT verifiers. These are discussed in the paper, alongside the base protocol’s own limitations, which all still apply.
What’s Next
The three natural directions are the ones we just ruled out of scope: predicate and range proofs for properties of hidden values, unlinkability via BBS+ signatures, and interoperability with the emerging SD-JWT VC profile. Each is a larger change that trades the current simple foundation for something stronger, and each composes with the base protocol’s own future work without touching how a credential is disclosed.
The full design, security properties, and complete dual-chain transcripts are in the research paper. The source code is on GitHub. The code is provided for research and educational purposes and has not been audited for production use.