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

ZeroVerify 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.