How to Implement Selective Disclosure for Credential Attributes

Selective disclosure is a core privacy feature of Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs). It enables a credential holder to share only the necessary attributes required by a verifier, rather than the full credential. For instance, to prove you are over 21, you can cryptographically demonstrate your age meets the threshold without revealing your exact birth date, name, or address. This minimizes data exposure and aligns with the privacy-by-design principle, making it essential for use cases like age verification, employment checks, and KYC processes where data minimization is legally required.

The technical foundation for selective disclosure is built on cryptographic primitives like BBS+ signatures (used in W3C's Data Integrity specifications) or zero-knowledge proofs (ZKPs). These methods allow a prover to generate a proof that certain predicates about the signed data are true, without disclosing the actual data values or the full signature. For example, a BBS+ signature can be transformed into a derivative proof that validates only a subset of the originally signed messages. This is a shift from simpler schemes like JSON Web Tokens (JWTs), which typically require revealing all signed claims to verify the signature's validity.

Implementing selective disclosure starts with issuing a verifiable credential that supports the feature. The issuer signs a set of claims (e.g., name, dateOfBirth, nationality) using a selective disclosure-capable signature suite like BbsBlsSignature2020. When a user needs to share this credential, they use a presentation request from a verifier, which specifies exactly which claims or predicates are needed (e.g., "dateOfBirth" >= 2003-01-01). The user's wallet or agent then creates a verifiable presentation, generating a cryptographic proof that satisfies the request while withholding all other data.

Here is a simplified conceptual example using pseudocode for a presentation generation step:

codeCopy
// Original Signed Credential Claims
credentialClaims = {
  "name": "Alice",
  "dateOfBirth": "1990-05-15",
  "nationality": "US",
  "licenseNumber": "AB123456"
}

// Verifier's Presentation Request (asks for proof of age >= 21)
requestedPredicate = {
  "attribute": "dateOfBirth",
  "condition": "LESS_THAN_OR_EQUAL",
  "value": "2003-01-01"
}

// Generate Selective Disclosure Proof
proof = generateSelectiveProof(
  credential: signedCredential,
  disclosedAttributes: [], // No raw attributes disclosed
  predicates: [requestedPredicate] // Only prove the age condition
)

// The resulting Verifiable Presentation contains the proof,
// but not Alice's name, exact DOB, nationality, or license number.

This proof can be verified against the issuer's public key, confirming the statement is true without learning the underlying data.

For developers, key libraries and frameworks enable implementation. The W3C-CCG's jsonld-signatures-bbs library provides tools for BBS+ signatures. Platforms like Trinsic, Spruce ID's ssi SDK, and Microsoft's Verifiable Credentials SDK abstract much of the cryptography. When designing the system, you must decide on the disclosure format: using derived credentials that are re-signed subsets, or presentation proofs that are ZKPs over the original credential. The choice impacts interoperability and complexity. Always refer to the core specifications: the W3C Verifiable Credentials Data Model and the linked Data Integrity Proofs.

In practice, selective disclosure faces challenges. Schema design is critical—issuers must structure credential data into discrete, separable claims. Performance can be a concern, as generating ZKPs is computationally heavier than simple signature verification. Furthermore, verifier trust must be established; a verifier needs to trust the issuer's public key and the revocation status of the credential, often checked via a revocation registry like those on Indy or other ledgers. Despite these considerations, implementing selective disclosure is a definitive step toward user-centric identity, giving individuals granular control over their personal data in digital interactions.

Selective disclosure is a core privacy feature of verifiable credentials, allowing a holder to prove specific claims from a credential without revealing the entire document. To implement this, you need a foundational understanding of Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) as defined by the W3C. You will also need a cryptographic library capable of handling zero-knowledge proofs (ZKPs) or BBS+ signatures, which are the primary methods for enabling this functionality. Familiarity with JSON-LD and the structure of a VC data model is assumed.

