Privacy by Design - 7 Foundational Principles Assessment

How Maelstrom AI embodies Privacy by Design principles in age verification

Public

Privacy by Design Assessment

Executive Summary

Maelstrom AI implements Privacy by Design principles throughout the Provii platform’s architecture. The platform’s zero knowledge verification architecture is designed so that during age checks, no date of birth is transmitted, only a cryptographic proof. During credential issuance, DOB is processed ephemerally and immediately discarded, providing strong privacy protection through a trust-based design.

Overall Privacy by Design Score

Assessment CategoryScore
Principles Achieving EXEMPLARY Status5 out of 7
Principles Fully Implemented7 out of 7
Principles Partially Implemented0 out of 7
Principles Not Met0 out of 7

Overall Rating: EXEMPLARY - Maelstrom AI demonstrates thorough implementation of Privacy by Design across all seven foundational principles.

Key Privacy by Design Attributes

  1. Architectural Privacy Design - DOB processed ephemerally during issuance and not persisted; verification is designed to reveal no PII
  2. Zero knowledge Proofs - Mathematical proof of age without revealing date of birth
  3. Radical Transparency - Open source code, published ISMS, public documentation
  4. User Control - Wallet-based credentials, no central database of user data
  5. Privacy as Business Model - Revenue model requires no user tracking or data monetisation

Introduction

About Privacy by Design

Privacy by Design (PbD) is a framework developed by Dr. Ann Cavoukian, former Information and Privacy Commissioner of Ontario. Formally recognised in the 2010 OECD Privacy Guidelines and embedded in GDPR Article 25, PbD establishes seven foundational principles for embedding privacy into technology design.

The 7 Foundational Principles:

  1. Proactive not Reactive; Preventative not Remedial
  2. Privacy as the Default Setting
  3. Privacy Embedded into Design
  4. Full Functionality - Positive-Sum, not Zero-Sum
  5. End-to-End Security - Full Lifecycle Protection
  6. Visibility and Transparency - Keep it Open
  7. Respect for User Privacy - Keep it User-Centric

Why This Matters for Provii

Traditional age verification creates a fundamental privacy dilemma: verify identity (invasive) or trust self-declaration (ineffective). Provii resolves this through zero knowledge cryptography, proving age eligibility without revealing personal information.

Privacy by Design informs the architecture from first principles, rather than being retrofitted:

  • Regulatory Alignment. Architecture designed to meet GDPR Article 25 (Privacy by Design) requirements
  • Privacy Differentiation. Privacy-preserving age verification at scale
  • User Trust. Cryptographic protections, not policy promises
  • Operational Simplification. No persisted PII = reduced data breach liability, simpler compliance
  • Privacy-First Design. Architecture developed with privacy as a core objective

Principle-by-Principle Assessment

Principle 1: Proactive not Reactive; Preventative not Remedial

Definition: Anticipate and prevent privacy-invasive events before they happen. Don’t wait for privacy risks to materialize; prevent them from occurring in the first place.

Implementation

Zero knowledge Architecture - Privacy by Design

Maelstrom AI minimises PII exposure through a trust-based issuance model with ephemeral processing and zero knowledge verification:

  • Date of Birth (DOB). During credential issuance, transmitted once to the issuer API for Pedersen commitment computation, processed ephemerally and immediately discarded. never stored, logged, or retained. During verification, not transmitted at all.
  • Identity Documents. Never collected, scanned, or stored
  • Biometric Data. Never captured or processed
  • Traditional PII. Names, addresses, contact information - architecturally excluded

Proactive Design Decisions:

  1. Groth16 Zero knowledge Proofs: By design, proofs reveal only the age threshold result (over/under) and nothing more
  2. Ephemeral Server-Side Processing: DOB transmitted once during issuance for Pedersen commitment computation, then immediately discarded. never stored, logged, or retained
  3. Trust-Based Credential Issuance: Issuer computes Pedersen commitment from DOB and blinding randomness (r_bits), signs the credential, and discards the DOB
  4. Unlinkability by Design: Random challenge IDs prevent cross-site tracking

Evidence

Architecture Documentation:

  • /trust/overview/architecture.mdx - Zero knowledge architecture specification
  • /trust/security/information-security-policy.mdx (Lines 102-109) - “Zero knowledge First” principle

Code Evidence:

  • provii-crypto/crypto-circuit-age/src/lib.rs - Age verification circuit proves DOB >= cutoff_days without revealing DOB
  • provii-crypto/crypto-commit/src/lib.rs:24-45 - Pedersen commitment hides DOB with cryptographic randomness

