var img = document.createElement('img'); img.src = "https://analytics.zks-standard.org/matomo.php?idsite=1&rec=1&url=https://zks-standard.org" + location.pathname; img.style = "border:0"; img.alt = "tracker"; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(img,s);
Skip to main content
Version: 1.0-RC2 / RELEASE CANDIDATE

Appendix C - Canonical Reference Diagrams (Normative)

These diagrams define the minimum architectural semantics required to reason about ZKS compliance. Any implementation claiming ZKS compliance SHALL be mappable to these diagrams without ambiguity.

Diagram 1 - ZKS Logical Component Model & Sovereignty Boundary​

Purpose​

This diagram defines:

  • the primary sovereignty boundary,
  • the location of decryptability,
  • and the separation between user-controlled and third-party components.

This is the single most important diagram in the entire standard.

Diagram 1A - Reference Diagram (Normative)​

ZKS logical component model: the Client Sovereignty Domain containing application logic, cryptographic engine and local key storage, separated by the sovereignty boundary from the cryptographically blind external CSS, KCS/UKRS and OP services

Normative Interpretation​

  1. All decryption occurs exclusively inside the CSD.
  2. The sovereignty boundary separates decryptability from all third parties.
  3. CSS, OP, KCS, and IRM are explicitly outside the sovereignty boundary.
  4. No component outside the boundary may:
    • reconstruct,
    • derive,
    • obtain,
    • intercept,
    • or revoke decryptability (given ciphertext availability).
  5. Optional components (KCS, IRM) do not change the boundary.

Any system that requires decryptability to cross this boundary is not ZKS-compliant.

Diagram 2 - ZKS Planes and Channels Separation Model​

Purpose​

This diagram shows how planes and channels are separated so that no intermediary can co-locate:

  • ciphertext,
  • unwrapping capability,
  • and authorization.

This diagram directly supports:

  • Tenet 3 (Separation),
  • Tenet 4 (Multi-Intermediary Incapability),
  • Section 3.3 (Planes),
  • and Section 3.6 (Metadata minimization).

Diagram 2A - Reference Diagram (Normative)​

ZKS plane separation model: Data, Key, Control and OOB planes meeting only inside the CSD, their external counterparts with operator visibility, and the per-entity coexistence rule with the compliant split-operator configuration

Normative Interpretation​

  1. Vertical Separation: Planes are logically independent. The Data Plane MUST NOT intersect with the Key Plane outside the CSD.
  2. No Cross-Talk: The Orchestration Plane (OP) MUST NOT process ciphertext from the Data Plane or keys from the Key Plane.
  3. The OOB Plane: Is independent of the Data Plane and strengthens user control.
  4. A system where any single intermediary can observe Ciphertext + Keys is not ZKS-compliant.

Diagram 3 - Prohibited Architectures (Informative but Critical)​

These diagrams are useful in audits and competitor discussions.

Diagram 3A - Anti-Pattern: Centralized Provider Control​

Anti-pattern: a single cloud service holding ciphertext, keys and authorization together, so one entity possesses the complete decryption set

Diagram 3B - Anti-Pattern: Provider-Held Recovery Keys​

Anti-pattern: provider-held recovery keys feeding a support-override workflow, giving the provider decryptability through its own recovery flow