For development, you will need Node.js (v18 or later) and a package manager like npm or yarn installed. The key library for this tutorial is @mattrglobal/bbs-signatures, which provides a TypeScript implementation of the BBS+ signature scheme used for selective disclosure. You can install it via npm install @mattrglobal/bbs-signatures. This library allows you to create signatures over multiple message attributes and later generate a proof for a subset of them, which is the essence of selective disclosure.

You must also set up a method to create and resolve DIDs. For testing, you can use a universal resolver or a local DID method like did:key. The issuer (who creates the credential) and the verifier (who checks the proof) must agree on and be able to resolve the DID and its associated public key. This setup ensures the cryptographic proofs are verifiable. We will simulate both roles in the following code examples to demonstrate the complete flow from credential issuance to presentation.

The core process involves three steps: Key Generation, Credential Signing, and Proof Generation. First, the issuer generates a BLS12-381 key pair. Next, they create a credential, sign its attributes (e.g., name, dateOfBirth, nationality), and issue it to the holder. Finally, the holder, when asked to prove only their nationality, uses the library to derive a proof from the full signature that reveals only that specific attribute, keeping all others hidden.

Here is a minimal code snippet to initialize the BBS context and generate a key pair:

javascriptCopy
import { BbsSignatures } from "@mattrglobal/bbs-signatures";
const bbs = await BbsSignatures.bls12381_shake256();
const keyPair = await bbs.generateBls12381KeyPair();
console.log("Public Key (hex):", Buffer.from(keyPair.publicKey).toString('hex'));

This key pair is used by the issuer to sign credentials. The public key must be published in the issuer's DID Document for verification.

Before proceeding, ensure you understand the security implications. The BBS+ signature scheme is secure under known cryptographic assumptions, but proper implementation is critical. Always use audited libraries, manage private keys securely (using HSMs or cloud KMS in production), and follow the latest specifications from the W3C Verifiable Credentials Data Model and BBS Signature Suite standards. With these prerequisites in place, you are ready to build a selective disclosure system.

Selective disclosure is a fundamental privacy-enhancing technique for verifiable credentials (VCs). It enables a credential holder to prove a subset of claims—such as their age being over 21 or their membership status—without exposing the entire credential, which might contain sensitive data like a full name or address. This is achieved using cryptographic primitives that allow the verifier to check the validity of the revealed claims while ensuring the unrevealed data remains hidden and the credential's signature remains intact. Core methods include BBS+ signatures and CL signatures, which are designed for this purpose.

Implementing selective disclosure typically involves a three-step process. First, the issuer creates a BBS+ signature over a set of attributes in the credential. The holder then generates a presentation by creating a cryptographic proof that discloses only the chosen attributes. Finally, the verifier checks this proof against the issuer's public key and the disclosed data. Libraries like @mattrglobal/bbs-signatures or anoncreds-rs provide the necessary APIs. For example, using the BBS+ library, a holder can call createProof with the signature, public key, and an array specifying which attributes to disclose.

Here is a simplified code snippet demonstrating the holder's proof generation using a hypothetical BBS library:

javascriptCopy
const { BBS } = require('bbs-signatures');
// credentialSig is the BBS+ signature received from the issuer
// publicKey is the issuer's public key
// messages is the array of all credential attributes
// disclosedIndices specifies which attributes to reveal (e.g., [2] for the third attribute)
const proof = await BBS.createProof({
  signature: credentialSig,
  publicKey: issuerPublicKey,
  messages: allAttributes,
  disclosedIndices: [2]
});
// The 'proof' and the disclosed attribute values are sent to the verifier.

The verifier would then use a corresponding verifyProof function, passing the proof, public key, disclosed messages, and the disclosed indices.

When designing a system for selective disclosure, key considerations include predicate proofs and non-revocation. Predicate proofs allow for proving statements about hidden attributes, such as "age > 18" without revealing the exact age, using range proofs or other zero-knowledge techniques. Simultaneously, you must integrate a revocation mechanism (like a revocation registry) so verifiers can check the credential's validity status without learning its unique identifier. Frameworks like Hyperledger AnonCreds and W3C SD-JWT VC provide standardized, interoperable ways to implement these features, handling much of the cryptographic complexity.

