4. Deployment Models and Use Cases (Informative with Normative Invariants)

4.1 Purpose and Reader Guidance

This section describes representative deployment models and use cases for ZKS architectures. The scenarios are informative in that they do not prescribe a single implementation. However, each scenario contains normative invariants-requirements that MUST remain satisfied for a deployment to be considered ZKS-compliant.

All deployments described herein SHALL be interpreted in accordance with:

• the ZKS definition and operative semantics in Section 2;
• the logical components, sovereignty boundary, and plane separation model in Section 3; and
• the canonical reference diagrams (Appendix C).

Where a scenario introduces an optional service (e.g., external ciphertext substrates or User-Controlled Key Recovery Services), the scenario remains ZKS-compliant only if no third party can reconstruct, derive, or obtain the complete set of components required to decrypt the user's information (given ciphertext availability), and only if third parties cannot revoke decryptability as defined in Section 2.2.6.

4.2 Common Normative Invariants Across All Deployment Models

The following invariants apply to all deployments, regardless of topology or service composition:

INV-1 (Decryptability locality). Decryption MUST occur only within the Client Sovereignty Domain (CSD). No third-party component SHALL be able to cause or perform decryption outside the CSD.

INV-2 (Key possession constraint). No third party - including any service provider or intermediary - SHALL possess, nor be able to reconstruct, derive, or obtain, the complete set of components required to decrypt user information (given ciphertext availability).

INV-3 (Plane separation). The Data Plane, Key Plane, Control Plane, and OOB Plane MUST remain separable such that no intermediary can co-locate ciphertext, unwrapping capability, and authorization sufficient to produce decryptability.

INV-4 (No third-party revocation of decryptability). No third party SHALL have the technical capability to revoke decryptability for an authorized user. Availability failures MAY occur but SHALL NOT constitute a ZKS violation unless they enable revocation of decryptability.

INV-5 (User-governed topology). The user SHALL retain topological control over ciphertext location and replication. A deployment SHALL NOT impose provider-controlled topology that prevents user relocation of ciphertext substrates.

INV-6 (Metadata minimization). External components (CSS, OP, KCS, IRM when external) MUST adhere to the metadata minimization requirements in Section 3.6 and SHALL NOT accumulate metadata sufficient to reconstruct decryption workflows or indirectly assemble decryptability.

These invariants serve as the baseline for the scenario-specific requirements below.

4.3 Scenario Template (Applied to Each Deployment)

To ensure consistent evaluation and auditability, each scenario is specified using the following subsections:

• Architecture Summary
• Applicable Components and Planes
• ZKS Compliance Notes
• Normative Invariants (Scenario-Specific)
• Operational Considerations
• Common Failure Modes (Non-Exhaustive)

4.4 Single-Device, Fully Local Deployment

4.4.1 Architecture Summary

In this deployment, all user information, ciphertext, and decryption-relevant components reside on a single user-controlled device within the CSD. There is no external CSS, OP, or KCS. This model is the simplest instantiation of ZKS and is often applicable to personal vaults, isolated workstations, air-gapped environments, or single-device mobile usage.

4.4.2 Applicable Components and Planes

• CSD: present (includes cryptographic engine: TEE/HSM/soft-token)
• CSS: local only
• OP: absent
• KCS: absent
• IRM: local only
• Planes:
  • Data Plane: local ciphertext storage
  • Key Plane: local key generation and storage
  • Control Plane: local coordination only
  • OOB Plane: optional for high-risk actions (local only or user-controlled)

4.4.3 ZKS Compliance Notes

This deployment typically satisfies ZKS by construction, provided that the platform does not introduce external recovery or support flows that grant third parties decryptability (e.g., vendor-hosted key backup enabled by default).

4.4.4 Normative Invariants (Scenario-Specific)

INV-4.4-A (No implicit external backup). The system MUST NOT enable third-party backup of decryption-relevant components by default.

