> ## 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.

# Credentials Overview

> How AIR Credentials work — issuer, holder, and verifier roles, signature-based proofs, encrypted DStorage, and program-driven verification on Moca Chain.

## What are AIR Credentials?

**AIR Credential** is a universal, decentralized verifiable credential system designed for seamless use across digital applications and networks. Issuers sign credentials with their own keys, credential payloads are encrypted to the holder before storage, and AIR stores and routes only opaque ciphertext and metadata — it never sees the underlying data. Holders prove claims (such as age, qualifications, or affiliations) through signature-based proofs, with optional zero-knowledge proofs where a program requires them. The result is privacy-preserving, issuer-sovereign, cross-ecosystem identity.

## How it works at a glance

* **Signature-based credentials.** Credentials use the `BJJ_SIG_2021` signature proof type. Proofs are generated from the issuer's signature, so verification is fast and does not depend on publishing proof state on-chain.
* **Issuer sovereignty.** Issuers control their own source data and signing keys through an Issuer Backend. Because the issuer holds its keys, its Issuer DID is derived from those keys and registered with AIR — AIR never holds issuer keys, signs on the issuer's behalf, or sees plaintext data.
* **Encrypted decentralized storage.** The issuer signs the credential, encrypts the payload to the holder's public key, and stores the encrypted envelope in DStorage on Moca Chain. AIR acts as a blind facilitator — it stores and routes ciphertext and metadata, never plaintext.
* **Program-driven verification.** Verifiers configure a Verification Program that centrally controls the proof type, whether ZKP is required, selective disclosure, and off-chain or on-chain mode. Successful verification returns a W3C Verifiable Presentation.
* **Fast.** Issuance and verification typically complete in \~1–4 seconds.

## Who's Who: Issuer, Holder, Verifier

|                 | **Issuer**                                                                                                                                      | **Holder**                                                                                                     | **Verifier**                                                                                                                                                                         |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Role**        | The entity that creates and vouches for the verifiable credential.                                                                              | The individual or entity that receives and stores the encrypted credential in their AIR Account.               | The party that requests and checks for proof of specific claims or attributes.                                                                                                       |
| **Key Actions** | Owns source data, signs and encrypts credentials                                                                                                | Receives, holds, and presents credentials                                                                      | Configures verification programs and consumes proofs                                                                                                                                 |
| **Details**     | The issuer structures the data, signs it with issuer-controlled keys, encrypts it to the holder, and stores the encrypted envelope in DStorage. | The holder receives an encrypted payload only they can decrypt, and controls how their credentials are shared. | Instead of accessing the full credential, the verifier receives a signature-based proof — and a zero-knowledge proof where the program requires one — bound to the requested claims. |
| **Examples**    | Universities, governments, protocols, DAOs, gaming platforms, community managers                                                                | Students, citizens, gamers, employees, community members                                                       | Employers, service providers, event organizers, online platforms, access-controlled communities                                                                                      |

## AIR as a blind facilitator

In the AIR model, the trust boundary sits with the issuer, not with AIR:

* Issuer user data remains with the issuer.
* The issuer signs credentials with issuer-controlled keys.
* Credential payloads are encrypted to the holder's public key before storage.
* AIR stores encrypted credential objects and metadata — not plaintext issuer data.
* Only the holder can decrypt the credential and generate proofs from it.

This keeps AIR out of the plaintext data path while still providing storage, routing, discovery, and program-driven verification.

## Choose your integration role

| Role               | Primary integration                     | Notes                                                                              |
| ------------------ | --------------------------------------- | ---------------------------------------------------------------------------------- |
| **Issuer**         | Issuer Backend + AIR Dashboard setup    | Best path for on-demand issuance, privacy, revocation, and issuer-controlled data. |
| **Verifier**       | Verification Program + AIR Verifier SDK | Verifiers use program-driven verification behavior.                                |
| **Issuer site**    | Self-hosted frontend + AIR Issuer SDK   | Recommended when issuers want full UX/auth control.                                |
| **Verifier site**  | Self-hosted frontend + AIR Verifier SDK | Recommended when verifiers want full UX/auth control.                              |
| **Bulk migration** | Operational bulk import                 | For large backfills; coordinate early because it may require manual operations.    |

## Issuer Process

1. Set up a Partner Account in the <a href="https://developers.sandbox.air3.com/dashboard" target="_blank" rel="noreferrer">Developer Dashboard</a>.
2. Generate your Issuer DID from your own signing keys and register it with AIR. Because you hold your keys, you own your DID — AIR does not generate it for you. Registering your DID enables credential services on your account.
3. Configure supported signature types (`BJJ_SIG_2021`) and JWKS / key information.
4. Create or search for a relevant Credential Schema.
5. Create an issuance program.
6. Integrate an Issuer Backend so your frontend can request available credentials via `available-vc` and call `air.issueCredential` — or use [on-demand issuance](/airkit/usage/credential/issuing-credentials#on-demand-issuance) when a backend event should issue without a user session.
7. Issue encrypted credentials to your users.

See [Issuing Credentials](/airkit/usage/credential/issuing-credentials) for both the SDK and on-demand issuance paths.

## Verifier Process

1. Set up a Partner Account in the <a href="https://developers.sandbox.air3.com/dashboard" target="_blank" rel="noreferrer">Developer Dashboard</a>.
2. Configure General Partner settings and obtain a Verifier DID.
3. Search for relevant Credential Schemas and Issuers.
4. Create a Verification Program and configure proof type, requested claims, selective disclosure, ZKP requirement, and off-chain / on-chain mode.
5. Integrate the AIR Verifier SDK and start verification with a `programId`.
6. Consume the returned Verifiable Presentation on success.

See [Verifying Credentials](/airkit/usage/credential/verify) for the full verifier integration.