Quote from Information Security Policy:

“If we don’t collect it, we can’t lose it. Maelstrom AI-operated services never persist to at-rest storage: names, addresses, contact information, dates of birth or identity document data, biometric information, or any other personally identifiable information (PII). During credential issuance, the date of birth is transmitted once to the issuer API for Pedersen commitment computation, processed ephemerally, and immediately discarded.”

Score: ✅ EXEMPLARY

Justification: Maelstrom AI does not merely prevent privacy violations reactively - the architecture is designed so that zero knowledge proofs make extracting PII computationally infeasible under standard cryptographic assumptions. This represents a strong implementation of proactive privacy protection.

Supporting Details:

  • Traditional age verification: Collect PII, then protect it (reactive)
  • Provii approach: Architecturally designed to prevent PII collection (proactive)
  • Zero knowledge proofs are designed so that DOB is not extractable from the proof output
  • No policy enforcement needed - privacy protected by mathematical design

Principle 2: Privacy as the Default Setting

Definition: Privacy protection should be automatic and require no action from users. Maximum privacy should be the default, not an opt-in setting.

Implementation

Privacy is Not Configurable - It’s Mandatory

Unlike systems with privacy “settings,” the Provii platform provides no option to reduce privacy:

  • No PII Toggle. Users cannot accidentally share more information
  • Minimal Disclosure Always. Proofs always reveal only binary threshold (over/under age)
  • Automatic Unlinkability. Each verification uses random challenge ID (cannot be disabled)
  • No User Configuration Required. Privacy is hardcoded into cryptographic protocol

Default Privacy Properties:

  1. Information Revelation: Only binary age threshold (e.g., “18+”), never actual age or DOB
  2. Cross-Site Tracking: Prevented by design - random IDs per verification prevent linkage
  3. Credential Reuse Detection: Nullifiers prevent replay without revealing user identity
  4. IP Address Retention: 90 days maximum (automatic deletion), used only for anti-abuse; critical security event logs are retained for up to 365 days

Evidence

Privacy Architecture Evidence:

  • /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 266-275) - Privacy by Design implementation

Cryptographic Implementation:

  • provii-crypto/crypto-circuit-age/src/lib.rs - Circuit reveals only cutoff_days comparison result
  • Public inputs: cutoff_days (threshold), cred_nullifier (replay prevention), rp_hash (binding) - NO personal data
  • Private inputs: Actual DOB, credential signature, randomness - never revealed

Data Minimization Evidence:

  • /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 37-95)
  • Server collects: IP addresses (90 days), challenge IDs (5 minutes), nullifiers (replay prevention)
  • Server does NOT collect: Names, emails, addresses, phone numbers, DOB, ID documents, biometric data

Score: ✅ EXEMPLARY

Justification: Privacy is not a “setting” users can change - it’s an architectural constant. The system is designed so it cannot be configured to reveal more information, making privacy the enforced default.

Supporting Details:

  • No opt-in required for privacy protection
  • No settings that weaken privacy guarantees
  • Zero knowledge proofs enforce minimal disclosure automatically
  • Even system administrators cannot access user PII (because it doesn’t exist server-side)

Principle 3: Privacy Embedded into Design

Definition: Privacy is not bolted on as an afterthought - it’s an essential component of the core system architecture and functionality.

Implementation

Privacy is the Cryptographic Protocol

Provii’s privacy protections are embedded in the mathematical structure of zero knowledge proofs:

  1. Groth16 ZK-SNARKs: Core proof system provides soundness (can’t fake age) and zero knowledge (reveals nothing beyond threshold)
  2. Pedersen Commitments: Cryptographically binding commitment to DOB computed server-side during issuance (DOB immediately discarded)
  3. RedJubjub Signatures: Issuer signs credentials after computing the commitment from transiently-processed DOB
  4. Nullifier System: Prevents credential reuse through one-way hash derivation

Privacy-First Architecture Choices:

  • Circuit Design. Age verification circuit proves dob_days >= cutoff_days in zero knowledge
  • Trust-Based Issuance. Issuer transiently processes DOB for commitment computation, then discards it; cannot correlate credentials to users after issuance
  • Unlinkable Verification. Verifier cannot track users across sites
  • No Central Database. Credentials stored in user-controlled wallet

Evidence

