Skip to main content

Zero-Knowledge Architecture

How SVA preserves user privacy through zero-knowledge encryption.

What is Zero-Knowledge?​

Zero-knowledge means that the service provider (SVA) cannot see or access user data in plaintext. All user data is encrypted client-side before being stored, and only the user (with their master key) can decrypt it.

Encryption Model​

Data Storage​

User Data → Encrypt (Client-Side) → Encrypted Data → Store in SVA Core

User data is encrypted in the browser before being sent to SVA Core:

  1. User enters data (e.g., email, name, phone)
  2. Browser encrypts data using session key
  3. Encrypted data is sent to SVA Core
  4. SVA Core stores encrypted data (cannot read it)

Data Retrieval​

Encrypted Data → Fetch from SVA Core → Decrypt (Client-Side) → Plaintext Data

User data is decrypted only in the user's browser:

  1. Browser fetches encrypted data from SVA Core
  2. Browser decrypts data using session key
  3. Plaintext data is available only in browser
  4. SVA Core never sees plaintext data

OAuth Flow with Zero-Knowledge​

When a third-party app requests user data:

  1. User clicks "Sign In with SVA"
  2. SVA OAuth creates authorization request
  3. User is redirected to consent screen

At this point: SVA services don't know what data the user has.

On the consent screen:

  1. User unlocks vault (master key or passkey)
  2. Browser decrypts user data from vault
  3. Consent screen displays requested scopes
  4. User reviews what will be shared

At this point: Plaintext data exists only in the browser.

Step 3: Data Attestation​

When user approves:

  1. Browser builds claims object from decrypted data: 
    {
      email: decryptedData.email,
      name: decryptedData.name,
      phone: decryptedData.phone
    }
  2. Browser sends claims to SVA Core for attestation
  3. SVA Core validates and signs data token
  4. SVA Core never stores plaintext claims

At this point: SVA Core sees claims only during attestation, but doesn't store them.

Step 4: Token Exchange​

  1. Third-party app exchanges code for tokens
  2. Data token (with claims) is included in response
  3. Third-party app can decode claims from token

At this point: Only the third-party app and user have access to plaintext data.

What SVA Services See​

SVA OAuth Provider​

  • OAuth app registrations
  • Authorization requests
  • Authorization codes
  • Access tokens
  • Cannot see: User data in plaintext

SVA Core​

  • User accounts
  • Encrypted vault data
  • Data token signatures
  • Cannot see: User data in plaintext (only during attestation)

SVA Client​

  • Consent UI
  • Decrypted data (only in browser, never sent to server)
  • Cannot see: User data on server (only in browser)

Data Token Privacy​

Data tokens contain user claims, but:

  1. Short-lived: Expire in 5 minutes
  2. Single-use: Linked to specific authorization request
  3. Audience-bound: Only valid for specific client
  4. User-controlled: Only includes approved scopes

Master Key​

The master key is the encryption key for user data:

  • Never sent to server: Stored only client-side
  • Derived from password: Using key derivation function
  • Required for decryption: Cannot decrypt without it
  • User responsibility: Lost master key = lost data

Passkey Support​

Users can use passkeys instead of passwords:

  • WebAuthn standard: Secure authentication
  • No password required: More secure and convenient
  • Same encryption: Data still encrypted with master key

Benefits​

Privacy​

  • User data remains private
  • Provider cannot read user data
  • Only user can decrypt their data

Security​

  • Encrypted at rest
  • Encrypted in transit
  • No plaintext storage

User Control​

  • Users control what data to share
  • Granular scope approval
  • Can revoke access anytime

Limitations​

Data Recovery​

  • If master key is lost, data cannot be recovered
  • No password reset for encrypted data
  • User must remember master key

Performance​

  • Encryption/decryption happens client-side
  • Slightly slower than plaintext storage
  • Acceptable trade-off for privacy

Comparison with Traditional OAuth​

Traditional OAuth​

User Data → Store Plaintext → OAuth Provider → /userinfo → Third-Party App
  • Provider sees all user data
  • Provider can read/modify data
  • Privacy depends on provider

SVA OAuth (Zero-Knowledge)​

User Data → Encrypt → Store Encrypted → Decrypt (Client) → Attest → Third-Party App
  • Provider never sees plaintext
  • Provider cannot read data
  • Privacy by design

Best Practices​

  1. Never send master key to server - Keep it client-side only
  2. Use strong passwords - For master key derivation
  3. Enable passkeys - More secure than passwords
  4. Backup master key - Store securely (user's responsibility)
  5. Educate users - About zero-knowledge and master key importance

Next Steps​