> ## 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.
# Selective Disclosure
> Selective Disclosure lets verifiers read specific credential fields after a successful zero-knowledge proof — opt-in by the issuer, sandbox only.
**Early Access**
Selective 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](/airkit/usage/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.
Sign in to the Developer Dashboard with your Issuer account.
Navigate to **Issuer → Programs** and either create a new program (Issue Pricing) or open an existing one to edit.
In the credential form, expand the **Advanced set up** section.
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.
```ts theme={null}
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.
```ts theme={null}
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.
```ts theme={null}
type SelectiveDisclosureResult = {
status: "Compliant";
zkProofs: Record;
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.
## Related
The base verification flow that Selective Disclosure builds on.
Generate the `scope=verify` Partner JWT used as `authToken`.