Cryptographic Implementation:

  • /trust/compliance/evidence/cryptography/crypto-implementation-evidence.md (Lines 52-153) - Groth16 ZK-SNARK implementation
  • provii-crypto/crypto-circuit-age/src/lib.rs (Lines 100-150) - Circuit constraint system

Privacy Architecture:

  • /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 486-583) - Issuance and verification flows

Code References:

// Pedersen commitment: Cryptographically hides DOB
pub fn pedersen_commit_dob(dob_days: i32, r_bits: &[bool]) -> [u8; 32] {
    let mut in_bits = dob_bits;
    in_bits.extend_from_slice(r_bits);

    let point = pedersen_hash(
        Personalization::NoteCommitment,
        in_bits.into_iter()
    );

    point.to_bytes()
}

// Nullifier: Prevents replay without revealing identity
pub fn pedersen_nullifier(c_bytes: &[u8; 32]) -> [u8; 32] {
    const NULLIFIER_DST: &[u8] = b"provii.nullifier.pedersen.v1";
    // ... hash commitment with domain separator ...
}

Score: ✅ EXEMPLARY

Justification: Privacy is not added as a layer - it’s the fundamental cryptographic protocol. The zero knowledge proof system cannot function without privacy guarantees, making privacy inseparable from core functionality.

Supporting Details:

  • Privacy cannot be “disabled” or “bypassed” without breaking the entire system
  • Every component (commitment, signature, proof) contributes to privacy
  • Architecture diagrams show privacy at every layer
  • Code review shows privacy embedded in cryptographic primitives

Principle 4: Full Functionality - Positive-Sum, not Zero-Sum

Definition: Achieve legitimate system objectives AND privacy protection simultaneously. Avoid false trade-offs between functionality and privacy.

Implementation

Privacy Enables Functionality, Not Hinders It

Traditional age verification forces a trade-off: effective verification (invasive) OR privacy (ineffective). Provii proves this is a false dichotomy:

User Wins:

  • Privacy. DOB never revealed, no tracking, no PII storage
  • Convenience. Verify once, reuse credential across sites
  • Control. Wallet-based credentials, user initiates verification
  • Portability. Credentials work across any integrated website

Verifier (Website) Wins:

  • Confidence. Cryptographic proof of age (unforgeable)
  • Compliance. Regulatory requirements met (e.g., age-restricted content)
  • Simplicity. No PII storage = no data protection liability
  • Universal. Works across jurisdictions without region-specific PII handling

Issuer Wins:

  • Revenue. Royalty on each verification using their credentials
  • Privacy Protection. Trust-based issuance with ephemeral DOB processing prevents tracking users
  • Reputation. Association with privacy-preserving technology

Evidence

Trust Model:

  • /trust/overview/trust-model.mdx - Unlinkability guarantees for users, cryptographic assurance for verifiers

Age Verification Flow:

  • /trust/compliance/evidence/age-verification/flow-evidence.md (Lines 12-62) - UC-083: Age threshold proof accuracy

Quote from Architecture Documentation:

“Zero knowledge proofs provide the best of both worlds: verifiers get cryptographic proof of age eligibility, users maintain complete privacy over their date of birth.”

Business Model Evidence:

  • Users: Free (no data monetization)
  • Websites: Pay per verification (fraud-resistant pricing)
  • Issuers: Royalty per verification (incentivizes credential issuance)
  • No party requires user tracking for revenue

Score: ✅ EXEMPLARY

Justification: Provii proves privacy and functionality are complementary, not competing. Zero knowledge cryptography achieves stronger verification (unforgeable proofs) AND stronger privacy (no PII) than traditional methods.

Supporting Details:

  • Users gain privacy without sacrificing verification effectiveness
  • Verifiers gain cryptographic assurance without PII liability
  • System demonstrates “positive-sum” design - all parties benefit
  • Revenue model requires no privacy compromises

Principle 5: End-to-End Security - Full Lifecycle Protection

Definition: Secure data throughout the entire lifecycle from collection to destruction, with strong encryption, access controls, and timely disposal.

Implementation

Security Across Entire Credential Lifecycle

1. Issuance Phase:

  • Wallet submits attestation. DobAttestation + blinding randomness (r_bits) sent to issuer API
  • Server-side commitment. Issuer verifies attestation, computes Pedersen commitment, immediately discards DOB
  • Credential storage. Encrypted in wallet (mobile secure storage)
  • Security. DOB processed ephemerally and never stored, logged, or retained; issuer cannot track future verifications

2. Storage Phase:

  • Client-side encryption. Credentials stored in wallet (Android Keystore, iOS Keychain)
  • No server-side PII. Only encrypted credentials in user control
  • Key management. Private keys never leave device
  • Backup. User-controlled (optional cloud backup, encrypted)

3. Verification Phase:

  • Proof generation. Client-side, uses credential + challenge
  • Transmission security. HTTPS/TLS for proof submission
  • Nullifier check. Prevents replay without revealing identity
  • Result. Verifier learns only threshold result (over/under age)

4. Deletion Phase:

  • User-initiated. Delete wallet app = delete credentials
  • Server-side. IP logs auto-deleted after 90 days
  • Challenge records. Auto-deleted after 5 minutes (challenge TTL)
  • Nullifiers. One-way hashes, cannot reveal PII even if stored
  • Cryptographic erasure. Sensitive data zeroized from memory (zeroize crate)

Evidence

Data Lifecycle:

  • /trust/compliance/evidence/privacy-controls/data-lifecycle-evidence.md (Lines 45-108) - Retention policies and automated deletion

Cryptographic Security:

  • /trust/compliance/evidence/cryptography/crypto-implementation-evidence.md (Lines 267-407) - Key generation, randomness sources, signature security

Code Evidence:

// Cryptographic erasure after use
use zeroize::Zeroize;

cached.submit_secret.zeroize(); // Securely overwrite in memory

Data Retention Policy:

  • /trust/security/data-retention.mdx (Lines 19-48)
  • Audit logs (including hashed IP addresses): 90 days; critical security event logs are retained for up to 365 days
  • Challenge records: 5 minutes
  • No PII retention (none collected)

Automated Deletion:

  • KV TTL-based expiration for challenges
  • Cloudflare Workers Logs in Grafana Cloud (Loki, SaaS sub-processor): automatic 90-day Loki tenant retention
  • Cleanup workers for sandbox/test data
  • Nonce store with 5-minute TTL for duplicate detection

Score: ✅ IMPLEMENTED

Justification: Lifecycle security from credential generation through deletion. Strong encryption, cryptographic erasure, and automated deletion ensure end-to-end protection.

Supporting Details:

  • Client-side encryption using platform secure storage (Keystore/Keychain)
  • No server-side PII to protect (strongest possible security)
  • Automated deletion prevents indefinite retention
  • Cryptographic primitives (Groth16, Pedersen, RedJubjub) provide mathematical security
  • Memory zeroization prevents secret recovery after use

Minor Gap: No HSM integration for issuer signing keys (Cloudflare KV storage currently). Recommendation: Integrate AWS CloudHSM or Azure Key Vault for production deployment.


Principle 6: Visibility and Transparency - Keep it Open

Definition: Assure stakeholders that privacy practices are operating according to promises and objectives. Enable independent verification through transparency.

Implementation

Radical Transparency - Open Source + Published ISMS

Maelstrom AI’s privacy claims are independently verifiable through complete transparency:

1. Open Source Code:

  • provii-crypto: Cryptographic primitives (ZK-SNARKs, signatures, commitments)
  • provii-verifier: Backend verification service
  • provii-issuer: Credential issuance service
  • Provii mobile wallet (client) repository under the MaelstromAI GitHub enterprise
  • provii-agegate: Browser integration SDK

2. Published ISMS:

  • Complete Information Security Management System (9,500+ lines)
  • Security policies, risk assessments, control implementations
  • Compliance documentation (ISO 27001, Privacy by Design)
  • Publicly accessible at GitHub repository

3. Architecture Documentation:

  • System architecture diagrams
  • Data flow documentation
  • Privacy guarantees explained
  • Trust model specification
  • Cryptographic protocol details

4. Privacy Policies:

  • Data retention policy (what’s collected, how long, why)
  • Information security policy (zero knowledge principles)
  • User-facing privacy notices
  • Published at maelstrom.au/trust

Evidence

Open Source Repositories:

  • GitHub: All core components open source
  • License: Permissive (Apache 2.0 / MIT)
  • Public audit: Anyone can review code

Published ISMS:

  • /trust/ - Entire ISMS published
  • Location: Public GitHub repository (branch: docs/iso27001-isms)
  • Classification: Public

Quote from Information Security Policy (Lines 111-121):

“We make our security practices public because:

  • We have nothing to hide (no PII to protect through obscurity)
  • Open scrutiny improves security
  • It builds trust through verifiability
  • It enables independent audit of our privacy claims”

Documentation:

  • /trust/overview/architecture.mdx - System architecture
  • /trust/overview/trust-model.mdx - Privacy guarantees
  • /trust/security/data-retention.mdx - Data retention
  • Trust Centre: maelstrom.au/trust

Score: ✅ EXEMPLARY

Justification: Complete transparency through open source code, published ISMS, and public documentation. Privacy claims are independently verifiable by anyone with technical expertise.

Supporting Details:

  • Open source enables independent security audit
  • Published ISMS demonstrates governance and controls
  • Public documentation explains privacy architecture
  • No security-through-obscurity (zero knowledge proofs don’t require secret algorithms)
  • Transparency builds trust without compromising security

Unique Achievement: Most companies treat security documentation as confidential. Maelstrom AI publishes everything because the zero knowledge architecture has nothing to hide.


Principle 7: Respect for User Privacy - Keep it User-Centric

Definition: Keep the interests of users paramount. Provide user-friendly options, strong defaults, clear privacy notices, and empower users to control their data.

Implementation

User Sovereignty - Full Control Over Credentials

The Provii platform puts users in complete control of their age credentials:

1. User-Controlled Wallet:

  • Credentials stored locally. User’s device (not Maelstrom AI servers)
  • Private keys never leave device. User has sole access
  • Proof generation. User initiates, controls when to verify
  • No central database. Maelstrom AI cannot revoke user credentials unilaterally

2. User Control Points:

  • Issuance. User chooses which issuer to trust
  • Storage. User controls wallet backup/restore
  • Verification. User decides when to prove age
  • Deletion. User can delete wallet (destroys credentials)
  • Portability. Credentials work across any Provii-integrated site

3. User-Friendly Design:

  • Simple verification flow. QR code scan or challenge code entry
  • No account required. No username/password, no PII registration
  • Accessible. Text-based challenge codes for users unable to scan QR
  • Cross-platform. Works on Android, iOS, web

4. Privacy Notices:

  • Point-of-collection. Privacy notice when generating credentials
  • Age-appropriate. Clear language explaining privacy protections
  • Wallet UI. “Your date of birth is processed once during setup and immediately discarded. it is never stored by Maelstrom AI”
  • Transparency. Open source code enables technical verification

Evidence

Wallet Control:

  • /trust/core/provii-mobile.mdx - Wallet architecture (local credential storage)
  • Credentials stored in: Android Keystore (Android), Keychain (iOS)
  • Private keys: Generated on device, never transmitted

User Rights:

  • /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 220-255) - UC-005: User Rights Implementation

User Control Evidence:

  • Right to Access. Users export wallet data locally (JSON)
  • Right to Deletion. Users delete wallet app (destroys credentials)
  • Right to Portability. Credentials are standard format (portable)
  • Right to Rectification. Users update DOB in wallet (new credentials generated)
  • Right to Restrict Processing. Users control when proofs are generated

Accessibility:

  • /trust/compliance/evidence/age-verification/flow-evidence.md (Lines 411-442) - UC-091: Age Verification Accessibility
  • QR code scanning (primary method)
  • 12-character challenge codes (text entry alternative)
  • Uppercase formatting for readability

Privacy Notice Evidence:

  • Privacy policy published at maelstrom.au/trust
  • In-wallet privacy information (planned)
  • Clear explanation: “Maelstrom AI servers are not designed to receive or store your personal information”

Score: ✅ IMPLEMENTED

Justification: Users have complete control over credentials through wallet-based architecture. All major user rights supported (access, deletion, portability). Privacy-friendly defaults require no user configuration.

Supporting Details:

  • Wallet-based architecture is designed to remove the need for central control of credentials
  • User initiates all proof generation (explicit action)
  • No forced registration or PII submission
  • Credentials portable across sites
  • Accessible verification methods (QR + text codes)

Minor Gap: In-wallet privacy notice documentation needs verification. Recommendation: Ensure wallet displays privacy information prominently.


Overall Assessment

Privacy by Design Maturity Matrix

PrincipleScoreKey StrengthsAreas for Improvement
1. Proactive not Reactive✅ EXEMPLARYZero knowledge architecture prevents PII collectionNone identified
2. Privacy as Default✅ EXEMPLARYPrivacy hardcoded, not configurableNone identified
3. Privacy Embedded✅ EXEMPLARYPrivacy is the cryptographic protocolNone identified
4. Full Functionality✅ EXEMPLARYPrivacy enables functionality, not hindersNone identified
5. End-to-End Security✅ IMPLEMENTEDLifecycle protectionHSM integration for issuer keys recommended
6. Visibility and Transparency✅ EXEMPLARYOpen source + published ISMSNone identified
7. User-Centric✅ IMPLEMENTEDWallet-based control, user sovereigntyIn-wallet privacy notice needs verification

Overall Score: 5/7 EXEMPLARY, 7/7 IMPLEMENTED

Assessment Summary:

Maelstrom AI achieves EXEMPLARY status on 5 out of 7 Privacy by Design principles and full implementation on all 7. This represents strong privacy engineering, with privacy protections designed to be stronger than policy-based systems.

Why This Matters:

  1. Architectural Protections over Policy Promises: Zero knowledge proofs are designed to make extracting PII computationally infeasible
  2. Regulatory Alignment: Architecture designed to meet GDPR Article 25 (Privacy by Design)
  3. Privacy-Preserving Design: Architecture designed for privacy-preserving age verification at scale
  4. User Trust: Cryptographic proofs support stronger user trust than privacy policies alone
  5. Operational Simplification: No PII persisted = reduced data breach liability, simpler operations

Competitive Analysis

Provii vs Traditional Age Verification

AspectProvii (Privacy by Design)Traditional Systems
Data CollectionNone (zero knowledge proofs)Full PII required (name, DOB, address, ID scan)
Privacy ProtectionCryptographic protection (by design)Policy-based (trust us)
Cross-Site TrackingArchitecturally prevented (random IDs)Common practice (persistent identifiers)
User ControlFull (wallet-based credentials)None (centralized databases)
Data Breach RiskMinimal (no PII to breach)High (honeypot of PII)
TransparencyOpen source, public ISMSProprietary, confidential
Regulatory ComplianceBuilt-in (GDPR Article 25)Bolt-on (retrofitted compliance)
User TrustMathematical proofPrivacy policy
Business LiabilityLow (no PII storage)High (data protection obligations)
Operational ComplexitySimple (no PII lifecycle)Complex (retention, deletion, rights requests)

Privacy by Design as a Factual Differentiator

Privacy Architecture Summary:

  • Privacy-Preserving Design. Privacy-preserving age verification for privacy-conscious users
  • Regulatory Alignment. Reduced GDPR/CCPA compliance burden for clients
  • Enterprise Suitability. Privacy-by-design architecture for enterprise requirements
  • Transparent Design. Open source implementation allows independent verification

Accurate, Defensible Statements:

  • ✅ “Zero knowledge age verification - we can’t see your personal information”
  • ✅ “Privacy by Design aligned - built-in GDPR Article 25 compliance”
  • ✅ “Minimal breach impact - we don’t persist your PII”
  • ✅ “Open source transparency - verify our privacy claims”
  • ✅ “User-controlled credentials - you own your age verification”

Privacy as Business Value

How Privacy by Design Creates Value

1. Regulatory Compliance Simplified

GDPR Compliance:

  • Article 5 (Principles). Data minimization, purpose limitation - DOB processed ephemerally during issuance only, never persisted
  • Article 25 (Privacy by Design). Built into architecture, not retrofitted
  • Article 30 (Records of Processing). Simplified (DOB processed transiently and discarded; no PII persisted)
  • Article 32 (Security). Strong (cryptographic protections by design)
  • Article 33-34 (Breach Notification). Minimal risk (no PII persisted to breach)

CCPA Compliance:

  • No “sale” of personal information (no PI persisted or shared)
  • Right to know satisfied (DOB processed ephemerally, never stored)
  • Right to deletion automatic (no PI persisted to delete)
  • Simplified privacy notice (minimal PI categories, ephemeral processing only)

Other Regulations:

  • UK Children’s Code: Privacy-first design for under-18 verification
  • COPPA: No PII collection from children
  • Australian Privacy Act: APP 3 minimization satisfied

Value: Reduced compliance burden, lower legal risk, simpler operations.

2. User Trust and Adoption

Trust Factors:

  • Mathematical Proof. Zero knowledge proofs more trustworthy than privacy policies
  • Open Source. Code transparency enables independent verification
  • No Account Required. Frictionless verification (no registration)
  • User Control. Wallet-based credentials empower users

Adoption Drivers:

  • Privacy-conscious users may prefer Provii over invasive alternatives
  • Parents may trust the system for children’s age verification given the reduced PII exposure
  • Enterprise customers seeking privacy-preserving solutions may find the architecture well suited to their requirements

Value: The privacy-preserving architecture may support user trust and uptake where privacy is a key concern.

3. Data Breach Protection

Traditional Age Verification Risk:

  • Centralised database of names, DOBs, ID scans = honeypot for attackers
  • Data breach = regulatory fines (GDPR up to 4% global revenue)
  • Reputational damage, customer churn

Maelstrom AI Risk Profile:

  • No PII to breach (IP addresses only, 90-day retention)
  • Breach reveals: Encrypted nullifiers (useless to attacker)
  • Minimal GDPR breach notification risk (no PI persisted to compromise)

Value: Significantly reduced data breach liability, lower GDPR fine exposure, minimal reputational risk from PII incidents.

4. Operational Simplicity

Traditional Systems:

  • PII storage requires encryption, access controls, audit logs
  • User rights requests (access, deletion, rectification)
  • Data retention schedules, deletion workflows
  • Cross-border transfer mechanisms (SCCs)
  • DPO appointment, DPIA processes

Maelstrom AI / Provii:

  • No PII storage = no PII lifecycle management
  • User rights mostly “not applicable” (no data held)
  • Minimal retention (IP logs 90 days, auto-deleted)
  • No cross-border PII transfer concerns
  • Simplified privacy governance

Value: Lower operational costs, simpler processes, fewer staff required for compliance.


Certification Potential

Privacy by Design Certification

Certifying Body: Ryerson University (now Toronto Metropolitan University) - Privacy by Design Centre of Excellence

Certification Process:

  1. Self-assessment against 7 principles
  2. Independent privacy audit
  3. Architecture review by privacy experts
  4. Certification issuance (renewable)

Readiness Assessment:

PrincipleReadinessNotes
1. Proactive✅ ReadyZero knowledge architecture documented
2. Default✅ ReadyPrivacy hardcoded, not configurable
3. Embedded✅ ReadyCryptographic protocol = privacy protocol
4. Full Functionality✅ ReadyPositive-sum design demonstrated
5. End-to-End Security✅ ReadyLifecycle security documented
6. Transparency✅ ReadyOpen source + published ISMS
7. User-Centric✅ ReadyWallet-based control demonstrated

Overall Readiness: READY - All principles implemented with strong evidence.

Certification Value:

  • Third-Party Validation. Recognised “Privacy by Design Certified” status
  • Independent Assurance. Third-party validation of privacy claims
  • Regulatory. Demonstrates GDPR Article 25 compliance
  • Privacy Architecture Verification. Independent verification of privacy-by-design implementation

Recommendation: Pursue Privacy by Design certification as a priority certification (easier than ISO 27701, and provides independent validation of the privacy architecture).

Other Privacy Certifications

ISO 27701 (Privacy Information Management):

  • Extension of ISO 27001 for privacy
  • Maelstrom AI: Strong position (ISO 27001 ISMS structured and aligned; certification being pursued when commercially justified)
  • Timeline: 6-12 months after ISO 27001 certification

NIST Privacy Framework:

  • Self-assessment framework (not certification)
  • Maelstrom AI: Strong alignment
  • Timeline: 1-2 months documentation effort

Kantara Privacy Assessment:

  • Privacy-enhancing technology evaluation
  • Provii: Excellent fit for zero knowledge systems
  • Timeline: 3-6 months

Recommendations

Immediate Priorities (Planned H1 2026)

  1. Complete Formal DPIA
  • Effort. 2-4 hours
  • Value. Strengthens UC-007 (Privacy Impact Assessment)
  • Evidence. Document privacy risks, mitigations, architectural decisions
  1. Document In-Wallet Privacy Notice
  • Effort. 2-4 hours
  • Value. Enhances Principle 7 (User-Centric)
  • Content. “Your date of birth is processed once during credential setup and immediately discarded. Maelstrom AI never stores your DOB”, “During age checks, only a cryptographic proof is shared”
  1. Create Privacy by Design Whitepaper
  • Effort. 1 week
  • Value. Technical documentation and transparency; accessible explanation of the privacy architecture
  • Content. This assessment + technical deep-dive

Short-Term Priorities (Planned H2 2026)

  1. Pursue Privacy by Design Certification
  • Effort. 3-6 months (including audit)
  • Value. Third-party validation of the privacy architecture
  • Cost. $10k-$30k (estimate)
  1. Implement HSM for Issuer Keys
  • Effort. 2-3 months
  • Value. Strengthens Principle 5 (End-to-End Security)
  • Options. AWS CloudHSM, Azure Key Vault HSM
  1. Formal Cryptographic Audit
  • Effort. 4-6 weeks (external audit firm)
  • Value. Validates zero knowledge implementation
  • Cost. $50k-$100k
  • Priority. Critical before high-volume production

Long-Term Priorities (2027)

  1. ISO 27701 Privacy Certification
  • Effort. 6-12 months
  • Value. International privacy management certification
  • Prerequisite. ISO 27001 certification
  1. Privacy Transparency Report
  • Effort. Ongoing (quarterly/annual)
  • Value. Public transparency, builds trust
  • Content. Privacy metrics, requests, incidents
  1. Responsible Disclosure Programme
  • Effort. Implemented (security@maelstrom.au)
  • Value. Enable security researchers to report privacy/security findings
  • Method. Email-based responsible disclosure

Conclusion

Provii as Exemplar of Privacy by Design

Maelstrom AI demonstrates thorough implementation of Privacy by Design across all seven foundational principles through the Provii platform. The platform’s zero knowledge verification architecture provides strong cryptographic privacy protections during age verification, combined with a trust-based issuance model where DOB is processed ephemerally and immediately discarded.

Key Achievements:

  1. Architectural Privacy: DOB processed ephemerally during issuance and never persisted; verification reveals no PII
  2. Zero knowledge Proofs: Prove age without revealing date of birth
  3. Radical Transparency: Open source code, published ISMS
  4. User Sovereignty: Wallet-based credentials under user control
  5. Business Model Alignment: Revenue requires no user tracking
  6. Regulatory Alignment: Architecture designed to meet GDPR Article 25 (Privacy by Design)
  7. Privacy-Preserving Design: Architecture designed for privacy-preserving age verification at scale

Privacy as a Core Design Objective

Privacy by Design is implemented as an architectural objective, not a compliance afterthought:

  • Privacy-First Architecture. Privacy-preserving alternative to invasive systems
  • User Trust. Cryptographic proofs support stronger user trust than policy-only approaches
  • Regulatory Alignment. Architecture designed to align with GDPR/CCPA requirements
  • Operational Simplicity. No PII = simpler business operations
  • Risk Reduction. Reduced data breach liability (no PII persisted)

Next Steps

Planned Actions:

  1. Certification: Pursue Privacy by Design certification (3-6 months)
  2. Cryptographic Audit: Validate zero knowledge implementation ($50k-$100k)
  3. Public Documentation: Publish privacy whitepapers, transparency reports
  4. Transparency: Ongoing publication of privacy governance documentation
  5. Continuous Improvement: Annual privacy reviews, ongoing enhancements

Objective: Develop Provii as a robust implementation of privacy-preserving age verification, demonstrating that privacy and functionality are complementary, not competing objectives.


Appendix: Evidence Index

Architecture Documentation

  1. /trust/overview/architecture.mdx - System architecture
  2. /trust/overview/trust-model.mdx - Privacy guarantees
  3. /trust/core/provii-crypto.mdx - Cryptographic design

Privacy Evidence

  • /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md - Privacy controls (UC-001 to UC-011)
  • /trust/compliance/evidence/privacy-controls/data-lifecycle-evidence.md - Data lifecycle (UC-017, UC-102-105)

Cryptographic Evidence

  • /trust/compliance/evidence/cryptography/crypto-implementation-evidence.md - Cryptographic controls (UC-071 to UC-082)
  • provii-crypto/* - Source code for zero knowledge proofs

Security Evidence

  1. /trust/compliance/evidence/security-controls/api-security-evidence.md - API security
  2. /trust/compliance/evidence/security-controls/access-control-evidence.md - Access controls
  3. /trust/compliance/evidence/security-controls/logging-monitoring-evidence.md - Logging and monitoring

Age Verification Evidence

  • /trust/compliance/evidence/age-verification/flow-evidence.md - Age verification flows (UC-083 to UC-093)

Policy Documentation

  1. /trust/security/information-security-policy.mdx - Information Security Policy
  2. /trust/security/data-retention.mdx - Data Retention Policy
  3. /trust/security/cryptography-policy.mdx - Cryptography Policy

Document Information

FieldValue
Version1.1
Created2025-11-08
Last Updated2026-02-13
OwnerMaelstrom AI
ClassificationPublic
Next Review2026-11-21 (or after major architecture changes)
ApprovalISMS Owner

Revision History

VersionDateAuthorChanges
1.02025-11-08Maelstrom AIInitial assessment
1.12026-02-13Compliance & ISMS SpecialistUpdated stale date references and action timelines