Skip to main content

​
What are AIR Credentials?

AIR Credentials are verifiable credentials that issuers sign with their own keys and that holders carry in their AIR Account to any app using AIR verification. 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) by disclosing only the fields a verifier requests. The result is privacy-preserving, issuer-sovereign identity.

​
How it works at a glance

  • SD-JWT credentials. Credentials use the SD_JWT_VC proof type by default: issuer-signed, selectively disclosable, and optionally bound to the holder’s key. Verification checks a signature and hashes, so it is fast and runs off-chain. Iden3 credentials with zero-knowledge proofs are an advanced option.
  • Issuer sovereignty. Issuers control their own source data and signing keys through an Issuer Backend. The Issuer DID (did:web:<your host>) is published from the issuer’s own domain 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, Moca Chain’s decentralized storage layer. 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 accepted format, requested claims, and selective disclosure. Successful verification returns a W3C Verifiable Presentation.
  • Fast. Issuance and verification typically complete in ~1–4 seconds.

​
The credential lifecycle

A credential goes through three phases:
  1. Issuance. The issuer builds, signs, and encrypts the credential, then stores the encrypted envelope in DStorage.
  2. Storage. AIR stores and routes the ciphertext and metadata. Only the holder can decrypt it.
  3. Verification. The holder discloses only the fields a Verification Program requests, and the verifier receives a Verifiable Presentation to check.
Every issuance and verification call is authenticated with a Partner JWT, which AIR checks against a JWKS endpoint you host and register in the Developer Dashboard. None of these phases can run until that endpoint is live. See JWKS endpoint setup.

​
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. Deploy your issuer service and register its did:web Issuer DID with AIR. Because the DID is published from your domain with your keys, you own it — AIR does not generate it for you. Registering your DID enables credential services on your account.
  3. Configure the supported signature type (SD_JWT_VC) and JWKS / key information.
  4. Create or search for a relevant Credential Schema.
  5. Create an issuance program.
  6. Integrate an Issuer Backend that AIR calls through available-vc and issue-vc when your frontend calls air.issueCredential — or use direct 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 the accepted proof type, requested claims, and selective disclosure.
  5. Integrate the AIR Verifier SDK and start verification with a programId and a nonce.
  6. On success, verify the returned presentation on your backend.
See Verifying Credentials for the full verifier integration.