Skip to main content
This guide covers everything a Verifier needs to integrate with the Compliance Access Key (CAK) framework: configuring a verification program that requires CAK, handling the user consent flow, receiving the CAK private key, and performing secure decryption of user data.
Before starting, make sure you understand the CAK lifecycle overview.

​
Verifier responsibilities summary

ResponsibilityDescription
CAK requirement configurationEnable CAK requirement for verification programs in the Dashboard
Verification initializationCall the platform’s initialization endpoint at the start of each verification flow
Private key secure handlingReceive the CAK private key from the SDK and use it in-memory only
Data decryption integrationDecrypt the semi-decrypted data package using the CAK private key
Data handling complianceHandle, store, and destroy decrypted data per applicable regulations

​
Step 1: Dashboard configuration

​
Require CAK for a verification program

In the Developer Dashboard, create or edit a verification program and enable the CAK requirement. When CAK is required:
  • Only CAK-encrypted credentials are accepted for verification
  • The user consent flow is mandatory — the Verification SDK displays an authorization statement
  • Only Issuers that have enabled CAK are available as partners when configuring the program
When CAK is not required:
  • Both CAK-encrypted and standard credentials are accepted
  • The consent flow is not triggered, even for CAK-encrypted credentials

​
Select Issuers

If your verification program requires CAK, the system only shows Issuers that have the CAK feature enabled. Select the Issuers whose credentials you want to verify.

​
Step 2: Initialize verification

At the start of each verification flow, your backend must call the platform’s initialization endpoint. This creates a callback record that tracks the authorization lifecycle. 
POST /verifier/verify/initialize

{
  "issuerDid": "did:air:id:..."
}
Pass the issuerDid of the Issuer whose credential is being verified. The platform creates a callback record with an initial NOT_SEND (-1) status.
The Verification SDK handles the consent flow automatically when it detects that the verification program requires CAK.

​
What happens

  1. The SDK reads the verification program configuration and detects the CAK requirement
  2. The SDK displays a clear authorization statement to the user, requesting consent to share their encrypted data with your system
  3. The user makes a manual choice: Agree or Deny
When the user grants consent:
  1. The SDK generates the corresponding CAK private key locally by signing with the user’s identity wallet
  2. The SDK returns the private key to your backend via the verification callback
  3. The platform updates the callback record from NOT_SEND (-1) to PENDING (0) and sends a notification to the Issuer

​
On user denial

When the user denies consent:
  • The verification process is aborted
  • No private key is generated or returned
  • The user’s encrypted data remains inaccessible
  • The user may be unable to complete their business with your service

​
SDK integration

Call verifyCredential() as usual. When CAK is enabled and the verification is successful, the response includes a cakPrivateKey field. 
const result = await airService.verifyCredential({
  authToken,    // Partner JWT with scope=verify
  programId,    // Verification program ID
  redirectUrl,  // Optional: redirect if user lacks the credential
});

if (result.status === "Compliant") {
  const { cakPrivateKey, zkProofs, transactionHash } = result;
  // Use cakPrivateKey to decrypt user data
}
Compliant response fields:
FieldTypeDescription
status"Compliant"Credential is valid and meets all verification requirements
zkProofsRecord<string, string>Zero-knowledge proofs generated for the verification
transactionHashstringOn-chain transaction hash of the verification
cakPrivateKeystringCAK private key for decrypting the user’s encrypted data. Only present when CAK is enabled
The cakPrivateKey is only returned when all of these conditions are met: (1) the verification status is "Compliant", (2) CAK was enabled for the issuance program, and (3) your verification program requires CAK.

​
Step 4: Decrypt user data

After receiving the CAK private key, you can decrypt the user’s sensitive data through a two-stage process.

​
Stage 1: Request semi-decrypted data

Call the Issuer’s (zkMe) Semi-Decrypted Data API to request the user’s encrypted data. This is not a direct download from dStorage — the Issuer partially decrypts the data using their managed key first. The Issuer:
  1. Validates your request (identity, authorization relationship)
  2. Fetches the encrypted data from dStorage
  3. Performs initial decryption with their managed key to produce a semi-decrypted data package
  4. Returns the package via a signed, time-limited download URL
  5. Logs the request in the audit trail

​
Stage 2: Final decryption with CAK private key

Use the CAK private key to decrypt the semi-decrypted data package. This produces the user’s original raw information:
  • Full name, date of birth, document numbers
  • Identity document images (ID cards, passports)
  • Facial biometric photos
  • Other structured identity fields
The two-stage decryption ensures that neither the Issuer alone nor the Verifier alone can access the plaintext data. Both must participate, and both stages require prior user consent.

​
Security best practices

The CAK private key must be used exclusively in-memory. Never write it to disk, database, logs, or any persistent storage. Discard it immediately after decryption is complete.
After using the decrypted data for your compliance process (account opening, eligibility check, etc.), destroy it according to your data retention policy. Only keep what your regulatory obligations specifically require.
The decrypted data is raw PII. Treat it with the highest level of data protection. Implement access controls, encryption at rest for any required storage, and data subject rights handling (access, deletion).
All communication between your systems and the AIR Credential platform must use HTTPS/TLS. The semi-decrypted data download URL is time-limited and pre-signed — use it immediately.
Log every instance of decryption, including the user ID, timestamp, purpose, and personnel involved. This audit trail is critical for regulatory compliance.

​
Verification flow diagram