Zero-Knowledge Proofs (BBS+ Selective Disclosure)

The Problem: All-or-Nothing Data Sharing

Traditional identity verification is all-or-nothing:

• Prove you’re over 21? Upload driver’s license → service sees birthdate, name, address, photo, license number
• Prove you’re employed? Share employment letter → employer sees job title, salary, start date, manager name
• Prove you have $100k income? Upload pay stub → bank sees exact salary, employer, SSN, deductions

You can’t prove just the minimum needed. It’s “share everything” or “can’t verify.”

This creates privacy nightmares:

• Data breaches: Service stores your full driver’s license data → breach exposes everything
• Surveillance: Every service knows your exact birthdate, address, income—aggregate that across services, you’re profiled
• Liability: Services storing unnecessary PII face GDPR/CCPA compliance costs and risk

Zero-Knowledge Proofs (ZKPs) solve this: cryptographic techniques that let you prove something is true without revealing the underlying data.

---

What Are Zero-Knowledge Proofs?

A zero-knowledge proof is a cryptographic method where:

1. Prover (you) wants to prove something (e.g., “I’m over 21”)
2. Verifier (service) wants to check it’s true
3. Zero knowledge: Verifier learns only that the statement is true—nothing else (not your birthdate, not your name)

Classic Example: The Cave

Imagine a circular cave with two paths (A and B) that meet at a locked door in the middle. You know the password to unlock the door.

How do you prove you know the password without revealing it?

1. You enter the cave (verifier can’t see which path you took)
2. Verifier shouts: “Come out via path A!”
3. You use the password to go through the door (if needed) and exit via path A
4. Repeat many times—if you always exit via the requested path, verifier knows you have the password
5. Zero knowledge: Verifier never sees the password, only that you can navigate the cave

Real-World ZKP Properties

A valid zero-knowledge proof must be:

• Complete: If the statement is true, an honest prover can convince an honest verifier
• Sound: If the statement is false, no cheating prover can convince the verifier (except with negligible probability)
• Zero-knowledge: Verifier learns nothing except whether the statement is true

---

BBS+ Signatures: ZKPs for Verifiable Credentials

BBS+ (Boneh-Boyen-Shacham signatures) is a cryptographic signature scheme designed for selective disclosure—proving specific claims about a credential without revealing all fields.

How BBS+ Works

1. Issuer creates credential with multiple attributes:

   {
     "name": "Alice",
     "birthdate": "1998-03-15",
     "address": "123 Main St",
     "license_number": "D1234567"
   }

2. Issuer signs with BBS+ (creates signature covering all attributes)

3. Alice stores credential in Affinidi Vault

4. Service requests proof: “Prove you’re over 21”

5. Alice creates zero-knowledge proof:

   • Derives proof from credential: “birthdate indicates age ≥ 21”
   • Proof reveals only that claim—not the actual birthdate
   • Proof includes signature verification (confirms issuer signed this)

6. Service verifies proof:

   • Checks: signature valid? Claim true? Issuer trusted?
   • Learns: “Alice is over 21” ✓
   • Does not learn: birthdate, name, address, license number

What Makes BBS+ Special

vs. Standard Digital Signatures (RSA, ECDSA):

• Standard signatures: sign entire credential → revealing credential reveals all fields
• BBS+: sign individual attributes → can reveal subset, hide rest

vs. Other ZKP Systems (zk-SNARKs, zk-STARKs):

• zk-SNARKs/STARKs: general-purpose ZKPs, require trusted setup or heavy computation
• BBS+: specialized for credentials, no trusted setup, efficient for selective disclosure

Key Advantages:

• ✅ No trusted setup (unlike zk-SNARKs)
• ✅ Small proof size (~300 bytes regardless of credential size)
• ✅ Fast verification (milliseconds)
• ✅ W3C standard (used in Verifiable Credentials spec)
• ✅ Unlinkability (multiple proofs from same credential can’t be correlated)

---

Selective Disclosure in Practice

Example 1: Age Verification

Scenario: Prove you’re over 21 to buy alcohol online.

Traditional approach:

• Upload driver’s license photo
• Service sees: birthdate (1998-03-15), name (Alice), address (123 Main St), license number (D1234567), photo

BBS+ selective disclosure:

• Government issues driver’s license credential with BBS+ signature
• Service requests: “Prove age ≥ 21”
• Alice’s Vault creates proof: age_over_21 = true (derived from birthdate ≥ 2005-07-22)
• Service verifies proof, learns only: “This person is over 21” ✓

What service doesn’t see:

• ❌ Exact birthdate
• ❌ Name
• ❌ Address
• ❌ License number
• ❌ Photo

Result: Privacy preserved, compliance maintained, service can’t be breached for unnecessary PII.

---

Example 2: Income Verification for Loans

Scenario: Prove income > $100k for mortgage approval.

Traditional approach:

• Upload pay stubs (last 3 months)
• Bank sees: exact salary ($120k), employer name, SSN, deductions, YTD earnings

