2. Zero-Knowledge Sovereignty Fundamentals (Normative)

2.1 Formal Definition of Zero-Knowledge Sovereignty (ZKS)

A system is ZKS-Compliant if and only if the user retains unilateral cryptographic, operational, and topological control over their data.

In a ZKS architecture, no third party - including the service provider or any intermediary in the digital supply chain - possesses the technical capability to access, derive, revoke, or intercept the complete set of components required to decrypt the user's information.

For the avoidance of doubt, ZKS compliance is determined by technical capability, not by policy assertions, contractual promises, or stated intent.

2.2 Operative Definitions and Core Concepts

This section defines the operative concepts necessary to interpret the ZKS definition and to evaluate compliance. More formal semantics and test mappings are specified in Appendix B and Appendix D.

2.2.1 Sovereignty vs. Confidentiality vs. Privacy vs. Availability

• Confidentiality concerns preventing unauthorized disclosure of information content.
• Privacy concerns limiting the exposure and misuse of information about individuals (including metadata).
• Availability concerns continued access to data and services within operational requirements.
• Sovereignty, as used in ZKS, concerns unilateral user authority over the data's cryptographic and operational lifecycle such that no third party can obtain or reconstruct decryption capability.

A system MAY provide strong confidentiality while failing sovereignty. Examples of sovereignty-failing configurations include:

• a provider holding keys in an HSM under customer policy control while retaining technical capability to use those keys (policy-based control is not capability-based control);
• a provider capable of revoking the user's decryptability through service termination, key invalidation, or withholding essential components; or
• a provider capable of deriving key material through recovery channels, password reset flows, or administrative backdoors.

Such systems are not ZKS-compliant regardless of confidentiality strength.

2.2.2 Complete Set of Components Required to Decrypt

The "complete set of components required to decrypt" includes any combination of artifacts that, when obtained together, enables decryption of user information. This includes, but is not limited to:

• plaintext decryption keys (e.g., item keys, content keys);
• wrapped/encrypted key material if the unwrapping capability is also obtainable;
• key derivation inputs and secrets (e.g., salts, seeds, protected master material) where derivation yields decryption keys;
• authorization artifacts that enable release of decryption material (e.g., recovery secrets, escrow release tokens, privileged administrative credentials);
• device-resident secrets where possession yields unwrapping capability; and
• any metadata, routing material, or orchestration mechanisms that - when combined with other components or used to target the acquisition of other components - yields decryption capability.

ZKS compliance requires that no third party can obtain this complete set, whether directly, indirectly, or through collaboration among intermediaries.

2.2.3 Access (in the ZKS context)

"Access" refers to the capability to read or derive plaintext information content from the protected user information. A third party that can decrypt user information-or can cause it to be decrypted on their behalf without user authorization-violates ZKS.

2.2.4 Interception (in the ZKS context)

"Intercept" refers to the capability to capture decryption-relevant components in transit or during operational processes, including through:

• network interception;
• privileged instrumentation of infrastructure;
• protocol termination points; or
• orchestration-layer collection.

A system is not ZKS-compliant if any third party can intercept the complete set of components required to decrypt, even if no single component appears sensitive in isolation.

2.2.5 Relocation and Data Topology in the ZKS context

ZKS-compliant systems MUST preserve user authority over data topology, i.e. where ciphertext and key material reside. Relocation concerns arise when third parties can:

• force ciphertext to remain in provider-controlled storage formats or locations;
• prevent migration of ciphertext substrates without provider permission or proprietary tooling; or
• compel that decryption-relevant components be stored in locations that enable third-party derivation or interception.

A ZKS-compliant system MUST preserve user authority to relocate ciphertext substrates and MUST NOT require third-party custody of the complete decryption component set as a condition of continued decryptability.

Relationship to Core Definition: Topology constraints that enable third parties to derive or intercept decryption components constitute violations of the core ZKS definition. Tenet 5 (User-Governed Data Topology) addresses this requirement directly.

2.2.6 Revocation (in the ZKS context)

"Revocation" is the most frequently misunderstood term and is defined narrowly and normatively:

