Zero-Knowledge Infrastructure | Technical Deep-Dive

What It Is

Zero-Knowledge Proofs (ZKPs) allow one party (prover) to convince another party (verifier) that a statement is true, without revealing any information beyond the truth of the statement itself. In identity systems, this means proving attributes (age, income, citizenship) without exposing the underlying data.

                Example: Prove "I am over 18" without revealing your birthdate. The verifier learns only 
                that the statement is true—not your age, birthdate, or any other detail. The cryptographic proof is mathematically 
                sound: forging it is computationally infeasible.
            

ZK infrastructure is the next evolution of privacy-preserving identity. While selective disclosure (SD-JWT) lets you share some attributes, ZKPs let you prove properties of attributes without sharing the attributes at all. This is critical for use cases where even partial data disclosure is too risky.

Zero-Knowledge Fundamentals

The Three Properties

Property	Definition	Meaning
Completeness	If statement is true, honest verifier will be convinced	Valid proofs always succeed
Soundness	If statement is false, no cheating prover can convince verifier	Faking proofs is computationally infeasible
Zero-Knowledge	Verifier learns nothing beyond the truth of the statement	No data leakage—only the boolean result (true/false)

ZKP Types

Type	Properties	Use Case
ZK-SNARKs (Succinct Non-interactive ARguments of Knowledge)	Very small proofs (~200 bytes), fast verification, requires trusted setup	Blockchain (Zcash), verifiable computation
ZK-STARKs (Scalable Transparent ARguments of Knowledge)	No trusted setup, larger proofs (~100 KB), quantum-resistant	Post-quantum privacy, transparent systems
Bulletproofs	Short proofs (~1 KB), no trusted setup, slower verification	Range proofs (e.g., income between X-Y)
BBS+ Signatures	Efficient selective disclosure + ZKP over credentials	Identity credentials (W3C VC with ZKP support)

Identity-Focused ZK Protocols

BBS+ Signatures for Verifiable Credentials

BBS+ (Boneh-Boyen-Shacham) is a signature scheme designed for selective disclosure and zero-knowledge proofs. It allows a credential issuer to sign multiple attributes, and the holder can later prove statements about those attributes without revealing them.

# Example: Age verification with BBS+

1. Issuer (Government) issues credential:
   {
     "name": "John Doe",
     "birthdate": "1990-05-15",
     "nationality": "Finnish"
   }
   - Signs with BBS+ (creates signature over all attributes)

2. Holder creates ZK proof:
   Statement: "birthdate indicates age >= 18"
   - Does NOT reveal birthdate
   - Verifier receives only: proof + boolean result (true)