BBS+ selective disclosure:

• Employer issues income credential with BBS+ signature: { "employee": "Alice", "salary": 120000, "employer": "Company X" }
• Bank requests: “Prove income > $100k”
• Alice’s Vault creates proof: income_greater_than_100k = true (derived from salary field)
• Bank verifies proof, learns only: “Income exceeds $100k” ✓

What bank doesn’t see:

• ❌ Exact salary ($120k)
• ❌ Employer name
• ❌ Start date
• ❌ Job title

Result: Loan underwriting proceeds, Alice’s exact salary stays private, bank stores less PII (reduced GDPR liability).

---

Example 3: Employment Verification

Scenario: Prove you worked as “Engineer” without revealing salary or performance rating.

Traditional approach:

• Former employer provides reference letter
• New employer sees: job title, salary, performance rating, reason for leaving

BBS+ selective disclosure:

• Former employer issues employment credential: { "employee": "Alice", "title": "Senior Engineer", "salary": 120000, "rating": 4.5, "start": "2020-01-15", "end": "2024-06-30" }
• New employer requests: “Prove you worked as Engineer”
• Alice’s Vault creates proof: title = "Senior Engineer" AND employment_dates = "2020-01-15 to 2024-06-30"
• New employer verifies proof, learns only: title + dates ✓

What new employer doesn’t see:

• ❌ Salary
• ❌ Performance rating
• ❌ Reason for leaving

Result: Employment verified, Alice controls what’s shared, previous employer’s sensitive data stays private.

---

Technical Deep-Dive: How BBS+ Selective Disclosure Works

Step 1: Credential Issuance

Issuer (e.g., government, employer) creates credential with n attributes:

Attributes = { a₁, a₂, a₃, ..., aₙ }

Issuer generates BBS+ signature:

σ = Sign(sk, {a₁, a₂, a₃, ..., aₙ})

Where:

• sk = issuer’s private key
• σ = BBS+ signature (covers all attributes)

Credential = { Attributes, σ, Issuer_DID }

Step 2: Storage

User stores credential in Affinidi Vault (device secure enclave).

Step 3: Selective Disclosure (Proof Generation)

Verifier requests proof of specific claim: “Prove attribute a₃ satisfies condition C”

User’s Vault generates zero-knowledge proof:

π = Prove(σ, {a₃}, Condition_C)

Where:

• π = zero-knowledge proof
• Proof includes:
  • Revealed attributes: a₃ (only if verifier needs exact value)
  • Hidden attributes: a₁, a₂, a₄, ..., aₙ (remain secret)
  • Proof of signature validity (confirms issuer signed this)
  • Proof of condition: C(a₃) = true

Key property: Proof π reveals nothing about hidden attributes (even their existence or count).

Step 4: Verification

Verifier receives proof π and checks:

1. Signature valid? Does proof derive from valid BBS+ signature by trusted issuer?
2. Condition satisfied? Does revealed data satisfy requested condition?
3. Not tampered? Cryptographic integrity check

If all checks pass: Claim verified ✓

Verifier learns:

• ✅ Claim is true (e.g., “age > 21”)
• ✅ Issued by trusted authority
• ❌ Nothing about hidden attributes

---

Unlinkability: Privacy Against Tracking

Problem: Even with selective disclosure, can services track you across verifications?

Example: You prove “over 21” to Service A and Service B. Can they correlate those two proofs and know it’s the same person?

BBS+ provides unlinkability:

• Each proof includes random blinding factors
• Two proofs from the same credential look completely different
• Services cannot correlate proofs to track users

Result: You can prove the same claim to multiple services without them knowing it’s you.

Caveat: If you reveal identifying attributes (e.g., name), services can obviously correlate. Unlinkability protects against cryptographic correlation—services can’t link proofs based on signature structure alone.

---

BBS+ vs. Other ZKP Systems

	BBS+ (Selective Disclosure)	zk-SNARKs	zk-STARKs
Use case	Verifiable credentials	General computation	General computation
Trusted setup	❌ No	✅ Yes (per circuit)	❌ No
Proof size	~300 bytes	~200 bytes	~50-100 KB
Prover time	Fast (ms)	Slow (seconds)	Medium (seconds)
Verifier time	Fast (ms)	Fast (ms)	Medium (ms)
Post-quantum	❌ No	❌ No	✅ Yes
Standards	W3C VC spec	Research stage	Research stage

When to use BBS+:

• Verifiable credentials with selective disclosure
• Need production-ready, standardized solution
• Want fast proof generation/verification
• Don’t want trusted setup

When to use zk-SNARKs/STARKs:

• General-purpose computation verification (e.g., “I ran this program and got this output”)
• Need smallest proof size (zk-SNARKs)
• Need post-quantum security (zk-STARKs)

Affinidi uses BBS+ because:

• W3C Verifiable Credentials standard
• No trusted setup (any issuer can sign)
• Fast enough for real-time flows (login, verification)
• Small proofs work on mobile devices

---

Limitations and Trade-offs