• Revocation of availability (service denial): a third party denies access to a service endpoint (e.g., cloud storage account suspension, network blocking). This affects availability but does not necessarily affect decryptability.

• Revocation of decryptability (sovereignty failure): a third party can deny, invalidate, or permanently prevent the user from obtaining the complete set of components required to decrypt their information (given ciphertext availability)-even when the user remains authorized.

ZKS compliance prohibits revocation of decryptability by any third party. ZKS does not require uninterrupted availability of third-party services; it requires that loss of such services does not transfer decryption authority away from the user or allow a third party to eliminate decryptability as a matter of unilateral control.

Terminological Note: Throughout this document, the phrase "given ciphertext availability" or "assuming ciphertext availability" indicates that the user possesses or can obtain the encrypted data. This assumption isolates the sovereignty question (can the user decrypt?) from the availability question (can the user obtain the ciphertext?).

2.2.7 Cryptographic Blindness

A component is cryptographically blind if it lacks the technical capability to unwrap, derive, decrypt, or otherwise reconstruct decryption-relevant components, regardless of whether it stores ciphertext, wrapped keys, or opaque cryptographic artifacts.

Cryptographic blindness is determined solely by capability, not by data residency, encryption at rest, or policy controls. Cryptographic blindness is not defeated by the ability to delete or corrupt artifacts; it refers specifically to the inability to read or derive plaintext content or keys.

2.2.8 Unilateral Control

The ability of the user to exercise cryptographic and operational authority (e.g., authorizing a device, recovering keys, deleting data) without requiring the discretionary permission, cooperation, or cryptographic participation of a third party, except where the user has explicitly delegated such participation in a manner that remains reversible, i.e. such that the user can unilaterally revoke without requiring third-party cooperation.

2.2.9 Sovereignty Domain Owner

"User" in this standard refers to the Sovereignty Domain Owner (hereafter SDO), the entity with ultimate authority over decryption capability within a sovereignty domain.

Deployment Contexts:

Context	Sovereignty Domain Owner	Individual Role
Consumer	Individual person	User = Owner
Small Business	Business entity or owner	Employees = Authorized Users
Enterprise	Organization	Employees = Authorized Users under Org sovereignty
Regulated	Organization	Org = Owner with compliance obligations

Enterprise Sovereignty Clarification:

In enterprise deployments:

1. The Organization is the Sovereign, not individual employees. Organizational sovereignty means the organization controls master keys and delegation policies.

2. Internal delegation (Section 4.7) operates within organizational sovereignty. The organization may delegate decryption capability to employees, departments, or roles.

3. Enterprise admins act as agents of the Sovereignty Domain Owner. Admin actions are authorized by the organization, not independent of it.

4. Employee departure does not transfer sovereignty. The organization retains control; departing employee access is revoked through normal key rotation or access revocation.

5. The provider remains outside sovereignty regardless of internal delegation structure. ZKS ensures the provider cannot decrypt, whether the sovereign is an individual or organization.

Clarification: ZKS protects the Sovereignty Domain Owner from the provider. It does not prevent the Sovereignty Domain Owner from managing internal access. An organization implementing ZKS can still revoke employee access, enforce retention policies, and respond to internal compliance requirements - these are exercises of organizational sovereignty, not violations of it.

2.2.10 Provider-Side Data Absence (PSDA)

Provider-Side Data Absence (PSDA) is an optional property beyond ZKS requirements. While ZKS prohibits coexistence of ciphertext and key material under provider control, PSDA further restricts providers from holding ciphertext at all.

Relationship to ZKS:

Configuration	ZKS Status	PSDA Status	Notes
Provider holds ciphertext only (no key material)	✅ Compliant	❌ Does not satisfy	Provider is cryptographically blind
Provider holds wrapped keys only (no ciphertext, no unwrapping capability)	✅ Compliant	✅ Satisfies	Provider is cryptographically blind; keys unusable without ciphertext
Provider holds neither ciphertext nor key material	✅ Compliant	✅ Satisfies	Maximum separation (coordination/orchestration only)
Provider holds both ciphertext and key material (or can obtain both)	❌ Non-compliant	❌ Does not satisfy	Coexistence enables decryption

