Skip to main content
AIR supports two credential families. Every AIR credential is issuer-signed, encrypted to the holder, and presented with the holder’s approval. The format decides what a verifier can learn and how it checks the result.

​
How they compare

Both formats support selective disclosure. The choice comes down to whether you need the simplicity of a JWT or the extra privacy of a zero-knowledge proof.

​
Which should I use

Use SD-JWT VC unless you have a specific reason not to. It is the better fit for:
  • Most partner integrations: membership, loyalty tier, KYC attributes, tickets.
  • Verifiers on your own backend, using standard JWT libraries.
  • Integrations with external parties that work with IETF and OpenID tooling.
Ask about Iden3 when you need:
  • Predicate proofs, such as “over 18” or “balance above a threshold”, without revealing the underlying value.
  • Presentations that verifiers cannot link to each other.
  • Verification by a smart contract.

​
Holder binding for SD-JWT

An SD-JWT VC can be bound to its holder, so a copy that leaks cannot be presented by someone else.
  1. At issuance, the user’s AIR Account provides a P-256 public key. The issuer writes it to the credential’s cnf.jwk claim before signing.
  2. At verification, your app passes a nonce. The holder signs a key-binding JWT (KB-JWT) with the matching private key. The KB-JWT covers your nonce, your programId, a timestamp, and a hash of the disclosed claims.
  3. Your backend checks the KB-JWT against cnf.jwk. A replayed or altered presentation fails.
Without a nonce, or for a credential issued without cnf, the presentation is a bearer token. See Verify SD-JWT on your backend for the checks.

​
Standards each format uses

Supporting a standard does not on its own make a deployment compliant with a regulation. That depends on the issuer, the assurance model, and the rules of the jurisdiction.