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.Documentation Index
Fetch the complete documentation index at: https://docs.moca.network/llms.txt
Use this file to discover all available pages before exploring further.
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
| Scenario | CAK needed? |
|---|---|
| Credential contains raw PII or biometric data that verifiers may need | Yes |
| Multiple verifiers require access to underlying identity data | Yes |
| Regulatory auditability of data access is required | Yes |
| Credential is used purely for ZK-based attribute proofs | No |
| No verifier ever requires access to plaintext data | No |
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
- Enable CAK on a Pricing Schema — This is the top-level switch. Only pricing schemas with CAK enabled can produce CAK-encrypted credentials.
- 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.
- Configure a Global Callback URL — Set an HTTPS endpoint via
POST /issuer/modify(passcallbackUrl). This endpoint receives authorization notifications whenever a Verifier is granted access to your users’ data.
Verifier setup
- Require CAK for a Verification Program — When enabled, only CAK-encrypted credentials are accepted and the user consent flow is mandatory.
- Select Issuers — If your verification program requires CAK, the system only shows Issuers that have enabled the CAK feature.
Phase 2: Credential issuance
When CAK is enabled for an issuance program, theissueCredential() SDK call includes additional encryption steps.
| Step | Party | Action |
|---|---|---|
| 1 | Issuance SDK | Generates a temporary CAK key pair locally by signing with the user’s identity wallet |
| 2 | Issuance SDK | Returns the CAK public key to the Issuer’s backend via callback |
| 3 | Issuer | Encrypts the user’s raw sensitive data (ID photo, name, biometrics) with the CAK public key |
| 4 | Issuer | Stores the encrypted ciphertext in dStorage |
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.| Step | Party | Action |
|---|---|---|
| 1 | Verifier | Calls POST /verifier/verify/initialize to start the verification flow |
| 2 | Verification SDK | Detects CAK requirement from program configuration |
| 3 | Verification SDK | Displays a clear authorization statement to the user |
| 4 | User | Grants or denies consent |
| 5 | Verification SDK | On consent, generates the CAK private key locally via identity wallet signing |
| 6 | Verification SDK | Returns the private key to the Verifier backend via callback |
| 7 | Platform | Updates callback record status and sends HTTPS notification to Issuer |
| 8 | Verifier | Requests semi-decrypted data from the Issuer (zkMe) |
| 9 | Issuer (zkMe) | Partially decrypts with managed key, returns semi-decrypted package |
| 10 | Verifier | Performs final decryption with CAK private key to obtain plaintext data |
verifyCredential() response includes a cakPrivateKey field when the result is "Compliant" and CAK is enabled. See Verifying Credentials for the SDK reference.
Platform responsibilities
The AIR Credential platform provides the following CAK capabilities:| Responsibility | Description |
|---|---|
| SDKs | Issuance and Verification SDKs include CAK key generation, consent UI, and callback handling |
| Key derivation | Deterministic CAK key pairs derived within SDKs via identity wallet signing (EIP-712 structured data) |
| Authorization UI | Standard, unified user consent interface in the Verification SDK |
| Callback dispatch | Reliable HTTPS notifications to the Issuer’s callback URL with retry logic |
| Record management | Authorization records and callback statuses maintained for full process traceability |
Cryptographic details
| Property | Value |
|---|---|
| Encryption scheme | ECIES (Elliptic Curve Integrated Encryption Scheme) |
| Default curve | SECP256R1 (P-256) |
| Alternative curve | SECP256K1 |
| Key derivation | Deterministic, based on [User - Issuer - Schema] composite identifier |
| Key pair generation | Local, 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.