"Provider holds wrapped keys only" refers to scenarios where the provider stores encrypted or wrapped key material but (a) lacks the capability to unwrap or decrypt that material, and (b) holds no user ciphertext. In this configuration, the provider is cryptographically blind as defined in Section 2.2.7: the key material is unusable without both unwrapping capability and the ciphertext it protects. This configuration satisfies PSDA because no user data (ciphertext) resides on provider infrastructure.

When PSDA Applies: PSDA is relevant for architectures where ciphertext is stored on user-controlled infrastructure (local devices, user cloud storage accounts) and the provider operates coordination/key-delivery services only.

Documentation: Systems claiming PSDA SHOULD document this as an additional property beyond ZKS compliance.

2.2.11 Derivation (in the ZKS context)

"Derive" refers to the capability to reconstruct, compute, or obtain decryption-relevant components from materials a third party holds or can access. This includes:

• cryptographic reconstruction from partial key shares or wrapped keys where unwrapping capability is obtainable;
• computation of keys from derivation inputs (salts, seeds, passwords combined with server-held secrets);
• extraction through recovery channels, escrow mechanisms, or administrative backdoors; or
• accumulation of components over time that collectively yield decryption capability.

A system is not ZKS-compliant if any third party can derive the complete set of components required to decrypt, regardless of the complexity or time required for such derivation.

2.3 ZKS Tenets (Normative)

A ZKS-compliant system MUST satisfy the following tenets. Each tenet is both a design requirement and an evaluative criterion.

Tenet 1 - User-Exclusive Decryption Capability

The system MUST ensure that only the SDO can obtain the complete set of components required to decrypt their information. No third party SHALL be technically capable of decryption, nor capable of inducing decryption without user authorization.

Tenet 2 - Cryptographic Non-Custodianship

The system MUST NOT require any third party to hold plaintext decryption keys, derivation secrets, or any equivalent material whose possession-alone or in combination-enables decryption.

Tenet 3 - Separation of Ciphertext, Keys, and Authorization

Ciphertext storage, key custody, and authorization for key release MUST be separated such that no third party can co-locate these functions to reconstruct decryptability.

Tenet 4 - Multi-Intermediary Incapability

The system MUST remain ZKS-compliant even if all intermediaries in the digital supply chain collude. No combination of intermediaries, whether acting independently or in coordination, SHALL be able to obtain the complete set of decryption components.

Tenet 5 - User-Governed Data Topology

The SDO MUST retain authority over where ciphertext resides and how it is replicated or synchronized. The system MUST support user-initiated relocation of ciphertext substrates without requiring provider permission or proprietary tooling that technically restricts migration.

Tenet 6 - Sovereign Device Authorization and Revocation

Only the SDO SHALL have authority to authorize and revoke devices participating in the sovereignty domain. No third party SHALL possess the capability to authorize devices into, or revoke devices from, the user's decryptability domain.

Tenet 7 - Evidentiary Requirement: Verifiable and Falsifiable Sovereignty Claims

ZKS claims MUST be demonstrable through falsifiable evidence. The system MUST support evidence generation sufficient to show that third parties cannot access, derive, revoke, or intercept the complete set of components required to decrypt, as defined in this Standard.

Tenet 8 - Availability Independence: Decryptability Survives Service Loss

Decryptability MUST NOT depend on continued availability of third-party services. Unavailability of provider services (including storage, orchestration, or key delivery services) MAY affect convenience or access to ciphertext, but MUST NOT:

• transfer decryption authority away from the SDO;
• eliminate the SDO's ability to decrypt data they possess; or
• create a condition where the SDO requires third-party cooperation to restore decryptability.

Given ciphertext availability, the SDO MUST be able to decrypt without ongoing third-party participation.

2.4 ZKS Assumptions and Baseline Threat Model (Normative)

A ZKS-compliant system SHALL be evaluated under the following baseline assumptions:

1. Third-party compromise is plausible. The Standard assumes service providers and intermediaries may be compromised, malicious, coerced, or misconfigured.

2. Network paths are hostile. Adversaries may observe, block, replay, and manipulate traffic. A ZKS-compliant system MUST NOT rely on trusted networks.

