Skip to main content
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. When zkMe issues credentials (for example through Veriff powered by zkMe), the cryptographic protections behind that Issuer — zkPassport, zkVault, and related zkMe Protocol components — are summarized for partners in KYC (Veriff powered by zkMe) — zkMe security architecture.

​
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:
  1. Encrypt raw sensitive data during credential issuance
  2. Store it securely so no party can read it at rest
  3. 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.

​
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.
1

Key pair generation

The Issuance SDK generates a temporary CAK key pair locally by signing with the user’s identity wallet.
2

Public key handoff

The SDK returns the CAK public key to the Issuer’s backend system.
3

Data encryption

The Issuer encrypts the user’s raw data (ID photo, name, biometric images) with the CAK public key.
4

Encrypted storage

The encrypted data is stored in decentralized storage (dStorage on Moca Chain). No party can read it without the corresponding private key.

​
Phase 3: Verification and authorization

When a user presents their credential to a Verifier, the CAK flow ensures consent-driven decryption.
1

Verification initialization

The Verifier’s backend starts the verification process via the platform API.
2

User consent

The Verification SDK displays a clear authorization statement. The user explicitly grants or denies the Verifier’s access to their encrypted data.
3

Private key generation

Upon user consent, the SDK generates the corresponding CAK private key locally.
4

Data decryption

The Verifier receives the private key and uses it to decrypt the user’s data, completing the compliance workflow.
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

  • 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

​
For Verifiers

​
For Users (Holders)

​
Glossary

​
Next steps

For technical integration details, see the AIR Kit developer documentation:

CAK overview

Technical architecture and lifecycle

Issuer guide

Dashboard setup, SDK integration, callback implementation

Verifier guide

Consent flow, decryption, security best practices