Privacy & Compliance
AIR Kit is built around a privacy-first architecture. Credentials use zero-knowledge proofs so verifiers receive only boolean results (“compliant” or “non-compliant”) without accessing raw personal data. For regulated industries that require verifiers to access underlying identity data, AIR Kit provides an additional layer: the Compliance Access Key (CAK) framework.Compliance Access Key (CAK)
CAK is an optional, consent-gated data access primitive designed for regulated data usage. It enables strong encryption of sensitive personal data during credential issuance and controlled decryption during verification — all driven by explicit user consent.The core problem
In finance, digital identity (KYC), and other regulated industries, organizations handle extremely sensitive information: ID cards, passports, facial biometric images, and other compliance data. The challenge is threefold:- Encrypt raw sensitive data during credential issuance
- Store it securely so no party can read it at rest
- Decrypt it only when a specific Verifier has obtained explicit consent from the user
How CAK addresses it
CAK introduces a user-consent-driven encryption and decryption process built on four principles:Data protection at rest
Sensitive data is encrypted with a temporary CAK public key during issuance. The ciphertext cannot be read by anyone — including the Issuer, the platform, or any storage provider — until a consented Verifier receives the corresponding private key.
User sovereignty
The user is the ultimate controller. During verification, the user must explicitly approve or deny each Verifier’s access request. Without consent, no party can decrypt the data.
Compliance enablement
Encrypted storage, user-controlled access, and traceable authorization records provide technical primitives that support compliance efforts — including audit trails and clear responsibility boundaries.
Separation of concerns
Encryption happens at issuance (performed by the Issuer). Decryption authorization happens at verification (executed by the Verifier with user consent). The two steps are separated in time and space, creating a clear audit trail.
CAK in the credential lifecycle
CAK spans three phases of the digital credential lifecycle.Phase 1: Business configuration
Before any credentials are issued, administrators configure rules in the Developer Dashboard.| Party | Action | CAK decision |
|---|---|---|
| Issuer | Configure Pricing Schema | Decide if credentials under this pricing model support CAK encryption |
| Issuer | Create Issuance Program | Choose whether to enable CAK for this specific program |
| Issuer | Configure Callback URL | Set a global HTTPS endpoint to receive authorization notifications |
| Verifier | Create Verification Program | Decide if this program requires the credential to be CAK-encrypted |
Phase 2: Credential issuance
When a user applies for a credential (for example, completing a KYC check), the CAK flow adds encryption steps to the standard issuance process.Key pair generation
The Issuance SDK generates a temporary CAK key pair locally by signing with the user’s identity wallet.
Data encryption
The Issuer encrypts the user’s raw data (ID photo, name, biometric images) with the CAK public key.
Phase 3: Verification and authorization
When a user presents their credential to a Verifier, the CAK flow ensures consent-driven decryption.Verification initialization
The Verifier’s backend starts the verification process via the platform API.
User consent
The Verification SDK displays a clear authorization statement. The user explicitly grants or denies the Verifier’s access to their encrypted data.
Private key generation
Upon user consent, the SDK generates the corresponding CAK private key locally.
The platform’s callback mechanism serves only as an authorization event notification and audit signal. It does not contain encrypted data, cryptographic keys, or any information that would enable direct data access.
When to use CAK
- CAK recommended
- CAK not necessary
- Raw identity data (ID images, biometric photos) may be accessed by verifiers
- Multiple verifiers need access to the same underlying data
- Regulatory auditability is a requirement
- Your industry requires proof that user consent was obtained before data access
Key decisions by party
For Issuers
| Decision | Options | Impact |
|---|---|---|
| Enable CAK for a pricing schema? | Yes / No | Top-level switch — determines whether CAK-enabled credentials can be issued under this pricing model |
| Enable CAK for an issuance program? | Yes / No | Yes: SDK generates a key pair and returns the public key for encryption. No: Standard issuance flow |
| Configure a callback URL? | Provide URL / Leave blank | Provide URL: Real-time notifications about which user authorized which verifier, critical for auditing. Leave blank: No notifications |
For Verifiers
| Decision | Options | Impact |
|---|---|---|
| Require CAK for a verification program? | Yes / No | Yes: Only CAK-encrypted credentials accepted; user consent flow is mandatory. No: Both CAK and non-CAK credentials accepted |
| Which Issuers to select? | CAK-enabled only / All | If CAK is required, only Issuers with CAK enabled are available as partners |
For Users (Holders)
| Decision | Options | Impact |
|---|---|---|
| Authorize the Verifier? | Agree / Deny | Agree: Verifier gains one-time decryption ability. Deny: Verification aborted, data stays encrypted, but the user may be unable to complete their business with that Verifier |
Glossary
| Term | Definition |
|---|---|
| CAK | Compliance Access Key — an optional, user-consent-driven encryption framework |
| Issuer | An entity that issues credentials (e.g., a KYC provider) |
| Verifier | An entity that verifies credentials to grant access to a service (e.g., a crypto exchange) |
| Holder | The end-user who owns and controls their credentials and data |
| dStorage | Decentralized Storage on Moca Chain, used for storing encrypted data packages |
| ECIES | Elliptic Curve Integrated Encryption Scheme — a hybrid encryption scheme using ECC |
| SECP256R1 | The elliptic curve (P-256) used for CAK key generation |