> ## 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 program-defined proofs.

Verifiable credentials on Moca Network are designed to be tamper-evident, privacy-preserving, and portable to any verifier that uses AIR verification.

## Issuance integrity

When a credential is issued:

1. The issuer signs the credential data with issuer-controlled keys, bound to their DID. SD-JWT issuers (`SD_JWT_VC`) publish the verifying keys in a `did:web` document on their own domain. When the holder provides a key, the issuer writes it to the credential's `cnf` claim, binding the credential to the holder.
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.

## Verification

Verification is program-driven:

* The verifier asks a question: "Does this user hold a valid credential matching schema X?"
* The holder decrypts the matching credential and approves the requested disclosure.
* For SD-JWT credentials, the holder signs a key-binding JWT over the verifier's nonce and `programId`, so the presentation cannot be replayed or altered.
* The verifier receives a compliance result and a Verifiable Presentation containing the disclosed claims — nothing else.

The presentation wrapper is not signed. Verifiers should check the SD-JWT inside it on their own backend: see [Verify SD-JWT on your backend](/products/identity/verify-sd-jwt).

## Selective disclosure

Holders can disclose individual attributes without revealing the full credential. How this works depends on the [credential format](/products/identity/credential-formats):

* **SD-JWT VC.** Each disclosable claim is replaced in the signed credential by a salted digest. The holder sends only the disclosures for the requested claims, and the verifier checks each against its digest. The verifier sees the exact value of each disclosed claim.
* **Iden3.** A zero-knowledge proof can establish a condition, such as `kycLevel >= 2`, without revealing the value. An attribute Merkle root binds the proven fields to the signed credential.

Disclosed claims may still be personal data. Selective disclosure is defined at the schema and verification program level. See [Schema Design](/products/identity/schema-overview) for configuration.

## Credential revocation

Issuers revoke credentials from their own issuer service. Verification programs that enable issuer revocation checks reject a revoked credential once the revoked status is published. SD-JWT issuers can also publish an IETF Token Status List, which verifiers cache; revocation then reaches them after the issuer's publish interval. See [Revoke credentials](/products/identity/revocation).

## Credential storage

| Storage layer | What is stored | Encrypted? |
| - | - | - |
| Issuer systems | Raw source documents and issuer signing keys | Protected under issuer controls |
| DStorage (decentralized) | Signed credential payload (VC envelope) | Yes — encrypted to the holder |
| Moca Chain (on-chain) | Cryptographic hashes, storage metadata, and status records; for Iden3 programs, verification proofs when required | Do not treat public metadata as encrypted payloads |
| User device | Private keys, session tokens | Yes, managed by MPC shards |

## Further reading

* [Privacy & Compliance](/technicals/architecture/privacy-and-compliance) for encryption, ZK proofs, and consent
* [zkTLS](/technicals/architecture/zktls) for the zero-knowledge transport layer
* [Schema Design](/products/identity/schema-overview) for defining verifiable attributes


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.