Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.moca.network/llms.txt

Use this file to discover all available pages before exploring further.

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. 
const result = await airService!.verifyCredential({
  authToken,
  programId,
  fieldsToDisclose: '*',
});

​
Disclose Specific Fields

Pass an array of field names from the credential subject. Only the listed fields are returned. 
const result = await airService!.verifyCredential({
  authToken,
  programId,
  fieldsToDisclose: ['membershipTier'],
});
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 and disclosure is requested, the response includes a disclosedData object alongside the standard verification fields. 
type SelectiveDisclosureResult = {
  status: "Compliant";
  zkProofs: Record<string, string>;
  transactionHash: string;
  disclosedData: {
    credentialSubject: IssuedCredential;
    credentialType: string;
    issuerDid: string;
    issuanceDate: string;
    expirationDate: string;
    proof: CredentialProof[];
  };
};
IssuedCredential is the same subject shape you defined when issuing the credential — selective disclosure simply mirrors back the fields your verifier requested.

​
Behavior and Limits

  • disclosedData is 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 disclosedData is omitted from the response.
  • 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.
  • The zero-knowledge proof in zkProofs is generated and validated regardless of which fields you disclose. Disclosure is additive, not a replacement for verification.
Treat disclosedData.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.