Skip to main content
The Compliance Access Key (CAK) is an optional encryption framework that enables regulated data usage without platform-level custody, key escrow, or implicit trust assumptions. When enabled, sensitive user data is encrypted during credential issuance and can only be decrypted by a Verifier who has obtained explicit user consent.
CAK is optional. If your credentials do not contain raw PII or biometric data, or if verifiers only need zero-knowledge proof results, the standard AIR Kit flow is sufficient.

​
When to use CAK

ScenarioCAK needed?
Credential contains raw PII or biometric data that verifiers may needYes
Multiple verifiers require access to underlying identity dataYes
Regulatory auditability of data access is requiredYes
Credential is used purely for ZK-based attribute proofsNo
No verifier ever requires access to plaintext dataNo

​
Three-phase lifecycle

CAK operates across the entire credential lifecycle: configuration, issuance, and verification.

​
Phase 1: Dashboard configuration

Before any credentials are issued, administrators configure the CAK rules in the Developer Dashboard.

​
Issuer setup

  1. Enable CAK on a Pricing Schema — This is the top-level switch. Only pricing schemas with CAK enabled can produce CAK-encrypted credentials.
  2. Enable CAK on an Issuance Program — When enabled, the Issuance SDK will generate a CAK key pair during issuance and return the public key to your system for encryption.
  3. Configure a Global Callback URL — Set an HTTPS endpoint via POST /issuer/modify (pass callbackUrl). This endpoint receives authorization notifications whenever a Verifier is granted access to your users’ data.

​
Verifier setup

  1. Require CAK for a Verification Program — When enabled, only CAK-encrypted credentials are accepted and the user consent flow is mandatory.
  2. Select Issuers — If your verification program requires CAK, the system only shows Issuers that have enabled the CAK feature.
For step-by-step configuration instructions, see the Issuer guide and Verifier guide.

​
Phase 2: Credential issuance

When CAK is enabled for an issuance program, the issueCredential() SDK call includes additional encryption steps.
StepPartyAction
1Issuance SDKGenerates a temporary CAK key pair locally by signing with the user’s identity wallet
2Issuance SDKReturns the CAK public key to the Issuer’s backend via callback
3IssuerEncrypts the user’s raw sensitive data (ID photo, name, biometrics) with the CAK public key
4IssuerStores the encrypted ciphertext in dStorage
The issueCredential() response includes a cakPublicKey field when CAK is enabled. See Issuing Credentials for the SDK reference.

​
Phase 3: Verification and authorization

When a user presents a CAK-encrypted credential to a Verifier, the process includes a consent step and a two-stage decryption.
StepPartyAction
1VerifierCalls POST /verifier/verify/initialize to start the verification flow
2Verification SDKDetects CAK requirement from program configuration
3Verification SDKDisplays a clear authorization statement to the user
4UserGrants or denies consent
5Verification SDKOn consent, generates the CAK private key locally via identity wallet signing
6Verification SDKReturns the private key to the Verifier backend via callback
7PlatformUpdates callback record status and sends HTTPS notification to Issuer
8VerifierRequests semi-decrypted data from the Issuer (zkMe)
9Issuer (zkMe)Partially decrypts with managed key, returns semi-decrypted package
10VerifierPerforms final decryption with CAK private key to obtain plaintext data
The verifyCredential() response includes a cakPrivateKey field when the result is "Compliant" and CAK is enabled. See Verifying Credentials for the SDK reference.
The CAK private key must be used in-memory only. Never persist it to disk, database, or logs.

​
Platform responsibilities

The AIR Credential platform provides the following CAK capabilities:
ResponsibilityDescription
SDKsIssuance and Verification SDKs include CAK key generation, consent UI, and callback handling
Key derivationDeterministic CAK key pairs derived within SDKs via identity wallet signing (EIP-712 structured data)
Authorization UIStandard, unified user consent interface in the Verification SDK
Callback dispatchReliable HTTPS notifications to the Issuer’s callback URL with retry logic
Record managementAuthorization records and callback statuses maintained for full process traceability

​
Cryptographic details

PropertyValue
Encryption schemeECIES (Elliptic Curve Integrated Encryption Scheme)
Default curveSECP256R1 (P-256)
Alternative curveSECP256K1
Key derivationDeterministic, based on [User - Issuer - Schema] composite identifier
Key pair generationLocal, via identity wallet signing (EIP-712)

​
Next steps

Issuer integration

Dashboard configuration, SDK integration, encryption workflow, and callback endpoint implementation.

Verifier integration

Verification setup, user consent flow, decryption workflow, and security best practices.