Skip to main content

​
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

​
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

​
Issuer Process

  1. Set up a Partner Account in the Developer Dashboard.
  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 when a backend event should issue without a user session.
  7. Issue encrypted credentials to your users.
See Issuing Credentials for both the SDK and on-demand issuance paths.

​
Verifier Process

  1. Set up a Partner Account in the Developer Dashboard.
  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 for the full verifier integration.