> ## 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. # Other ways to verify > AIR issues SD-JWT VC credentials by default. Iden3 BJJ credentials with zero-knowledge proofs are an advanced option the AIR team enables. 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. | Format | Proof type | Availability | | - | - | - | | **SD-JWT VC** (IETF SD-JWT-based Verifiable Credentials) | `SD_JWT_VC` | Default. Self-serve in sandbox and production. | | **Iden3** (BJJ signature) | `BJJ_SIG_2021` | Advanced. Contact the AIR team to enable it. See [Iden3 credentials](/products/identity/iden3-credentials). | ## 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. | | SD-JWT VC | Iden3 BJJ | | - | - | - | | **What the verifier learns** | The exact value of each claim the holder discloses, such as `age: 25`. Undisclosed claims stay hidden behind salted digests. | Exact values, or a condition such as `age > 18` proven without revealing the value. | | **Linkability** | The issuer-signed token is the same in every presentation, so verifiers that compare notes can link them. | Proofs are randomized for each presentation and are unlinkable. | | **Holder cost** | Near instant. The holder sends the selected disclosures. | Proof generation takes seconds of CPU on the holder's device. | | **Verifier cost** | Sub-millisecond: check one signature and hash the disclosures. | Milliseconds, with a ZK verifier and verification keys. | | **Verifier tooling** | Standard JWT libraries. | An Iden3-specific verifier with circuits and on-chain issuer state. | | **Holder binding** | Optional `cnf` key in the credential, plus a key-binding JWT for each presentation. | Depends on the proof profile. | | **Revocation** | Per-credential status endpoint, or an IETF Token Status List. | Non-membership proof against the issuer's revocation tree. | | **On-chain verification** | Not used. Verification is off-chain. | Supported through the Universal Verifier and Groth16 verifier contracts. | ## 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](/products/identity/verify-sd-jwt) for the checks. ## Standards each format uses | Standard | Used by | Notes | | - | - | - | | IETF SD-JWT-based Verifiable Credentials | SD-JWT VC | Selective disclosure and optional key binding. External acceptance depends on the verifier's algorithms, metadata, and trust policy. | | `did:web` | SD-JWT VC issuers | The issuer DID resolves to a DID document on the issuer's own domain. | | IETF Token Status List | SD-JWT VC | Optional, and configured per issuer. See [Revoke credentials](/products/identity/revocation#token-status-list). | | W3C Verifiable Credentials Data Model v1.1 (JSON-LD) | Iden3 | Defines the credential structure. Verifiers must also implement the Iden3 proof profile; generic W3C VC support is not enough. | | W3C Verifiable Presentation (VC Data Model v2.0) | Both | The envelope a successful verification returns. Each enclosed credential is checked in its own format. | 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. ## Related * [Issuing credentials](/products/identity/issuing-credentials) * [Verifying credentials](/products/identity/verify) * [Selective disclosure](/products/identity/selective-disclosure) * [Iden3 credentials](/products/identity/iden3-credentials) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.