Skip to main content
Early AccessSelective Disclosure is a new feature we are currently testing. It is only available in the Sandbox environment, and the API surface may change. It requires the latest AIR Kit SDK and an issuance program with disclosure explicitly enabled by the Issuer.
By default, AIR Kit credential verification only returns a Compliant / Non-Compliant result with a zero-knowledge proof — the Verifier never sees the underlying credential data. Selective Disclosure lets the Issuer opt-in to data disclosure for a credential. Once enabled, a Verifier can request specific fields from the credential subject — or the entire credential subject — alongside the zero-knowledge proof. The Verifier still validates the credential cryptographically; disclosure is layered on top of that result.

​
When to Use It

Selective Disclosure is useful when a yes/no proof is not enough to decide the final user experience. A verification program can prove a broad condition, but the Verifier may still need the exact disclosed value to choose the right reward, access level, or next step. A common example is a membership rewards flow:
  • A user proves they hold a valid membership credential.
  • A broad ZK condition such as membershipTier > bronze confirms they are eligible for rewards.
  • If the Verifier only gets that broad result, a Gold member may miss rewards that are specific to the Gold tier.
  • With Selective Disclosure, the Verifier can request membershipTier, confirm the value is gold, and grant the Gold reward.
In this flow, Selective Disclosure keeps the verification privacy-preserving while giving the Verifier the specific field needed to apply the correct business logic. Other typical scenarios:
  • A loyalty program that discloses rewardPoints only after the credential is verified.
  • A KYC Verifier that needs countryCode and kycLevel to route the user through the correct compliance flow.
  • A ticketing partner that needs seatTier to issue a physical wristband at the venue.
  • A fintech onboarding step where an analyst reviews disclosed verifiedAt timestamps.

​
Prerequisites

Before using Selective Disclosure you need:
  1. Sandbox environment — Selective Disclosure is currently available only in Sandbox.
  2. Latest AIR Kit SDK — Install or upgrade to the latest version of @mocanetwork/airkit.
  3. Issuer with disclosure enabled — The Issuer of the credential must have Allow data disclosure turned on for the issuance program.
  4. Active verification program — A published verification program in the Developer Dashboard (Verifier → Programs).
  5. Partner JWT with scope=verify — See Partner Authentication.

​
Step 1: Enable Disclosure on the Issuance Program

Selective Disclosure must be enabled by the Issuer at the program level. As a Verifier, you cannot request disclosed data unless the Issuer has opted in.
1

Open the Developer Dashboard

Sign in to the Developer Dashboard with your Issuer account.
2

Create or edit an issuance program

Navigate to Issuer → Programs and either create a new program (Issue Pricing) or open an existing one to edit.
3

Expand Advanced set up

In the credential form, expand the Advanced set up section.
4

Enable Allow data disclosure

Toggle Allow data disclosure on, then save the program.
Any credential issued from this program will now support Selective Disclosure during verification.

​
Step 2: Request Disclosure During Verification

On the Verifier side, pass fieldsToDisclose to airService.verifyCredential. There are two supported shapes.

​
Disclose the Entire Credential Subject

Pass '*' to receive every field in the credential subject.

​
Disclose Specific Fields

Pass an array of field names from the credential subject. Only the listed fields are returned.
Field names in fieldsToDisclose must match keys defined in the credential schema. Fields the Issuer has not enabled for disclosure are silently omitted.

​
Response Shape

When the verification result is Compliant, disclosed fields are returned inside the W3C Verifiable Presentation on verifiablePresentation, as the credentialSubject of the embedded credential.
Read the disclosed fields off the embedded credential:
credentialSubject mirrors the subject shape you defined when issuing the credential, narrowed to the fields your verifier requested.
Deprecated as of 1.11. Disclosure used to be returned on a top-level disclosedData object alongside zkProofs and transactionHash. Those fields are no longer populated — read verifiablePresentation instead. See the 1.11.1 release notes.

​
Behavior and Limits

  • Disclosed fields are only returned when status === "Compliant". Non-compliant verifications never expose credential data.
  • If the Issuer has not enabled Allow data disclosure on the program, fieldsToDisclose is ignored and no disclosed claims appear in the presentation.
  • Requesting fields that do not exist on the schema or were not enabled for disclosure does not fail the verification — those fields are simply absent.
  • Disclosure is additive, not a replacement for verification. Where the program requires a zero-knowledge proof, that proof is generated and validated regardless of which fields you disclose, and is returned on verifiablePresentation.proof.
  • fieldsToDisclose is required for SD_JWT_VC programs — an empty array or an omitted value is rejected. For those programs verifiableCredential[0] is a compact string rather than an object, so type-check before reading credentialSubject.
Treat the disclosed credentialSubject as user data: store it only as long as you need it for the downstream action (redemption, compliance review, fulfillment), and apply the same retention rules as any PII you receive directly from the user.

Verifying Credentials

The base verification flow that Selective Disclosure builds on.

Partner Authentication

Generate the scope=verify Partner JWT used as authToken.