INV-4.4-B (Local recovery constraints). Any recovery mechanism MUST remain within the user's sovereignty domain; if a third-party recovery mechanism is introduced, it SHALL be assessed under the User-Controlled Key Recovery Service constraints in Section 4.10.

4.4.5 Operational Considerations

• Device compromise is the primary threat; ZKS does not eliminate endpoint compromise but constrains third-party capability.
• The user SHOULD maintain a user-governed backup strategy if availability and continuity are requirements.

4.4.6 Common Failure Modes

• Loss of device with no recovery path (availability failure, not a sovereignty failure).
• Vendor support reset that regenerates or restores keys (sovereignty failure).

4.5 Multi-Device Peer Synchronization

4.5.1 Architecture Summary

In this deployment, a user maintains multiple devices within the CSD (e.g., desktop + laptop + mobile). Ciphertext and selected metadata are synchronized among devices. An Orchestration Plane (OP) MAY be used for connectivity coordination, but it MUST remain blind to decryptability and key material.

Sync may be continuous or opportunistic and may occur through direct device-to-device communication or via ciphertext substrates (Section 4.6).

4.5.2 Applicable Components and Planes

• CSD: present on each device
• OP: optional (coordination only)
• CSS: optional (see Section 4.6)
• KCS: optional (delivery only or recovery; see Section 4.10)
• Planes:
  • Data Plane: ciphertext replication between devices (direct and/or via CSS)
  • Control Plane: device roster and routing, sync scheduling
  • Key Plane: per-device key custody; wrapped key packets for authorized devices
  • OOB Plane: optional device enrollment approval or key release approval

4.5.3 ZKS Compliance Notes

The primary ZKS risk in multi-device deployments is co-location: orchestration mechanisms must not become a collection point where ciphertext identity, wrapped keys, and authorization artifacts can be correlated to yield decryptability.

Additionally, sync architectures MUST preserve user-governed topology and must not require centralized custody of key material.

4.5.4 Normative Invariants (Scenario-Specific)

INV-4.5-A (Device enrollment sovereignty). Device authorization MUST require explicit user approval and SHALL NOT be achievable solely through provider-side administrative action.

INV-4.5-B (Key distribution constraint). Key distribution for new authorized devices MUST ensure that no third party can reconstruct, derive, or obtain decryptability through the distribution workflow. Key distribution is typically made safe by wrapping new device keys with existing device keys and requiring OOB confirmation for new device enrollment.

INV-4.5-C (OP key-plane blindness). Where an OP is used, it MUST be blind and stateless with respect to the Key Plane and MUST NOT log or retain key material or decryption-enabling authorization artifacts.

4.5.5 Operational Considerations

• Users SHOULD be able to remove a device from their sovereignty domain unilaterally (sovereign device revocation).
• TEEs and secure elements are particularly relevant for mobile devices to protect keys at rest and during use.

4.5.6 Common Failure Modes

• Provider-managed "device reset" that reissues keys (sovereignty failure).
• OP logging wrapped key packets with correlatable identifiers (sovereignty failure by correlation risk).

4.6 External Ciphertext Substrate (Consumer Cloud / NAS)

4.6.1 Architecture Summary

In this deployment, ciphertext is stored on an external CSS operated by a third party (e.g., consumer cloud drive, object storage, or NAS substrate). The external CSS functions as a storage substrate and optional replication point. Decryptability remains exclusively within the CSD.

This model supports user-governed topological flexibility and portability: the ciphertext substrate can be relocated without changing decryption authority.

4.6.2 Applicable Components and Planes

• CSS: external third-party storage
• CSD: present on one or more devices
• OP: optional
• KCS: optional (delivery/recovery)
• Planes:
  • Data Plane: ciphertext at rest and in transit to CSS
  • Control Plane: optional orchestration for multi-device coordination
  • Key Plane: keys remain under user control; never co-located with decryptability externally

4.6.3 ZKS Compliance Notes