The W3C Selective Disclosure for JWTs (SD-JWT) approach offers a different, increasingly popular implementation. It uses specially formatted JSON Web Tokens where disclosed claims are sent in plain text alongside hashes of the undisclosed claims. The verifier recalculates the hashes to verify the integrity of the entire payload. This method can be simpler to implement with existing JWT libraries and is being adopted for real-world use cases like age verification and employee attestations. The choice between BBS+/AnonCreds and SD-JWT often depends on the required cryptographic features, ecosystem support, and interoperability requirements of your project.

Selective disclosure is a privacy-preserving feature of verifiable credentials (VCs) that allows a holder to prove specific claims from a credential without revealing the entire document. This is typically achieved using zero-knowledge proofs (ZKPs) or BBS+ signatures. For example, a user can prove they are over 21 from a government ID credential without disclosing their exact birthdate, name, or address. This workflow is essential for building compliant and user-centric identity systems in Web3, balancing verification needs with data minimization principles outlined in regulations like GDPR.

The issuance phase begins when a trusted entity, the issuer, creates a signed credential containing multiple attributes. Using the W3C Verifiable Credentials Data Model with a BBS+ signature scheme, the issuer signs a credential JSON-LD document. The signature is generated over the entire set of attributes, creating a cryptographic commitment to each one. The credential, along with its proof, is then delivered to the user's digital wallet, which becomes the credential holder. This establishes the foundational signed data set from which selective proofs can later be derived.

For the holder to perform selective disclosure, their wallet uses a cryptographic derivation process. From the original BBS+ signature and the full set of attributes, the wallet can generate a new, valid proof that only covers the disclosed attributes. The undisclosed attributes are replaced with cryptographic blinds or placeholders. The output is a verifiable presentation, a new JSON-LD document containing the revealed claims and the derived proof. This presentation is what is shared with the verifier, such as a dApp or service.

The verification phase involves the verifier receiving the presentation. The verifier's system must check two critical things: that the derived proof is cryptographically valid against the issuer's public key, and that the disclosed attributes satisfy their business logic (e.g., age > 21). Libraries like @mattrglobal/bbs-signatures or anoncreds-rs provide functions for this. The verifier does not see the blinded attributes and cannot infer their values, but the cryptographic proof confirms they were signed by the trusted issuer and have not been tampered with.

Implementing this requires choosing a supported signature suite. For a JavaScript/TypeScript stack, you can use the @mattrglobal/node-bbs-signatures library. Issuance involves creating a BBS+ key pair, signing a multi-attribute message array, and embedding the signature in a VC. Derivation is done by the wallet, specifying the indices of the attributes to disclose and calling signature.createProof(). Verification is performed by the relying party using signature.verifyProof() with the issuer's public key, the disclosed messages, and the proof. Always refer to the latest W3C VC-API and BBS Signature Suite specifications for interoperability standards.

Key considerations for production use include revocation status—selective disclosure proofs must often be combined with a non-revocation proof, such as a revocation bitmap or accumulator. Performance of ZKP generation can be a bottleneck for mobile wallets, requiring optimized native libraries. Furthermore, the schema of the credential must be designed with disclosure in mind, ensuring attributes are atomic enough to be selectively shared. Testing should cover edge cases like proving multiple, non-consecutive attributes from a single credential to ensure the cryptographic derivation works correctly.

Selective disclosure is a core privacy feature in verifiable credential (VC) systems like W3C Verifiable Credentials and Decentralized Identifiers (DIDs). It enables a credential holder to share only the necessary attributes with a verifier, minimizing data exposure. For instance, a user can prove they are over 21 from a digital driver's license without revealing their exact birthdate, name, or address. This is typically achieved using cryptographic techniques such as zero-knowledge proofs (ZKPs) or BBS+ signatures, which allow for the creation of a derived proof from the original signed credential.

Implementing selective disclosure requires choosing a supported cryptographic suite. The BBS+ signature scheme (BBS+ Signatures 2020) is a popular standard that enables this functionality. A credential is signed with BBS+, creating a cryptographic commitment to all its attributes. When a user needs to disclose only specific fields, they can generate a derived proof using the original signature, the disclosed attributes, and a nonce from the verifier. The verifier can then cryptographically validate this derived proof against the issuer's public DID without seeing the hidden data.

