ZeroVerify Technical Specification

Version: 1.0 | Date: 2/15/26

Team: Lisa Nguyen (CS), Anton Sakhanovyvh (CS), Souleymane Sono (CS), Fateha Ima (CS), Simon Griemert (CS)

(CS) = Computer Science Major

Product Overview (The “What”)

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.

Target User: The primary persona is an end user (student, individual) who holds a digitally-issued credential and needs to selectively prove specific attributes to third-party verifiers (merchants, services, platforms) without exposing their full identity. Secondary actors are institutional identity providers (universities, employers) whose OAuth/OIDC infrastructure ZeroVerify delegates to for attribute verification during issuance, and verifiers (merchants, services) who integrate ZeroVerify’s open-source SDK to cryptographically validate proofs.

Minimum Viable Product (MVP) Features:

System Architecture (The “How”)

System Diagram

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. They only call ZeroVerify to get a W3C revocation bitstring.

The Tech Stack

Backend: AWS Lambda (Rust)

The credential issuance service is implemented as a serverless Lambda function behind the API Gateway. Lambda is appropriate here because issuance is a stateless, event-driven operation with low baseline traffic and unpredictable spikes during enrollment periods. A persistent server (EC2 or ECS) would be over-provisioned at idle and require operational management that adds no architectural value for this workload. Lambda’s per-invocation billing and automatic scaling match the issuance traffic pattern.

Rust was chosen over Java or other runtime options because Lambda cold start times are critical for issuance responsiveness (target < 800ms total execution). Rust Lambda functions have significantly faster cold starts ( 100-300ms) compared to Java ( 1-3s) and lower memory footprint. Since issuance operations involve cryptographic operations (BBS+ signing) where memory safety is critical, Rust’s compile-time guarantees eliminate entire classes of vulnerabilities without runtime overhead. The BBS+ signature library ecosystem in Rust is mature, and Rust’s zero-cost abstractions ensure the 6-7.5ms signature operation target is achievable without JVM garbage collection pauses.

Database: AWS DynamoDB

Credential metadata is stored in DynamoDB. The access pattern is entirely key-value.

Revocation Storage: AWS S3

The revocation bitstring (a Bitstring Status List per the W3C spec) is stored as a static object in S3 and replicated globally using S3 Cross Region Replication (CRR). The bitstring is small (1 bit per credential) so CDN is not justified.

Client SDK: TypeScript

The proof generation library that runs entirely in the browser. The library fetches needed keys from ZeroVerify.

Infrastructure/IaC: Terraform/OpenTofu

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

External APIs & Integrations

University OAuth 2.0/OIDC IdP

Used during credential issuance to authenticate the user and fetch authoritative attribute claims (enrollment status) from the IdPs” endpoint.

AWS Secrets Manager

The BBS+ issuer private key is stored here, since AWS KMS does not support BBS+ as it is not a NIST-standardized algorithm.

Data Design

Core Entities

List the 3–4 most important data objects:

Proof Entity Schema

{
  "proof_type": "age_over_21",
  "proof": "base64_zkSNARK_proof_bytes",
  "public_inputs": {
    "challenge": "n-0S6_WzA2Mj",
    "credential_status_index": 94567
  }
}

Credential Entity Schema

{
  "student_id": "G89u28394",
  "email": "anton@oakland.edu",
  "first_name": "Anton",
  "last_name": "Sakhanovych",
  "birthdate": "2000-05-15",
  "custom_claims": {
    "student_status": "enrolled",
    "enrollment_date": "2021-09-01",
    "university": "Oakland University",
    "major": "Computer Science"
  }
}

Data Schema

Relationships:

Credential Metadata Table:

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

Storage Strategy

The files will be stored in AWS S3 and metadata about issued credentials will be in AWS DynamoDB.

Technical Complexity & Depth

The “Hard” Part

Integrating with existing Authentication protocols

OAuth/OIDC protocol variability: institutions use different implementations with varying standards compliance, attribute formats.

Designing Efficient and expressive zk-SNARK circuit

Designing circuits that prove boolean claims (e.g “Over 21”, “is student”) without revealing any underlying attributes.

Revocation consistency and batch processing

The core challenge is preventing race conditions when multiple Lambda functions concurrently process revocation requests. For example: 1000 users generate revocation requests → SQS queue batches them (100 requests/batch) → lambda reads S3 bitstring, modifies bits for all 100 requests, write back to S3. However, concurrent lambda invocations reading and writing the same S3 file create race conditions where revocation updates can be lost or overwritten. The solution is implementing optimistic locking or atomic update mechanism to ensure all revocation bit flips are captured under high concurrency.

Performance Goals

Credential Issuance

Client-Side Proof Generation Performance

Proof Verification

BBS+ Signature Operation

Revocation Processing

Resilience & Security

Error Handling

Security

Milestone Roadmap (The “When”)

Phase 1 (Weeks 1-3): Prototype Implementation

Infrastructure + Database Schema + Issuance Skeleton (API endpoints)

Trusted Setup (required before credential generation + proofs)

Credential Issuance Flow

Replay Protection (session nonce/challenge binding)

Proof Generation + User Consent (at least 1 proof type)

Verifier Verification Flow (Accepted/Rejected) (last step)

Phase 4 (Week 4-6): Hardening + UI + Testing

Goal: Done by April 13

Error handling + clear rejection reasons

Revocation checking (if in scope for demo)

UI polish for demo flow

Testing plan + test cases

Phase 5 (Week 7-Finals): Final Checklist + Demo Prep

Deployment/demo packaging + documentation cleanup

Final deliverables prep

Final product demo (Finals Week)

Limitations and Tradeoffs

Credential Revocation

We implement W3C Bitstring Status Lists rather than PKI mechanisms (CRL/OCSP) because bitstrings preserve verification privacy. CRL requires merchants to download lists of revoked credential identifiers, creating linkability. OCSP requires real-time queries with credential identifiers, exposing verification patterns. Bitstrings encode revocation as bit positions in a compressed list; merchants fetch the bitstring, check the relevant bit locally, reveal nothing about which credential they’re verifying. Users self-revoke by generating ZK proofs of credential ownership. Time-based expiration handles normal lifecycle without revocation overhead.

Proof Generation Cost

Generating ZK Proofs takes 2-5 seconds on modern devices. This is more compute-intensive than submitting a SheerID form. However, it is faster than uploading the document and waiting for manual approval. The computational cost shifts from servers to user’s device.

Browser Security vs Apple’s hardware wallet

Browser-based credentials storage is less secure than Apple’s secure element. However, our architecture never transmits the credentials. Credentials always stay on the device, and only ZK proofs are sent. Even if someone compromises browser storage, they get only one user’s credentials, not a centralized database of millions. Apple’s approach is more secure, but their selective disclosure still sends identity data. We trade hardware-level security for zero data disclosure.

Trust

Merchants trust our mechanism through cryptographic verification, not reputation. The ZK proof is mathematically verifiable using our public key; if it verifies, the credential was genuinely issued by us and hasn’t been tampered with. We issue credentials only after OAuth confirmation from the authoritative source; the issuer is the source of truth, not us. Merchants can audit our public key and verification code for transparency. SheerID offers broader coverage through 200,000+ data sources but requires collecting excessive user data. We offer cryptographic certainty with zero data collection. Initial adoption requires pilots with privacy-conscious brands.

Reference links for performance Benchmarks