1. Verifier Must Trust Issuer

ZKPs prove “credential claims X” without revealing X’s value—but verifier must trust the issuer:

• If government issues age credential → banks trust it
• If random website issues age credential → banks don’t trust it

Solution: Trust Registries (TRQP) validate issuer authority in real-time.

2. Predicate Proofs Are Limited

BBS+ supports predicates (conditions):

• ✅ Age ≥ 21 (comparison)
• ✅ Income > $100k (comparison)
• ✅ Title = “Engineer” (equality)
• ✅ Date range checks (start date ≤ X ≤ end date)

Cannot prove:

• ❌ Complex computation (“average of last 3 salaries > $90k”)
• ❌ Cross-credential proofs (“my income from Credential A + assets from Credential B > $500k”)

For complex proofs, need zk-SNARKs or application-level logic.

3. Not Post-Quantum Secure

BBS+ relies on elliptic curve pairings (like most current crypto)—vulnerable to quantum computers.

Post-quantum BBS+ variants are in research (lattice-based signatures).

Current mitigation:

• Quantum computers capable of breaking ECC are 10-15 years away
• Credential lifetimes are short (months to years)
• When post-quantum threat is imminent, rotate to new signature schemes

4. Verifier Learns What You Choose to Prove

ZKPs reveal the claim you’re proving:

• Prove “age > 21” → verifier learns you proved age (not exact birthdate, but knows age is relevant)
• Prove “employed as Engineer” → verifier learns your job title (even though salary stays hidden)

Not zero-knowledge about the fact you’re proving something.

For true privacy: don’t prove claims that reveal too much context.

---

BBS+ in Affinidi’s Stack

Where BBS+ is used:

1. Elements Services issues credentials with BBS+ signatures
2. Affinidi Vault generates BBS+ proofs (selective disclosure)
3. Verifiers (applications, services) verify proofs via OpenID4VP

Example flow (Passwordless login with selective disclosure):

[User Alice logs into Service]
  ↓
Service requests: "Prove you're an employee of Company X"
  ↓
Alice's Vault:
  - Has employment credential (name, title, salary, start date)
  - Generates BBS+ proof: "employed at Company X, title = Engineer"
  - Hides: salary, exact start date, performance rating
  ↓
Service verifies proof:
  ✓ Signature valid (Company X issued this)
  ✓ Claim true (Alice is employee)
  ↓
Alice logged in—service never saw salary or full credential

Result: Passwordless authentication + privacy-preserving verification.

---

Real-World Deployments

BBS+ is not theoretical—it’s production-ready:

• ✅ W3C Verifiable Credentials spec includes BBS+ as recommended signature suite
• ✅ EU Digital Identity Wallet architecture uses selective disclosure (BBS+ or equivalent)
• ✅ Affinidi Elements Services issues BBS+-signed credentials today
• ✅ Multiple governments (Canada, New Zealand, Singapore) piloting BBS+ for digital identity

Proof size: ~300 bytes (fits in QR code, NFC tag, URL parameter)

Speed: Proof generation ~10ms, verification ~5ms (fast enough for real-time flows)

Compatibility: Works on all platforms (iOS, Android, Web, embedded devices)

---

Get Started with BBS+ Selective Disclosure

Build your first selective disclosure flow:

1. Issue a credential with multiple attributes (age, name, address)
2. Store in Affinidi Vault (user-owned wallet)
3. Request selective disclosure (“prove age > 21”)
4. Verify proof (check signature + condition)

Start building →

Documentation:

• W3C BBS+ Signature Suite
• Affinidi Elements Services (BBS+ issuance)
• Affinidi Vault (proof generation)

---

Related Resources

Technical Deep Dives

• Verifiable Credentials - How cryptographically signed credentials work
• Verifiable Presentations - How credentials are shared with selective disclosure

Related Solutions

• Reusable KYC - Uses BBS+ to prove identity without revealing PII
• Passwordless Authentication - Login with selective disclosure
• Employment Verification - Prove work history without revealing salary

---

Summary

Zero-knowledge proofs (ZKPs) let you prove something is true without revealing the underlying data.

BBS+ signatures enable selective disclosure for verifiable credentials:

• Prove “age > 21” without revealing birthdate
• Prove “income > $100k” without revealing exact salary
• Prove “employed as Engineer” without revealing salary or performance rating

Key properties:

• ✅ No trusted setup
• ✅ Fast (milliseconds)
• ✅ Small proofs (~300 bytes)
• ✅ Unlinkable (can’t track across verifications)
• ✅ W3C standard (production-ready)

Trade-offs:

• ⚠ Limited to predicate proofs (comparisons, equality)
• ⚠ Not post-quantum secure (yet)
• ⚠ Verifier must trust issuer (solved via Trust Registries)

Where Affinidi uses BBS+:

• Elements Services (credential issuance)
• Affinidi Vault (proof generation)
• OpenID4VP flows (selective disclosure during login/verification)

Result: Privacy-preserving identity verification—share only what’s needed, nothing more.