Technical Specification

Product Overview

Problem Statement

Existing identity verification systems require users to disclose entire credential documents (student IDs, driver's licenses) to prove a single attribute, creating unnecessary privacy exposure and centralized data liability for verifiers. ZeroVerify allows circuit-defined attributes ("I am an enrolled student," "I am over 21") to be cryptographically proven without revealing any underlying personal data.

MVP Features

Credential Issuance: ZeroVerify authenticates the user via OAuth/OIDC IdP, generates a W3C Verifiable Credential, signs it with BBS+ signature, and delivers it to the user's client for local storage
Proof Generation: User's client runs a zk-SNARK circuit against locally-stored credential, producing a proof of boolean claim without revealing underlying attributes
Proof Verification: Verifier uses open-source SDK to validate zk-proof against issuer's verification key and checks revocation status via W3C Bitstring Status List

System Architecture

Click diagram to view full size

Architectural Boundary

ZeroVerify is a library and issuance service, not a verification intermediary. The system provides: (1) an issuance API that issues BBS+ signed credentials, (2) a client-SDK that handles credential storage and proof generation, and (3) a verification library that verifiers embed. Verifiers interact directly with users and only call ZeroVerify to get a W3C revocation bitstring.

Tech Stack

Backend: AWS Lambda (Rust)

Serverless issuance function behind API Gateway. Lambda provides per-invocation billing and automatic scaling for unpredictable traffic spikes. Rust chosen for fast cold starts (100-300ms vs Java's 1-3s), memory safety guarantees, and mature BBS+ signature library ecosystem. Target: <800ms total execution time.

Database: AWS DynamoDB

Credential metadata stored with key-value access pattern. Supports fast lookups for duplicate credential prevention and revocation status.

Revocation Storage: AWS S3

W3C Bitstring Status List stored as static object and replicated globally using S3 Cross Region Replication. Bitstring is small (1 bit per credential).

Client SDK: TypeScript

Proof generation library running entirely in browser. Fetches keys from ZeroVerify and executes Groth-16 zk-SNARK prover compiled to WebAssembly.

Infrastructure: Terraform/OpenTofu

Infrastructure defined as code for reproducible deployments and CI/CD.

Data Design

Credential Metadata Schema

{
  "subject_id": "did:key:z6MkF5rGMoatr...",
  "credential_id": "https://api.zeroverify.com/credentials/a3f8b2c1-...",
  "credential_type": "Student_Credential",
  "issued_at": "2025-02-10T20:41:27Z",
  "expiresAt": "2026-02-10T20:41:27Z",
  "revocation_index": 94567,
  "revoked": false
}

Relationships

One user can have multiple credentials from different sources (University, Job, Government)
One user can generate many different proofs
Each signed credential can be used to generate many proofs

Performance Goals

Credential Issuance

OAuth/OIDC authentication: <500ms
Lambda execution: <800ms
BBS+ signature operation: 0.3-7.5ms per credential
DynamoDB write: ~20ms
Credential delivery to user: ~200ms

Client-Side Proof Generation

zk-SNARK circuit execution: <4 seconds

Proof Verification

Complete verification: <300ms
Cryptographic zk-proof validation: <150ms
Bitstring retrieval from S3: <100ms

Revocation Processing

Revocation update latency: <10 min from request to global availability
Batch processing: 100 revocations/batch
Lambda execution time: <3s/batch
Target: 99.9% consistency for concurrent revocation updates

Security

All communication uses HTTPS (TLS 1.2+)
Server-side data encrypted using AWS KMS
ZeroVerify does not store raw PII after credential issuance
Credentials stored locally in browser, never retransmitted to any server
Each proof bound to verifier-provided session nonce to prevent replay attacks
Session identifiers expire after fixed time window (5 minutes)
Verification validates proof structure, cryptographic validity, issuer signature, and revocation status
IAM roles follow least privilege principles
Signing keys stored in AWS Secrets Manager, never hardcoded
System never returns "valid" if verification fails or is incomplete

Limitations and Tradeoffs

Credential Revocation

We implement W3C Bitstring Status Lists rather than PKI mechanisms (CRL/OCSP) because bitstrings preserve verification privacy. Bitstrings encode revocation as bit positions in a compressed list; merchants fetch the bitstring and check locally without revealing which credential they're verifying.

Proof Generation Cost

Generating ZK Proofs takes 2-5 seconds on modern devices. This is more compute-intensive than submitting a form but faster than uploading documents and waiting for manual approval. The computational cost shifts from servers to user's device.

Browser Security

Browser-based credential storage is less secure than hardware wallets. However, our architecture never transmits credentials after issuance. Credentials always stay on the device, and only ZK proofs are sent. We trade hardware-level security for zero data disclosure.

Trust Model

Merchants trust our mechanism through cryptographic verification, not reputation. The ZK proof is mathematically verifiable using our public key. We issue credentials only after OAuth confirmation from the authoritative source. Merchants can audit our public key and verification code for transparency.