3. Verifier checks:
   - Proof signature valid (issuer's public key)
   - Statement satisfied (age >= 18)
   - Learns NOTHING about birthdate, name, or nationality
            

Anonymous Credentials (Idemix, U-Prove)

Protocol	Developer	Features
Idemix	IBM	Anonymous authentication, unlinkable presentations, revocation support
U-Prove	Microsoft	Minimal disclosure, no issuer tracking, efficient mobile implementation
BBS+ (W3C)	MATTR, others	Open standard, VC integration, selective disclosure + ZKP

Range Proofs (Bulletproofs)

Prove a value lies within a range without revealing the value. Critical for financial and eligibility proofs.

# Example: Income verification for loan

Issuer: Tax office issues credential with income = €75,000

Holder wants to prove: "Income >= €60,000" (loan requirement)

Bulletproof construction:
1. Holder computes proof: P = Prove(income >= 60000)
   - Uses Pedersen commitment (hides actual value)
   - Generates range proof (cryptographic evidence)
2. Verifier checks: Verify(P, commitment, public_key)
   - Confirms: income >= 60000 is TRUE
   - Learns nothing about actual income (could be 60k, 100k, 1M—unknown)

Proof size: ~1 KB (efficient for mobile wallets)
            

Real-World Use Cases

1. Age Verification (Privacy-Preserving)

                Scenario: Online service requires age >= 18 (alcohol sales, adult content).
                
                Traditional: User uploads ID scan → service sees birthdate, name, photo → privacy breach.
                
                With ZKP:
                User's wallet holds government-issued birthdate credential
Service requests: "Prove age >= 18"
Wallet generates ZK proof (BBS+): "birthdate implies age >= 18"
Service verifies proof → grants access
Service learns ONLY: user is 18+ (not birthdate, not identity)

                Benefit: Compliance without surveillance. Service can't build user profiles.

2. Income Threshold for Benefits

                Scenario: Housing allowance requires "annual income < €30,000".
                
                Traditional: Applicant submits tax return → agency sees exact salary → stigma, privacy loss.
                
                With ZKP:
                Tax office issues income credential (signed, but value hidden in commitment)
Applicant generates range proof: "income < 30000"
Agency verifies proof → approves benefit
Agency learns ONLY: applicant qualifies (not exact income)

                Benefit: Dignity-preserving eligibility checks.

3. Citizenship Proof (No Border Data Leak)

                Scenario: Traveler crosses border, customs needs citizenship verification.
                
                Traditional: Passport scan → full identity stored in customs database → potential misuse.
                
                With ZKP:
                Traveler's wallet holds citizenship credential (government-issued)
Border system requests: "Prove EU citizenship"
Wallet generates ZK proof: "nationality ∈ {EU member states}"
System verifies → allows entry
System learns ONLY: traveler is EU citizen (not which country, not identity)

                Benefit: Privacy at scale—no central database of border crossings.

4. Compliance Verification (B2B)

                Scenario: Supplier must prove "revenue > €2M" to qualify for contract.
                
                Traditional: Supplier shares full financial statements → buyer sees sensitive data.
                
                With ZKP:
                Auditor issues revenue credential (certified financials)
Supplier generates ZK proof: "revenue > 2M"
Buyer verifies proof → approves supplier
Buyer learns ONLY: supplier meets threshold (not exact revenue)

                Benefit: Competitive intelligence protected while proving eligibility.

Implementation Architecture

ZK-Enabled Wallet Stack

┌────────────────────────────────────────────────────────────────┐ │ ZK-Enhanced EUDI Wallet │ └────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ User Interface Layer │ │ - Credential viewer │ │ - Proof generation prompts ("Prove age >= 18?") │ └─────────────────┬───────────────────────────────────────────┘ │ ┌─────────────────▼───────────────────────────────────────────┐ │ Credential Storage (Encrypted) │ │ - VCs with BBS+ signatures │ │ - Commitments (hidden values) │ │ - Issuer public keys │ └─────────────────┬───────────────────────────────────────────┘ │ ┌─────────────────▼───────────────────────────────────────────┐ │ ZK Proof Engine │ │ - BBS+ proof generation │ │ - Bulletproof range proofs │ │ - Statement parser ("age >= 18" → circuit) │ └─────────────────┬───────────────────────────────────────────┘ │ ┌─────────────────▼───────────────────────────────────────────┐ │ Cryptographic Libraries │ │ - libsodium (elliptic curve ops) │ │ - zkp-toolkit (proof generation) │ │ - bbs-signatures (W3C spec implementation) │ └─────────────────┬───────────────────────────────────────────┘ │ ▼ [Presentation to Verifier] │ ┌─────────────────▼───────────────────────────────────────────┐ │ Verifier System │ │ - Receives proof (200 bytes - 1 KB) │ │ - Verifies against issuer public key │ │ - Checks statement validity (age >= 18 → TRUE) │ │ - No access to underlying data │ └─────────────────────────────────────────────────────────────┘

Implementation Challenges

Challenge	Current Status	Solution Path
Performance	Proof generation: 1-10 seconds on mobile	Hardware acceleration (ARM TrustZone), optimized circuits
Standardization	BBS+ in W3C draft, no finalized spec	W3C VC working group targeting 2026 recommendation
Revocation	ZK-friendly revocation schemes immature	Accumulators (Merkle trees) for privacy-preserving revocation checks
User Experience	Complex for non-technical users	Abstract complexity: "Prove age without sharing birthdate" (simple prompt)
Issuer Adoption	Most issuers use basic VCs (no ZKP)	Gradual migration: support both standard VCs and ZK-VCs

Code Example: BBS+ Proof Generation

# Pseudo-code: Generate age >= 18 proof

import bbs_signatures as bbs

# 1. Holder's credential (BBS+ signed)
credential = {
    "issuer": "did:web:dvv.fi",
    "credentialSubject": {
        "name": "John Doe",
        "birthdate": "1990-05-15"  # Hidden in commitment
    },
    "proof": {
        "type": "BbsBlsSignature2020",
        "proofValue": "..."  # BBS+ signature over attributes
    }
}

# 2. Verifier requests proof
presentation_request = {
    "statement": "credentialSubject.birthdate indicates age >= 18"
}

# 3. Generate ZK proof
proof = bbs.generate_proof(
    credential=credential,
    statement=presentation_request["statement"],
    disclosed_attributes=[],  # Reveal nothing
    holder_secret=wallet.private_key
)

# 4. Send proof to verifier
presentation = {
    "type": "VerifiablePresentation",
    "verifiableCredential": [{
        "proof": proof  # ZK proof (compact: ~200 bytes)
    }]
}

# 5. Verifier checks
is_valid = bbs.verify_proof(
    proof=proof,
    issuer_public_key="did:web:dvv.fi#key-1",
    statement="age >= 18"
)

# Result: is_valid = True, but verifier learns NOTHING about birthdate
            

Deployment Roadmap

Phase	Timeframe	Milestones
Standards Finalization	2025-2026	W3C BBS+ specification reaches recommendation status
Library Development	2026	Production-ready ZK libraries for mobile (iOS, Android)
Pilot Programs	2027	Age verification, benefit eligibility (limited rollout)
EUDI Wallet Integration	2027-2028	National wallets support ZK proofs (optional feature)
Widespread Adoption	2028+	ZK proofs standard for privacy-sensitive verifications

🔐 Zero-Knowledge Infrastructure