The CSS operator may deny service or delete the ciphertext blob (availability failure). This is not a ZKS violation unless the architecture makes the CSS operator capable of revoking decryptability, which is prohibited.

This deployment is a primary test for the standard's distinction between:

• ciphertext availability, and
• revocation of decryptability.

4.6.4 Normative Invariants (Scenario-Specific)

INV-4.6-A (No key possession by CSS). The CSS operator MUST NOT possess decryption keys, key derivation secrets, or unwrapping capability.

INV-4.6-B (Relocation sovereignty). The user MUST be able to relocate ciphertext substrates without provider permission or proprietary constraints that prevent migration.

INV-4.6-C (No reliance on CSS for decryptability). A user's ability to decrypt their information (given ciphertext availability) MUST NOT depend on the CSS operator.

4.6.5 Operational Considerations

• Users SHOULD maintain redundancy across devices if CSS availability is not guaranteed.
• Users SHOULD be able to use multiple CSS providers simultaneously without altering key custody.
• Split Topology Recommendation: ZKS compliance is significantly strengthened when the CSS operator (Storage) and the Orchestration Plane operator (Signaling) are distinct legal and technical entities. This "Split Topology" ensures that no single provider can correlate operational metadata (from the OP) with ciphertext traffic patterns (at the CSS), thereby enforcing Tenet 4 (Multi-Intermediary Incapability) by architecture.

4.6.6 Common Failure Modes

• Provider-side file conversion or server-side processing of ciphertext (sovereignty failure if it requires plaintext).
• CSS-driven key escrow integration (sovereignty failure).

4.7 Enterprise Synchronization Hub Deployment

4.7.1 Architecture Summary

In this deployment, ciphertext synchronization may be coordinated through an enterprise-controlled infrastructure component (e.g., internal NAS, synchronization hub, or controlled relay infrastructure). The enterprise is the "user" for sovereignty purposes, and decryptability remains within the enterprise sovereignty domain (CSD across managed endpoints and enterprise-controlled secure modules).

The enterprise may enforce operational governance (role-based device authorization, compliance policies) provided that such governance does not transfer decryptability capability or key possession to a third-party provider.

4.7.2 Applicable Components and Planes

• CSD: enterprise-managed devices and user endpoints
• CSS: enterprise-controlled (NAS) and/or external (cloud)
• OP: enterprise-controlled coordination services
• KCS: optional enterprise-controlled KCS or user-controlled services
• IRM: enterprise identity and recovery systems (internal governance)

4.7.3 ZKS Compliance Notes

Enterprise deployments introduce delegation. ZKS compliance permits delegation within the user's sovereignty domain (the organization) but prohibits delegation to the vendor or external intermediaries in a manner that grants them decryption capability or key possession.

Note: Intra-organizational sovereignty (individual employee sovereignty vs. enterprise sovereignty) is outside the scope of this Standard. ZKS focuses on preventing vendor/provider access.

4.7.4 Normative Invariants (Scenario-Specific)

INV-4.7-A (Internal delegation permitted). The organization MAY delegate operational authority to internal administrators (e.g., CISO, key custodians) without breaking ZKS, provided that delegation remains within the organization's sovereignty domain.

INV-4.7-B (Vendor delegation prohibited). The vendor or external intermediaries MUST NOT be granted decryption capability or key material possession through enterprise governance workflows.

INV-4.7-C (Enterprise IRM constraint). Enterprise recovery mechanisms MUST NOT introduce provider-side decryptability or provider-controlled revocation of decryptability.

4.7.5 Operational Considerations

• Enterprise deployments SHOULD document sovereignty boundaries explicitly for audit.
• TEEs and device attestation MAY be used to strengthen endpoint assurance.

4.7.6 Common Failure Modes

• Vendor-managed break-glass accounts capable of key release (sovereignty failure).
• Centralized enterprise KMS where the KMS operator is a third-party cloud provider possessing keys (sovereignty failure under "possession" semantics).

