> ## Documentation Index
> Fetch the complete documentation index at: https://docs.air3.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Credential Security

> How Moca Network credentials are signed by issuers, encrypted to the holder, stored as ciphertext, and verified with signature-based proofs — no PII exposure.

Verifiable credentials on Moca Network are designed to be tamper-evident, privacy-preserving, and portable across any verifier in the ecosystem.

## Issuance integrity

When a credential is issued:

1. The issuer signs the credential data with issuer-controlled keys (`BJJ_SIG_2021`), bound to their DID.
2. The signed credential payload is encrypted to the holder's public key.
3. The encrypted envelope is stored in DStorage. AIR stores and routes opaque ciphertext and metadata as a blind facilitator — it never sees the plaintext.

The issuer's signature acts as a tamper seal. If the credential data is modified after issuance, any verification will fail because the signature no longer matches.

## Signature-based verification

Verification is program-driven and uses signature-based proofs, with zero-knowledge proofs where the program requires them:

* The verifier asks a question: "Does this user hold a valid credential matching schema X?"
* The holder's device generates a proof that answers the query, disclosing only the requested claims.
* The verifier receives a compliance result and a Verifiable Presentation containing the disclosed claims and proof material — nothing else.

No PII is transmitted beyond what the program requests. The verifier cannot reconstruct the original credential from the proof. Verification completes off-chain by default; programs that require it can record the proof on-chain through the Universal Verifier.

## Selective disclosure

Proofs can verify individual attributes without revealing the full credential. For example, a credential containing `age`, `country`, and `kycLevel` can prove that `kycLevel >= 2` without revealing the user's age or country. An attribute Merkle root binds the disclosed fields to the signed credential.

Selective disclosure is defined at the schema and verification program level. See [Schema Design](/airkit/usage/credential/schema-overview) for configuration.

## Credential revocation

Issuers can revoke credentials at any time through issuer-controlled revocation. A revocation check is part of verification, so any subsequent verification against a revoked credential will fail.

## Regulated data access (CAK)

For industries where verifiers must access raw data (e.g. identity photos for KYC), the [Compliance Access Key (CAK)](/learn/advanced-topics/privacy-and-compliance) framework adds a consent-gated encryption layer. Data is encrypted at issuance and only decryptable by a verifier who has obtained explicit user consent after a successful verification.

## Credential storage

| Storage layer            | What is stored                                                       | Encrypted?                    |
| ------------------------ | -------------------------------------------------------------------- | ----------------------------- |
| DStorage (decentralized) | Signed credential payload (VC envelope) and metadata                 | Yes — encrypted to the holder |
| Moca Chain (on-chain)    | Optional proof records when a program requires on-chain verification | N/A — proof records, not data |
| User device              | Private keys, session tokens                                         | Yes, managed by MPC shards    |

## Further reading

* [Privacy & Compliance (CAK)](/learn/advanced-topics/privacy-and-compliance) for the full encryption framework
* [zkTLS](/learn/advanced-topics/zktls) for the zero-knowledge transport layer
* [Schema Design](/airkit/usage/credential/schema-overview) for defining verifiable attributes