Product Requirement Document (PRD)

Date: 2/22/26 | Team: Lisa Nguyen (CS), Anton Sakhanovyvh (CS), Souleymane Sono (CS), Fateha Ima (CS), Simon Griemert (CS)

Executive Summary

The Hook

Over 17 billion personal records were compromised in 2023 alone (Flashpoint 2024 Global Threat Intelligence Report). The dominant identity verification protocols in use today, SAML, OAuth, OpenID Connect, are designed to transmit full identity attribute sets rather than selective proofs of individual claims. An organization verifying student status receives a name, institutional affiliation, date of birth, and email address because that is what the protocol delivers. There is no native mechanism for a verifier to request only what a transaction requires and receive only that. When systems built on these protocols are breached, the exposed records reflect everything the protocol required them to collect. ZeroVerify attacks the collection requirement itself.

The Problem

Current digital identity verification operates on a structural mismatch between what verifiers need and what protocols deliver. To confirm a single boolean claim (“Is this a person a student?“), SAML, OAuth, OIDC return a full attribute assertion containing every identity field the institution has on record. Once the transmission occurs, the user has no mechanism to limit how the data is used, how long it is retained, or whether it is deleted at all. No existing system integrates zero-knowledge proofs into standard OAuth 2.0 and OIDC flows such that a verifier can confirm a claim about a user’s identity without receiving any personal attributes at all, and without requiring organizations to replace their existing identity infrastructure.

The Solution

ZeroVerify is a privacy-preserving identity verification layer that integrates with the identity infrastructure universities and enterprises already operate. It addresses the structural problem of attribute over-disclosure not by minimizing what is shared, but by eliminating attribute disclosure entirely from the verification event.

The system works in two phases. In the issuance phase, ZeroVerify federates with an institution’s existing IdP via Keycloak acting as an identity broker. The institution requires no modification; from its perspective, Keycloak is a standard service provider. ZeroVerify’s issuance layer extracts the verified attributes from the claims set and produces a BBS+ signed verifiable credential, which is delivered to and stored in the user’s mobile wallet. The raw credential never leaves the device after this point.

In the verification phase, a verifier issues a challenge requesting confirmation of a specific boolean claim, for example “Is this person over 21?” or “Is this person an active student?” The user’s wallet uses the stored credential as a private witness to a zk-SNARK circuit specific to that claim type. The circuit produces a cryptographic proof that the claim is true without encoding any attribute value in the proof output. The verifier submits this proof to ZeroVerify’s library, which checks cryptographic correctness, confirms the challenge nonce has not been previously consumed (preventing replay attacks), and checks the credential’s revocation status against a W3C Status List bitstring. The verifier receives a single result: valid or invalid. No name, no birthdate, no institutional affiliation, no personal data of any kind is transmitted to the verifier at any point in this flow.

The integration boundary is deliberately placed so that neither the institution nor the verifier needs to understand or adopt zero-knowledge proof systems. The institution speaks SAML, OAuth, OIDC. The verifier calls two SDK functions. ZeroVerify handles the cryptographic complexity in between.

Technical Approach

ZeroVerify is built on four core technologies: BBS+ signatures for credential issuance, Groth-16 zk-SNARKs compiled in circom for circuit definition, Keycloak as a SAML/OAuth-to-OIDC broker, and snarkjs for client-side proof generation. The backend runs on AWS Lambda and DynamoDB Global Tables across three regions, with W3C Status List revocation state stored in S3.

The technical challenge is composing zk-SNARKs and BBS+ signatures into a system that speaks the protocols universities and enterprises already operate, SAML, OAuth, OIDC, without requiring those institutions to change anything on their end. Keycloak bridges that gap as SAML/OAuth-to-OIDC broker, normalizing heterogeneous institutional identity systems into a consistent claims surface that ZeroVerify’s issuance layer can sign into verifiable credentials. The second hard problem is that proof generation must run entirely on the user’s mobile device, because sending the raw credential to a server for proof generation would defeat the privacy guarantee. This requires compiling a Groth-16 zk-SNARK prover to WebAssembly and executing it client-side within the constraints of mobile hardware.

Impact

