Skip to main content
Issuance turns something an issuer already knows about a user, such as a membership tier or a completed KYC check, into a credential the user can carry to other apps. The issuer builds and signs the credential on its own service. AIR delivers it to the user and stores it encrypted. AIR never sees what is inside.

​
The five steps behind every credential

Whichever way a credential is issued, the issuer’s service performs the same five steps:

​
Who is involved

​
Two ways to issue

​
Two credential formats

Both are encrypted to the user and stored the same way. See Where credentials are stored, and for AIR’s part in every step, Where AIR participates.

​
What issuance guarantees

  • Authentic. The issuer’s signature proves who issued the credential and that nothing was changed.
  • Private. Only the holder can decrypt it. AIR, storage providers, and chain observers cannot.
  • Holder-bound. A verifier that asks for proof of possession rejects anyone who lacks the holder’s private key.
  • Issuer-controlled. AIR never holds issuer keys and cannot issue on an issuer’s behalf.
What it does not guarantee: that the claims are true (that depends on the issuer’s own checks), that two verifiers cannot link presentations of the same credential, or that disclosed copies disappear after revocation.

​
In this section

Where AIR participates

What AIR does, holds, and cannot do at each step.

Issuer setup

What must exist before the first credential.

On-demand issuance

The user previews and confirms.

How SD-JWT credentials work

Fingerprinted claims, holder binding, and issuer keys.

How Iden3 credentials work

Merkle trees, BabyJubJub signatures, and ZK proofs.

Where credentials are stored

The encrypted envelope, DStorage, and Moca Chain.

Revocation and updates

What happens after a credential is issued.
To build an issuer, follow the developer guide: Issuing credentials.