Project Management

Milestone Roadmap

The ZeroVerify project is organized into distinct phases, each building upon the previous to deliver a fully functional privacy-preserving identity verification system.

Phase 1 (Weeks 1-3): Prototype Implementation

Infrastructure + Database Schema + Issuance Skeleton

  • Set up basic infrastructure for end-to-end demo (frontend + backend)
  • Create minimal database schema (credential storage + proof session tracking)
  • Set up Keycloak identity middleware and connect to backend
  • Stand up issuance API skeleton with basic endpoints

Trusted Setup

  • Run trusted setup to generate setup parameters for circuits
  • Deploy verification and proving keys to S3

Credential Issuance Flow

  • Backend generates credential and returns it to web app
  • Credential stored locally in user's browser
  • User clicks "Request Credential" to start issuance
  • Create a mock verifier

Replay Protection

  • Generate unique session challenge per verification attempt
  • Bind challenge to proof (handled as part of circuit)

Proof Generation + User Consent

  • Proof request shown in web app with user approval/denial
  • On approval, generate proof for one proof type (student status or over 21)

Verifier Verification Flow

  • Verify proof using issuer public key + public inputs
  • Return Accepted/Rejected and log basic non-PII debug info

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

Goal: Done by April 13

Error Handling + Clear Rejection Reasons

  • Invalid: proof doesn't verify
  • Malformed: missing/wrong format
  • Revoked: credential was disabled
  • Expired: session/challenge/credential expired

Revocation Checking

  • Add revocation check during verification
  • Demo case: revoked credential → rejected

UI Polish for Demo Flow

  • Simplify demo screens and prompts
  • Clear "Approve/Deny" consent step
  • Clear "Accepted/Rejected" result screen

Testing Plan + Test Cases

  • Happy path: request → approve → proof generated → verify → accepted
  • Failure cases: replay attempt, malformed input, invalid proof, revoked/expired

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

Deployment/Demo Packaging + Documentation Cleanup

  • Decide demo format: hosted or local run
  • Create simple "how to run" steps
  • Cleanup documentation to match what was built

Final Deliverables Prep

  • Finalize website/video
  • Lock demo script + slide updates

Final Product Demo (Finals Week)

  • Final rehearsal + backup plan
  • Deliver final demo during finals week

Team Structure

The ZeroVerify team consists of five Computer Science students working collaboratively on all aspects of the system:

  • Lisa Nguyen (Computer Science)
  • Anton Sakhanovych (Computer Science)
  • Souleymane Sono (Computer Science)
  • Fateha Ima (Computer Science)
  • Simon Griemert (Computer Science)

Ethics & IRB Considerations

Privacy by Design

ZeroVerify is fundamentally built on privacy-preserving principles. The system is designed to minimize data collection, storage, and transmission at every layer. Unlike traditional identity verification systems that collect and retain full identity documents, ZeroVerify never persists raw personal identity data after credential issuance. The system stores only non-reversible cryptographic derivatives necessary for preventing duplicate credential issuance.

Data Minimization

The core principle of ZeroVerify is data minimization at the protocol level. Users prove specific claims (e.g., "I am a student") without revealing any underlying personal attributes. Verifiers receive only a binary result: valid or invalid. This approach complies with GDPR and CCPA data minimization requirements and aligns with the EU's May 2024 digital identity regulation that explicitly requires zero-knowledge proofs.

User Consent

Every verification attempt requires explicit user consent. Users review the requested proof type and either approve or deny before any proof is generated. The system provides clear information about what is being requested and what will be disclosed (in this case, only a yes/no confirmation of the claim, with no personal data).

Security Considerations

All communications use HTTPS (TLS 1.2+). Server-side data is encrypted using AWS KMS. Credentials are stored locally in the user's browser and never retransmitted. Each proof is bound to a verifier-provided session nonce to prevent replay attacks. The system follows least-privilege principles for IAM roles, and all cryptographic keys are stored securely in AWS Secrets Manager.

Responsible Disclosure

ZeroVerify operates transparently with verifiers able to audit the public verification key and verification code. The system provides cryptographic certainty rather than relying on reputation. This transparency allows external security researchers and users to verify the system's privacy guarantees independently.