3. Intermediary collusion is plausible. Multiple intermediaries may cooperate, voluntarily or under compulsion, to reconstruct decryption capability. ZKS compliance requires resistance to such collusion.

4. Endpoint compromise is possible. ZKS does not claim to prevent endpoint compromise. Instead, it constrains what third parties can obtain or do regardless of endpoint state. Additional controls MAY be implemented (e.g., user-controlled key recovery services) to address high-assurance threat models. Note that vendor-initiated endpoint compromise via malicious updates is addressed in Section 5.3.1.

5. Availability failures are expected. Storage providers, key recovery services, and orchestration services may become unavailable or may deny service. ZKS prohibits revocation of decryptability but does not require uninterrupted availability.

Threats and risks are elaborated in Section 5; this section establishes the minimum adversarial baseline required for compliance claims.

2.5 ZKS Compliance Statement (Normative)

A system MAY claim ZKS compliance only if:

• it satisfies the definition in Section 2.1;
• it satisfies all tenets in Section 2.3; and
• it satisfies the conformance requirements and prohibited capability constraints specified in Section 7.4 and Section 8.

A system SHALL NOT claim ZKS compliance if any third party can obtain the complete set of components required to decrypt user information through any combination of:

• service operation,
• recovery or support workflows,
• administrative override capabilities,
• infrastructure control,
• software update mechanisms that could introduce deferred decryption capability,
• legal or policy enforcement mechanisms embedded into the technical design, or
• metadata correlation that enables reconstruction of decryption capability.

"ZKS-compliant" and related claims SHALL be scoped to the evaluated deployment architecture, including all client runtimes, third-party APIs, storage substrates, and external services required for normal operation. A claim that a client application is ZKS-compliant is invalid if the deployed architecture includes backend services that can obtain decryption-relevant components.

2.6 ZKS Compliance Profiles (Normative)

This Standard defines the following compliance profiles to support procurement clarity and deployment-specific requirements. A system that claims a profile MUST satisfy all requirements of that profile and all requirements of ZKS-Core.

2.6.1 ZKS-Core

ZKS-Core defines the minimum requirements for ZKS compliance. A ZKS-Core system MUST:

• satisfy all tenets in Section 2.3;
• ensure no third party can obtain decryption capability (complete component set);
• ensure data topology is user-governed and relocatable;
• ensure revocation of decryptability is not possible by third parties (as defined in Section 2.2.6).
• implement Binary Transparency for client software updates as specified in Section 5.3.1; and
• ensure the update mechanism cannot be exploited for targeted attacks without detection.

2.6.2 ZKS-Enhanced

ZKS-Enhanced strengthens ZKS-Core by adding additional constraints and assurances for higher-risk environments. A ZKS-Enhanced system MUST satisfy all ZKS-Core requirements and additionally MUST:

• provide stronger separation between ciphertext substrates and decryption component handling;
• implement enhanced resistance to metadata correlation;
• provide additional evidence-generation mechanisms (e.g., stronger demonstrability of component separation); and
• constrain any optional high-assurance modes (including user-controlled key recovery services) to preserve ZKS invariants with documented controls.

A ZKS-Enhanced system MUST satisfy Binary Transparency requirements and SHOULD additionally provide reproducible builds as specified in Section 5.3.1.

ZKS-Enhanced requirements are specified in Sections 7 and 8.

2.6.3 ZKS-Enterprise

ZKS-Enterprise applies to organizational deployments requiring stronger operational governance and audit alignment. A ZKS-Enterprise system MUST satisfy all ZKS-Enhanced requirements and additionally MUST:

• provide explicit role and device governance controls without transferring decryptability authority to administrators or providers;
• provide audit evidence sufficient for third-party assessment (without exposing plaintext or decryption capability);
• implement operational controls that preserve sovereignty even in delegated administrative environments;
• provide verifiable compliance artifacts suitable for enterprise procurement and assurance programs; and
• implement update transparency mechanisms (binary transparency logs, multi-party signing, or reproducible builds) as specified in Section 5.3.1.

Constraints: Enterprise governance features MUST NOT empower the service provider to bypass user sovereignty or perform decryption on behalf of the enterprise.

ZKS-Enterprise requirements are specified in Sections 7 and 8.