Provider-Side Data Absence (PSDA)
An Optional Property Beyond ZKS Requirements
Version: 1.0 Status: Position Paper Audience: Security Architects, CISOs, Compliance Officers
Executive Summary
Provider-Side Data Absence (PSDA) is an architectural property where service providers never store user ciphertext on their infrastructure. PSDA is not required for ZKS compliance but provides additional security benefits for implementations that achieve it.
| Property | ZKS Requirement | Security Benefit |
|---|---|---|
| Provider cannot decrypt | Required | Protects confidentiality |
| Provider never holds ciphertext | Optional (PSDA) | Eliminates data exposure entirely |
Key insight: ZKS ensures providers cannot decrypt. PSDA ensures providers never possess the encrypted data in the first place.
Definitions
Zero-Knowledge Sovereignty (ZKS)
ZKS requires that providers cannot reconstruct decryptability:
"No provider may control the components necessary to reconstruct decryptability - now or in the future."
A ZKS-compliant system may store ciphertext on provider infrastructure, provided the provider never controls key components.
Provider-Side Data Absence (PSDA)
PSDA requires that providers never store user ciphertext:
"No provider-operated service stores user ciphertext at rest. User data exists only on user-controlled endpoints and user-controlled storage substrates."
A PSDA-compliant system ensures ciphertext never resides on provider infrastructure.
The Orthogonal Relationship
ZKS and PSDA answer different questions:
| Property | Question | ZKS-Only System | ZKS + PSDA System |
|---|---|---|---|
| ZKS | "Who can ever decrypt?" | Only the user | Only the user |
| PSDA | "Who ever possesses the encrypted data?" | Provider holds ciphertext | Only user-controlled systems |
These properties are orthogonal - each can be achieved independently:
Why PSDA Matters
Threat Scenarios: ZKS-Only vs. ZKS + PSDA
| Threat | ZKS-Only Response | ZKS + PSDA Response |
|---|---|---|
| Subpoena for user data | Provider produces ciphertext (encrypted, but exposed) | Provider produces no user content (wrapped keys and operational metadata remain producible but are not decryption-enabling) |
| Provider infrastructure breach | Attacker exfiltrates ciphertext | No user content to exfiltrate (metadata and wrapped artifacts remain in scope) |
| Insider threat | Insider can access ciphertext | No user content for insider to access |
| Long-term cryptographic risk | Ciphertext available for future attacks | No ciphertext accumulation |
| Data retention demands | Provider must retain ciphertext per regulation | No content to retain; metadata retention obligations remain |
| Jurisdiction conflicts | Ciphertext subject to storage location laws | No content residency exposure; metadata residency remains subject to analysis |
The "Harvest Now, Decrypt Later" Problem
ZKS-Only:
Adversary strategy:
1. Breach provider infrastructure
2. Exfiltrate all ciphertext
3. Wait for cryptographic advances
4. Decrypt in the future
Provider status: ZKS-compliant (cannot decrypt today)
Adversary status: Patient (may decrypt tomorrow)
User risk: Non-zero (ciphertext exposed)
ZKS + PSDA:
Adversary strategy:
1. Breach provider infrastructure
2. Find no ciphertext to exfiltrate
3. No "harvest" possible
Provider status: ZKS-compliant + PSDA-compliant
Adversary status: Unable to harvest content
User risk: No ciphertext exposure via the provider
(metadata exposure and user-storage risk remain - see Limitations)
PSDA Architecture
Data Flow: ZKS-Only (Common Pattern)
Data Flow: ZKS + PSDA
PSDA Criteria
A system satisfies PSDA if and only if:
Criterion 1: No Ciphertext at Rest
No service operated by the provider stores user ciphertext at rest.
| Compliant | Non-Compliant |
|---|---|
| Provider stores only metadata | Provider stores encrypted files |
| Provider stores only wrapped keys | Provider stores encrypted messages |
| Provider stores only coordination data | Provider stores encrypted database |
Criterion 2: No Ciphertext Caching
No service operated by the provider caches user ciphertext beyond immediate delivery.
| Compliant | Non-Compliant |
|---|---|
| Fire-and-forget message relay | Message queue with persistence |
| Stateless data relay | CDN caching of ciphertext |
| Ephemeral transport only | Temporary storage for delivery |
Criterion 3: User-Controlled Data Flow
User ciphertext flows only between user-controlled endpoints and user-controlled storage.
| Compliant | Non-Compliant |
|---|---|
| Device-to-device P2P | Device-to-server-to-device |
| Device-to-user's-cloud-storage | Device-to-provider-storage |
| Relay without inspection or storage | Store-and-forward with persistence |
Criterion 4: Provider Role Limited to Coordination
The provider's role is limited to coordination, key delivery, and transport facilitation - not data storage.
| Provider May Do | Provider May Not Do |
|---|---|
| Route messages (ephemeral) | Store messages |
| Deliver wrapped keys (TTL) | Store ciphertext |
| Coordinate sync events | Cache user data |
| Facilitate P2P connections | Persist user content |
Benefits of PSDA
Legal Benefits
| Scenario | ZKS-Only Position | ZKS + PSDA Position |
|---|---|---|
| Subpoena for data | "Here's ciphertext; we can't decrypt" | "We hold no user content" (wrapped keys and metadata remain producible) |
| Data preservation order | Must preserve ciphertext | No content to preserve; held metadata remains preservable |
| Discovery request | Produce ciphertext | Produce no user content; wrapped keys and operational metadata remain producible but are not decryption-enabling |
| Data residency compliance | Must ensure ciphertext location | No content residency exposure; metadata (which may be personal data) remains subject to residency and transfer analysis |
Note: This table describes the technical position, not legal advice. A PSDA provider still holds discoverable material - wrapped keys, connection metadata, device/item identifiers, sync-event logs - much of which is personal data under regimes such as the GDPR (see Limitations below).
Operational Benefits
| Aspect | ZKS-Only | ZKS + PSDA |
|---|---|---|
| Storage costs | Provider bears storage costs | User bears storage costs |
| Scaling | Provider scales storage | User storage scales naturally |
| Backup responsibility | Provider must backup ciphertext | User controls backups |
| Data lifecycle | Provider manages retention | User manages retention |
Security Benefits
| Threat | ZKS-Only Exposure | ZKS + PSDA Exposure |
|---|---|---|
| Breach | Ciphertext exfiltrated | No user content to exfiltrate |
| Insider | Ciphertext accessible | No user content to access |
| Future crypto breaks | Historical ciphertext vulnerable | No historical ciphertext |
| Metadata correlation | Storage patterns visible | Storage patterns absent; coordination metadata remains (A7 applies) |
Implementation Patterns
Pattern 1: Peer-to-Peer with Coordination
Provider role: Signaling, presence, key delivery
Data flow: Direct between user devices
Storage: None on provider
Example: Briar, P2P messaging systems
Pattern 2: User-Controlled Storage Substrate
Provider role: API layer to user's cloud storage
Data flow: User device → User's cloud account
Storage: User's cloud storage (not provider's)
Example: Apps using user's Dropbox/OneDrive/GDrive accounts
Pattern 3: Relay Without Persistence
Provider role: Message relay (fire-and-forget)
Data flow: Through provider but not stored
Storage: Ephemeral only (seconds, not retained)
Example: TURN relays, fire-and-forget messaging
PSDA and ZKS Profiles
PSDA is not required for any ZKS profile, but it can be documented as an additional property:
| Profile | ZKS Requirements | PSDA |
|---|---|---|
| ZKS-Core | A1–A8, A13, common invariants | Optional |
| ZKS-Enhanced | ZKS-Core + metadata + transparency | Optional |
| ZKS-Enterprise | ZKS-Enhanced + delegation + split | Optional |
| ZKS-Core + PSDA | ZKS-Core + no provider ciphertext | Documented |
Documenting PSDA
In compliance assessments, PSDA can be documented as:
## Additional Properties
### Provider-Side Data Absence (PSDA)
This implementation satisfies PSDA criteria:
1. No ciphertext at rest on provider infrastructure
2. No ciphertext caching beyond immediate delivery
3. User data flows only to user-controlled storage
4. Provider role limited to coordination
Provider-operated services handle:
- [Key delivery service] - wrapped keys only, TTL-based
- [Coordination service] - metadata only
- [Relay service] - fire-and-forget, no persistence
Provider-operated services never store:
- User ciphertext
- User plaintext
- User files or content
Limitations
PSDA Does Not Eliminate All Metadata
Even with PSDA, providers may see:
- Connection metadata (who connects when)
- Sync patterns (when users are active)
- Key delivery events (when keys are exchanged)
- Message relay timing (when messages flow)
PSDA eliminates data exposure, not metadata exposure. A7 (Metadata Minimization) addresses metadata separately.
PSDA Requires User-Controlled Storage
PSDA shifts storage responsibility to users. This requires:
- Users have cloud storage accounts or other user-controlled storage
- Users manage storage capacity
- Users handle backup and redundancy
This may not suit all use cases or users.
PSDA May Increase Complexity
P2P architectures and user-controlled storage introduce complexity:
- NAT traversal (TURN/STUN)
- Offline delivery challenges
- Sync conflict resolution
- User storage management
ZKS-only architectures with provider ciphertext storage may be simpler to implement.
Case Study: QuodArca
QuodArca has published a preliminary self-attested conformance statement against ZKS-Core and documents PSDA as an additional property (see the Assessments registry; the full evidence pack per ZKS-1.0 Section 7.5 is pending):
Architecture
| Component | Function | Data Stored |
|---|---|---|
| QKEYS | Key delivery | Wrapped keys (TTL ≤ 1 week) |
| QBEND | Sync coordination | Device/item UUIDs |
| QMSVC | Message relay | None (fire-and-forget) |
| QP2P | P2P transport | None (relay only) |
| CLinks | User storage | Ciphertext (user's accounts) |
PSDA Verification
| Criterion | QuodArca Implementation |
|---|---|
| No ciphertext at rest | Ciphertext only on CLinks (user-controlled) |
| No ciphertext caching | QMSVC is fire-and-forget |
| User-controlled data flow | Device → CLink → Device |
| Provider role limited | Coordination only |
Security Properties
| Property | Status |
|---|---|
| ZKS-Core | Self-attested (preliminary; evidence pack pending) |
| PSDA | Documented as additional property |
Result: The QuodArca architecture combines the ZKS decryptability-control model with PSDA data absence. Note that QKEYS holds wrapped keys (TTL-bounded) while ciphertext resides with distinct third-party storage providers under user account control - a cross-entity separation that is compliant under the per-entity Coexistence Prohibition (ZKS-1.0 §2.2.2) and subject to the metadata non-correlation requirements (A7). QMSVC/QP2P relay handling is transient per ZKS-1.0 §2.2.12 and must be documented as such in conformance evidence.
Conclusion
Provider-Side Data Absence (PSDA) is an optional property that provides security benefits beyond ZKS:
| Benefit | ZKS | PSDA |
|---|---|---|
| Provider cannot decrypt | ✅ | ✅ |
| Provider cannot be compelled to produce ciphertext | Holds ciphertext (encrypted) | ✅ (no ciphertext held; metadata remains producible) |
| No "harvest now, decrypt later" risk via provider | Ciphertext exposed | No ciphertext to harvest |
| Content residency exposure | Ciphertext location matters | No content on provider (metadata residency remains) |
For maximum security: Implement both ZKS (decryptability control) and PSDA (data absence).
For ZKS compliance: PSDA is not required, but its presence can be documented as an additional security property.
References
- ZKS Working Group (2026). Zero-Knowledge Sovereignty Standard, ZKS-1.0-RC2 (Release Candidate). https://zks-standard.org/spec/v1/
- QuodArca ZKS Conformance Statement (preliminary self-attestation). https://zks-standard.org/assessments/quodarca