4.8 Cross-Account and External Collaboration

4.8.1 Architecture Summary

This deployment enables collaboration across distinct user sovereignty domains (e.g., two organizations, or an organization and an external client). Collaboration may be achieved via:

• direct device-to-device encrypted transfer; or
• shared ciphertext repositories with controlled key distribution.

The primary ZKS challenge is preserving sovereignty while supporting sharing, synchronization, and permissions.

4.8.2 Applicable Components and Planes

• Multiple CSDs (distinct sovereignty domains)
• Optional OP for coordination
• Optional shared CSS for ciphertext replication
• Key distribution governed by each domain's Key Plane and APP

4.8.3 ZKS Compliance Notes

ZKS does not prohibit cross-domain sharing; it requires that sharing does not create a third-party decryptability point and that each domain's key possession remains sovereign.

4.8.4 Normative Invariants (Scenario-Specific)

INV-4.8-A (No transitive decryptability). Sharing MUST NOT utilize unblinded "re-encryption proxies," server-side key wrapping, or ephemeral decryption intermediaries that grant a third party temporary access to the plaintext or the unwrapped key during the sharing workflow, however brief. Zero-Knowledge Proxy Re-Encryption schemes that demonstrably preserve cryptographic blindness are permitted.

PRE Security Requirements. Proxy Re-Encryption (PRE) schemes used in ZKS-compliant systems MUST satisfy:

1. Unidirectionality: The re-encryption key enables transformation A→B only, not B→A.
2. Non-Interactivity: Re-encryption does not require real-time participation of the delegator.
3. Proxy Blindness: The proxy cannot derive the private key of either delegator or delegatee from the re-encryption key.
4. Collusion Resistance: Collusion between proxy and delegatee does not reveal delegator's private key.
5. Non-Transitivity (RECOMMENDED): Re-encryption from A→B and B→C should not enable the proxy to derive A→C transformation.

PRE schemes that do not satisfy properties 1-4 MUST NOT be used for Key Plane operations.

INV-4.8-B (Explicit governance). Cross-domain synchronization MUST be explicitly authorized and MUST maintain independent sovereignty boundaries for each domain unless the domains are formally merged under a single user governance model.

INV-4.8-C (Permission enforcement locality). Permission enforcement SHOULD occur within the CSD; external enforcement MUST NOT require third-party decryptability.

4.8.5 Operational Considerations

• Shared content may create metadata correlation risk; implementers SHOULD use opaque identifiers and minimize exposure.
• Auditable evidence should demonstrate that third parties cannot reconstruct decryptability by observing shared workflows.

4.8.6 Common Failure Modes

• Shared repository requires provider-side key distribution or processing (sovereignty failure).
• Collaboration implemented through provider-hosted "preview" services (sovereignty failure).

4.9 Offline-First and Intermittent Connectivity

4.9.1 Architecture Summary

This deployment assumes devices may be offline for extended periods and synchronize opportunistically. The architecture may use:

• direct peer sync when available;
• asynchronous ciphertext substrates; and/or
• optional key delivery services for offline device enablement.

ZKS compliance requires that offline enablement not introduce third-party key custody that permits revocation of decryptability or reconstructability.

4.9.2 Applicable Components and Planes

• CSD on each device
• Optional OP for routing and scheduling
• Optional CSS for ciphertext buffering
• Optional KCS for delivery (not recovery unless explicitly in Section 4.10)

4.9.3 Normative Invariants (Scenario-Specific)

INV-4.9-A (Asynchronous delivery constraint). Asynchronous delivery MUST NOT use the OP for payload storage. The OP handles only delivery notifications and coordination. Storage of ciphertext and wrapped keys for asynchronous delivery MUST occur in components designated for that purpose (e.g., CSS, KCS), which MUST be blind to unwrapping capability.

INV-4.9-B (No offline hostage condition). Offline access to previously decrypted content MUST not depend on third-party key release.