Here is a conceptual workflow using the @mattrglobal/jsonld-signatures-bbs library for BBS+:

javascriptCopy
// 1. Issuer signs a credential with all attributes
const signedCredential = await bbs.sign(credential, issuerKey);

// 2. Holder creates a derived proof for selective disclosure
const derivedProof = await bbs.deriveProof({
  document: signedCredential,
  disclosureFrame: { credentialSubject: { age: true } }, // Reveal only 'age'
  nonce: verifierNonce
});

// 3. Verifier checks the derived proof
const verified = await bbs.verifyProof(derivedProof, issuerPublicKey, verifierNonce);

This process ensures the revealed attribute (e.g., age) is valid and unchanged, while other attributes remain private.

For Ethereum-based systems, ZK-SNARKs or ZK-STARKs via circuits are common. A user might store a credential's hash on-chain and use a ZKP to prove a claim about its contents. Libraries like Circom or SnarkJS allow developers to write circuits that define the disclosure logic. For example, a circuit could take a secret birthdate and public issuer signature as inputs, and output a proof that the holder is over 18. The verifier contract only checks the proof, not the underlying data. Semaphore and ZKopru are protocols built on this principle for anonymous authentication and transactions.

Key considerations for implementation include schema design and revocation. Credential schemas should define attributes discretely to allow granular disclosure. Revocation mechanisms, such as status lists or accumulators, must also support selective disclosure to avoid leaking information about other revoked credentials. Always use a cryptographically secure nonce from the verifier to prevent replay attacks. For production use, audit established libraries and frameworks like Veramo, Trinsic, or Microsoft's ION/Sidetree for DID-linked VCs rather than building cryptographic primitives from scratch.

Selective disclosure transforms credential verification from an all-or-nothing data dump into a privacy-preserving dialogue. It is fundamental for compliant data minimization under regulations like GDPR and for building user-trusting applications in DeFi, DAO governance, and access control. By implementing these patterns, developers enable users to own and control their digital identity without sacrificing utility or security.

Selective disclosure is a fundamental privacy-enhancing technique for verifiable credentials. By implementing it, you empower users to share only the specific attributes required for a verification, such as proving they are over 21 without revealing their exact birthdate. This minimizes data exposure and aligns with principles of data minimization and user sovereignty. The primary methods include using BBS+ signatures for predicate proofs or zero-knowledge proofs (ZKPs) via circuits for more complex logic.

To implement selective disclosure, start by choosing a supporting Decentralized Identifier (DID) method and cryptographic suite. For BBS+, use a DID method like did:key or did:ion with the BbsBlsSignature2020 suite. Your credential issuance system must sign the credential with a BBS+ key. For verification, the holder derives a selective disclosure proof from the original signed credential, which the verifier can validate against the issuer's public key. Libraries like @mattrglobal/bbs-signatures provide essential primitives.

For advanced use cases requiring arithmetic or logical operations on hidden data, ZKPs are necessary. Frameworks like Circom and SnarkJS allow you to write circuits that prove statements like "salary > threshold". The credential data serves as private inputs to the circuit, which generates a proof. This proof, alongside the public outputs, is presented for verification. This approach is more complex but enables powerful privacy-preserving applications in DeFi or employment verification.

Your next steps should be practical: 1) Experiment with the W3C VC Implementation Guide, 2) Review the BBS+ Signature Suite 2020 specification, and 3) Test issuance and verification using a test network like Sepolia or a dedicated VC sandbox. Prioritize security audits for any production code, especially for ZKP circuits, as subtle bugs can compromise the entire system's integrity.

Finally, consider the broader ecosystem. Selective disclosure is one component of a trust triangle between issuer, holder, and verifier. Ensure your implementation supports standard formats like JSON-LD with Data Integrity proofs or JWT-VCs for interoperability. As the landscape evolves, stay informed about emerging standards from groups like the W3C Credentials Community Group to ensure your solution remains compatible and secure.