ZeroVerify has implications across three dimensions. Economically, it targets markets where identity over-disclosure is endemic: the student discount market (\$19.3B by 2033) and age verification market (\$1.2B by 2028), where users currently surrender full identity documents to prove a single attribute. Legally, GDPR and CCPA both mandate data minimization; ZeroVerify satisfies that requirement at the protocol level rather than through organizational policy. The EU’s May 2024 digital identity regulation explicitly requires zero-knowledge proofs, which independently validates the technical approach. Socially, users stop surrendering identity documents for routing verifications. The credential stays on the device. The verifier learns one bit: valid or invalid.

Product Definition

ZeroVerify is a privacy-centered verification platform that lets users confirm eligibility claims, like student status or age requirements, without exposing unnecessary personal information. The system is designed to reduce identity data exposure while still providing secure and reliable verification for online services.

ZeroVerify integrates with trusted Identity Providers (IdPs or Keycloak) through standard authentication protocols. After a user signs in, the platform receives verified information needed to issue a credential, then issues and signs that credential and delivers it to the user for local storage.

When a verifier requests verification, the request maps to a specific proof type, which corresponds to a specific circuit that ZeroVerify supports. The circuit determines exactly what becomes public versus private in the proof, meaning the user is not choosing arbitrary attributes to reveal. Instead, the user reviews the requested proof type (circuit) and either approves or denies generating that proof. The verifier receives a simple Accepted/Rejected result and does not gain access to the user’s full identity data.

Overall, ZeroVerify focuses on data minimization, user consent at the proof-type level (circuits), and compatibility with existing identity systems.

Target Audience (Primary users + pain points)

Primary: Verifiers (merchants, websites, service providers) who need to confirm a single eligibility claim (ex: student status, over-21) but do not want to collect or store personal identity data.

Pain points:

Secondary: End users (students/individuals) who want to prove eligibility without oversharing personal details.

Pain points:

Supporting: Institutions/IdPs (universities/enterprises) that already run identity infrastructure and prefer solutions that do not require major changes.

Pain points:

User Goals (What they are trying to achieve)

Verifier goals:

End user goals:

Institution/IdP goals:

Minimum Viable Product (MVP)

For the initial launch/demo, ZeroVerify will support one end-to-end verification flow with at least one proof type (e.g., student status).

Core requirements and features:

Functional Requirements

User Requirements

Credential Issuance (User + IdP)

Verifier Request Proof (Website/Store)

User Generates ZK Proof

Proof Verification (Verifier)

Security and Access Control

Functional Logic

A logical blueprint for how the system responds to user inputs.

Digital Credential Issuance

Attribute Proof Request

User Consent & ZK proof

Proof Verification

Non-Functional Requirements

Privacy

Performance

Scalability

Usability

Reliability

Interoperability

Maintainability

UI/UX & Design Strategy

How the user interacts with the logic

ZeroVerify’s UI is designed around a simple “start → login → consent → result” flow. The user should always understand (1) what they are proving, (2) what is being shared (yes/no), and (3) when the action is complete. The UI emphasizes privacy and consent so users never feel like verification is happening “in the background.”

Conceptual Model (the mental map we want users to have)

We want users to think of ZeroVerify like a digital yes/no stamp, not an identity-sharing process:

  1. Get credential (login once with your institution through Keycloak/IdP)

  2. Review request (a verifier asks for a specific proof type like “student status”)

  3. Approve/Deny (user controls whether the proof is generated)

  4. Result (verifier receives Accepted/Rejected; user sees confirmation)

Key message shown in the UI:

Style goals: simple, professional, low-stress, privacy-first.

Reusable components (used across screens):

Feedback Mechanisms (instant signals)

Users should always get immediate feedback that something is happening:

Error Handling (minimize confusion and mistakes)

We reduce user mistakes by making the next action obvious and preventing “oops” clicks:

Example error messages (plain language):

Prevent slips:

Technical Constraints & Data

Ensuring the project is technically feasible.

Data Models

Define clear relationships (1:N, N:N) and primary keys.

Credential Table Schema:

AttributeTypeRole
subjectStringPartition key
credential_idString (UUID)Sort key
issue_dateString (ISO 8601)Attribute
expiry_dateString (ISO 8601)Attribute
revocation_indexNumberAttribute
statusString (ACTIVE or REVOKED)Attribute