INV-4.9-C (Recovery semantics). Offline recovery flows MUST not introduce provider-side decryptability.

4.9.4 Operational Considerations

• Systems SHOULD provide clear evidence of what is available offline and what requires synchronization.
• Local caches are high-value targets; TEEs may reduce risk.

4.9.5 Common Failure Modes

• KCS becomes required for everyday access (sovereignty erosion).
• OP logs correlate key packets and ciphertext identifiers (sovereignty failure by inference risk).

4.10 Key Separation Mode: User-Controlled Key Recovery Services

4.10.1 Architecture Summary

This deployment introduces an optional key separation mode in which users deliberately separate decryption-relevant components (e.g., item keys or wrapped item keys) from endpoints in order to mitigate threats such as ring-0 compromise or forensic extraction from a compromised device.

A User-Controlled Key Recovery Service (UKRS) stores wrapped key packets that require explicit user authorization and, where appropriate, OOB approval to release. The UKRS is outside the sovereignty boundary and must remain incapable of reconstructing decryptability.

4.10.2 Applicable Components and Planes

• CSD on endpoints
• Optional UKRS (as a constrained KCS role)
• OOB Plane for secondary authorization
• CSS for ciphertext storage (local or external)
• OP optional for orchestration, strictly blind to Key Plane

4.10.3 ZKS Compliance Notes

Key separation modes are frequently mischaracterized as "key escrow." ZKS permits user-controlled key recovery only if it does not transfer decryption capability or key material possession to a third party and does not create a vendor-controlled revocation mechanism.

The UKRS MAY deny service (availability failure), but the architecture MUST preserve a sovereign pathway for the user to restore decryptability without provider discretion, consistent with Section 3.5.3.

4.10.4 Normative Invariants (Scenario-Specific)

INV-4.10-A (User initiation and reversibility). Key recovery / key separation MUST be explicitly user-initiated and MUST be reversible under user control.

INV-4.10-B (No plaintext key possession). The UKRS MUST NOT possess plaintext keys, nor possess unwrapping capability.

INV-4.10-C (Explicit authorization for release). Release MUST require explicit user authorization and SHOULD require OOB confirmation for high-risk operations.

INV-4.10-D (No provider revocation of decryptability). The UKRS operator MUST NOT be able to revoke decryptability for an authorized user (given ciphertext availability). A denial of service is permissible only if the user retains a sovereign restoration pathway.

INV-4.10-E (Evidence requirements). ZKS claims in key separation mode MUST be supported by evidence that demonstrates:

• UKRS blindness to unwrapping capability,
• OP blindness to Key Plane,
• and absence of provider override workflows.

4.10.5 Operational Considerations

• Sovereign Restoration Requirement: To satisfy INV-4.10-D (No provider revocation), systems utilizing a UKRS MUST provide a secondary, user-held recovery artifact (e.g., a mnemonic phrase, a local file backup, or a hardware token) that functions independently of the UKRS. A system that relies solely on the UKRS for recovery is not ZKS-compliant, as the provider's refusal of service would constitute a revocation of decryptability.
• Recovery artifacts SHOULD be passphrase-protected or otherwise secured against casual theft.
• This mode SHOULD be scoped to specific data classes (e.g., "locked items") rather than global defaults.
• Key-lock states SHOULD be explicit and auditable within the CSD.
• OOB approval mechanisms MUST be independent of the primary device to provide meaningful assurance. OOB channels operated by the same provider as the UKRS (e.g., provider-operated authenticator app) reduce independence and SHOULD be avoided.

4.10.6 Common Failure Modes

• UKRS becomes the sole repository of keys with no user-controlled fallback (sovereignty failure).
• Provider support override capable of releasing keys (sovereignty failure).
• UKRS correlates identity and item semantics beyond minimum operational metadata (privacy and sovereignty erosion).
• OOB channel controlled by the same provider as the UKRS (reduced independence).