The Problem

Every time you claim a student discount, you upload your driver’s license to a third-party platform like SheerID. For a $5 Spotify discount, you hand over your full name, birthdate, address, and a photo, stored indefinitely on a server you don’t control.

The real issue: the merchant only needs to know one boolean fact, are you a student?, but existing verification systems are designed to collect and transmit entire identity documents. The verification event becomes a data collection event.

The Solution

ZeroVerify uses zero-knowledge proofs to let you cryptographically prove a claim (“I am an enrolled student”, “I am over 21”) without disclosing any underlying personal data. The merchant learns only the boolean result. Your name, birthdate, university, none of it leaves your device.

How It Works

The system operates in two phases:

Issuance: You authenticate with your university’s existing OAuth/OIDC identity provider (via Keycloak acting as a SAML broker). ZeroVerify’s issuance service extracts your verified attributes and produces a Baby Jubjub EdDSA signed W3C Verifiable Credential, delivered directly to your browser wallet. The raw credential is stored encrypted in IndexedDB and never sent anywhere after this point.

Verification: A merchant redirects you to ZeroVerify with a challenge nonce and a requested proof type. Your wallet uses the locally-stored credential as a private witness to a zk-SNARK circuit. The circuit produces a cryptographic proof that the claim is true, without encoding any attribute value in the output. The proof goes to the merchant’s callback URL. The merchant validates it using ZeroVerify’s open-source verification library, checks revocation status against a W3C Bitstring Status List hosted on S3, and gets a single result: valid or invalid. No personal data is transmitted at any point.

Architecture

System architecture diagram showing the full ZeroVerify data flow

The backend is a set of AWS Lambda functions (Go) behind API Gateway:

  • Issuance Lambda: Exchanges OAuth authorization codes for OIDC claims, computes a pseudonymous subject identifier via HMAC-SHA256 (raw identity never persisted), signs a W3C Verifiable Credential with Baby Jubjub EdDSA, and writes metadata to DynamoDB
  • Revocation Processor: Validates zk-SNARK proofs of credential ownership and marks credentials as revoked in DynamoDB
  • Free Lambda: Handles bit reclamation on both explicit revocation (DDB Streams) and automatic expiry (DDB TTL)
  • Bitstring Updater: Consumes DynamoDB Stream events and synchronizes the W3C Bitstring Status List in S3, using ETag-based conditional writes to handle concurrent Lambda invocations

The browser wallet runs entirely in TypeScript/React. Proof generation uses snarkjs compiled to WebAssembly, so no credential data touches the network during this step. The Circom circuits prove boolean claims (student status, age over 21) against the signed credential without encoding any attribute in the proof output.

Interesting Technical Bits

Replay protection without server-side state: Each proof is bound to a verifier-provided challenge nonce embedded in the circuit’s public inputs. The verifier tracks consumed nonces on their side. ZeroVerify’s infrastructure doesn’t need to track verification sessions.

Revocation without revealing what you’re checking: OCSP requires querying a server with your credential ID, leaking which credential is being verified. W3C Bitstring Status Lists let merchants download a compact bit array (~1.25KB for 10,000 credentials), check the bit at their credential’s index locally, and reveal nothing about which credential they verified.

Privacy-preserving duplicate prevention: To prevent users from holding multiple active credentials from the same institution, the issuance service stores only HMAC-SHA256(issuer_id || subject_id), a one-way pseudonymous identifier. Raw identity attributes are never persisted anywhere in the system.

Client-side proof generation tradeoff: Generating proofs in the browser (2-5 seconds on mid-range devices) is slower than server-side generation, but server-side would require transmitting the raw credential to the server, defeating the core privacy guarantee.

Built With

This was my senior capstone project at Oakland University. I led and implemented the majority of the system: the issuance Lambda, the cryptographic pipeline (Baby Jubjub EdDSA signing, HMAC-based subject pseudonymization), the full revocation architecture, and the browser wallet. Built as a team of five.