The relationship between a pseudonymous user identity and their credentials is 1:N. One partition key groups all credential records ever issued to that user under that IdP. Each individual credential is uniquely identified by cred_id as the sort key, meaning new issuance after revocation or expiry produces a new record rather than overwriting the old one.

The Issuance Lambda never touches the bitstring. It only queries the Credential table: if any record exists under the partition key with status = ACTIVE and expiry_date > now, the request is rejected, since the user can only have one active credential from a given IdP. Otherwise a new record is written with a freshly generated cred_id.

System Architecture

ZeroVerify’s architecture is split into two completely independent paths: issuance and verification. The backend is only involved in issuance. Verification happens entirely between the user’s browser and the verifier, with ZeroVerify’s backend never seeing what is being proved or to whom.

Issuance Path

The user navigates to ZeroVerify’s React web app and initiates credential issuance. The app redirects to Keycloak, which federates with the user’s institutional Shibboleth IdP via SAML. From the user’s perspective this is a standard OAuth login flow. Once authenticated, Keycloak returns an authorization code to the React app. The app passes this code to the Issuance Lambda via API Gateway. The Lambda exchanges the code with Keycloak for a normalized OIDC claims set, computes HMAC(issuer_id || sub_id) using a key from AWS Secrets Manager, queries DynamoDB to check whether an active unexpired credential already exists for that pseudonymous identifier, and if not, signs a BBS+ verifiable credential to the React app. The credential is stored in the browser’s IndexedDB and never transmitted to any server again.

Verification Path

The verifier generates a URL containing the proof type, their callback endpoint, and a nonce they generated themselves. The user opens this URL in their browser, landing on ZeroVerify’s React web app. The app loads the credential from IndexedDB, checks whether a valid active credential exists for the requested proof type, and presents a consent screen showing exactly what is being requested and by whom. If the user consents, the app generates a Groth16 zk-SNARK proof client-side using snarkjs. The proof is posted directly to the verifier’s callback endpoint. ZeroVerify’s backend is not involved at any point in the verification path.

The verifier independently downloads ZeroVerify’s W3C Revocation Bit String to check credentials revocation status. Both the verification key and the bitstring are public artifacts served statically. The verifier needs no API integration with ZeroVerify beyond these two static resources.

Revocation Path

Revocation requests are submitted to the SQS Queue via API Gateway. Those requests are processed in batches by the Revocation Lambda. The Lambda updates the credential record’s status to REVOKED in DynamoDB. Lambda downloads the bitstring from the S3 and updates the values and uploads it back.

Component interaction

The React app talks to API Gateway over HTTPS for issuance and revocation only. It talks directly to the verifier’s callback endpoint for proof submission.

Integration Strategy

Identity Providers (via Keycloak)

ZeroVerify integrates with institutional identity providers through Keycloak as the federation layer. Keycloak handles all SAML complexity internally. From ZeroVerify’s perspective, every IdP looks identical: a standard OIDC claims set returned after an authorization code exchange. Adding a new institution requires only configuring a new IdP in Keycloak’s realm.

Verifier Callback Endpoint

The React app receives the verifier’s callback URL as a query parameter in the verification link and posts the generated proof directly to it over HTTPS. ZeroVerify imposes no requirements on the verifier’s backend beyond accepting an HTTP POST with the proof payload.

Success Metrics & Validation

Functional Requirements

Digital Credential Issuance

Success Metrics:

Validation Method:

Attribute Proof Request

Success Metrics:

Validation Method:

User Review, Consent, ZK Proof Generation

Success Metrics:

Validation Method:

Proof Verification & Revocation Check

Success Metrics:

Validation Method:

Security & Access Control

Success Metrics:

Validation Method:

Non-functional Requirements

Security

Success Metrics:

Validation Method:

Privacy

Success Metrics:

Validation Method:

Performance

Success Metrics:

Validation Method:

Scalability

Success Metrics:

Validation Method:

Usability

Success Metrics:

Validation Method:

Reliability

Success Metrics:

Validation Method:

Interoperability

Success Metrics:

Validation Method:

Maintainability

Success Metrics:

Validation Method: