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 Category | Score |
|---|---|
| Principles Achieving EXEMPLARY Status | 5 out of 7 |
| Principles Fully Implemented | 7 out of 7 |
| Principles Partially Implemented | 0 out of 7 |
| Principles Not Met | 0 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
- Architectural Privacy Design - DOB processed ephemerally during issuance and not persisted; verification is designed to reveal no PII
- Zero knowledge Proofs - Mathematical proof of age without revealing date of birth
- Radical Transparency - Open source code, published ISMS, public documentation
- User Control - Wallet-based credentials, no central database of user data
- 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:
- Proactive not Reactive; Preventative not Remedial
- Privacy as the Default Setting
- Privacy Embedded into Design
- Full Functionality - Positive-Sum, not Zero-Sum
- End-to-End Security - Full Lifecycle Protection
- Visibility and Transparency - Keep it Open
- 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:
- Groth16 Zero knowledge Proofs: By design, proofs reveal only the age threshold result (over/under) and nothing more
- Ephemeral Server-Side Processing: DOB transmitted once during issuance for Pedersen commitment computation, then immediately discarded. never stored, logged, or retained
- Trust-Based Credential Issuance: Issuer computes Pedersen commitment from DOB and blinding randomness (r_bits), signs the credential, and discards the DOB
- 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 DOBprovii-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:
- Information Revelation: Only binary age threshold (e.g., “18+”), never actual age or DOB
- Cross-Site Tracking: Prevented by design - random IDs per verification prevent linkage
- Credential Reuse Detection: Nullifiers prevent replay without revealing user identity
- 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 onlycutoff_dayscomparison 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:
- Groth16 ZK-SNARKs: Core proof system provides soundness (can’t fake age) and zero knowledge (reveals nothing beyond threshold)
- Pedersen Commitments: Cryptographically binding commitment to DOB computed server-side during issuance (DOB immediately discarded)
- RedJubjub Signatures: Issuer signs credentials after computing the commitment from transiently-processed DOB
- Nullifier System: Prevents credential reuse through one-way hash derivation
Privacy-First Architecture Choices:
- Circuit Design. Age verification circuit proves
dob_days >= cutoff_daysin 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 implementationprovii-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 (
zeroizecrate)
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 serviceprovii-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
| Principle | Score | Key Strengths | Areas for Improvement |
|---|---|---|---|
| 1. Proactive not Reactive | ✅ EXEMPLARY | Zero knowledge architecture prevents PII collection | None identified |
| 2. Privacy as Default | ✅ EXEMPLARY | Privacy hardcoded, not configurable | None identified |
| 3. Privacy Embedded | ✅ EXEMPLARY | Privacy is the cryptographic protocol | None identified |
| 4. Full Functionality | ✅ EXEMPLARY | Privacy enables functionality, not hinders | None identified |
| 5. End-to-End Security | ✅ IMPLEMENTED | Lifecycle protection | HSM integration for issuer keys recommended |
| 6. Visibility and Transparency | ✅ EXEMPLARY | Open source + published ISMS | None identified |
| 7. User-Centric | ✅ IMPLEMENTED | Wallet-based control, user sovereignty | In-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:
- Architectural Protections over Policy Promises: Zero knowledge proofs are designed to make extracting PII computationally infeasible
- Regulatory Alignment: Architecture designed to meet GDPR Article 25 (Privacy by Design)
- Privacy-Preserving Design: Architecture designed for privacy-preserving age verification at scale
- User Trust: Cryptographic proofs support stronger user trust than privacy policies alone
- Operational Simplification: No PII persisted = reduced data breach liability, simpler operations
Competitive Analysis
Provii vs Traditional Age Verification
| Aspect | Provii (Privacy by Design) | Traditional Systems |
|---|---|---|
| Data Collection | None (zero knowledge proofs) | Full PII required (name, DOB, address, ID scan) |
| Privacy Protection | Cryptographic protection (by design) | Policy-based (trust us) |
| Cross-Site Tracking | Architecturally prevented (random IDs) | Common practice (persistent identifiers) |
| User Control | Full (wallet-based credentials) | None (centralized databases) |
| Data Breach Risk | Minimal (no PII to breach) | High (honeypot of PII) |
| Transparency | Open source, public ISMS | Proprietary, confidential |
| Regulatory Compliance | Built-in (GDPR Article 25) | Bolt-on (retrofitted compliance) |
| User Trust | Mathematical proof | Privacy policy |
| Business Liability | Low (no PII storage) | High (data protection obligations) |
| Operational Complexity | Simple (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:
- Self-assessment against 7 principles
- Independent privacy audit
- Architecture review by privacy experts
- Certification issuance (renewable)
Readiness Assessment:
| Principle | Readiness | Notes |
|---|---|---|
| 1. Proactive | ✅ Ready | Zero knowledge architecture documented |
| 2. Default | ✅ Ready | Privacy hardcoded, not configurable |
| 3. Embedded | ✅ Ready | Cryptographic protocol = privacy protocol |
| 4. Full Functionality | ✅ Ready | Positive-sum design demonstrated |
| 5. End-to-End Security | ✅ Ready | Lifecycle security documented |
| 6. Transparency | ✅ Ready | Open source + published ISMS |
| 7. User-Centric | ✅ Ready | Wallet-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)
- Complete Formal DPIA
- Effort. 2-4 hours
- Value. Strengthens UC-007 (Privacy Impact Assessment)
- Evidence. Document privacy risks, mitigations, architectural decisions
- 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”
- 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)
- Pursue Privacy by Design Certification
- Effort. 3-6 months (including audit)
- Value. Third-party validation of the privacy architecture
- Cost. $10k-$30k (estimate)
- Implement HSM for Issuer Keys
- Effort. 2-3 months
- Value. Strengthens Principle 5 (End-to-End Security)
- Options. AWS CloudHSM, Azure Key Vault HSM
- 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)
- ISO 27701 Privacy Certification
- Effort. 6-12 months
- Value. International privacy management certification
- Prerequisite. ISO 27001 certification
- Privacy Transparency Report
- Effort. Ongoing (quarterly/annual)
- Value. Public transparency, builds trust
- Content. Privacy metrics, requests, incidents
- 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:
- Architectural Privacy: DOB processed ephemerally during issuance and never persisted; verification reveals no PII
- Zero knowledge Proofs: Prove age without revealing date of birth
- Radical Transparency: Open source code, published ISMS
- User Sovereignty: Wallet-based credentials under user control
- Business Model Alignment: Revenue requires no user tracking
- Regulatory Alignment: Architecture designed to meet GDPR Article 25 (Privacy by Design)
- 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:
- Certification: Pursue Privacy by Design certification (3-6 months)
- Cryptographic Audit: Validate zero knowledge implementation ($50k-$100k)
- Public Documentation: Publish privacy whitepapers, transparency reports
- Transparency: Ongoing publication of privacy governance documentation
- 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
/trust/overview/architecture.mdx- System architecture/trust/overview/trust-model.mdx- Privacy guarantees/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
/trust/compliance/evidence/security-controls/api-security-evidence.md- API security/trust/compliance/evidence/security-controls/access-control-evidence.md- Access controls/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
/trust/security/information-security-policy.mdx- Information Security Policy/trust/security/data-retention.mdx- Data Retention Policy/trust/security/cryptography-policy.mdx- Cryptography Policy
Document Information
| Field | Value |
|---|---|
| Version | 1.1 |
| Created | 2025-11-08 |
| Last Updated | 2026-02-13 |
| Owner | Maelstrom AI |
| Classification | Public |
| Next Review | 2026-11-21 (or after major architecture changes) |
| Approval | ISMS Owner |
Revision History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 2025-11-08 | Maelstrom AI | Initial assessment |
| 1.1 | 2026-02-13 | Compliance & ISMS Specialist | Updated stale date references and action timelines |