Paper 020: The ZKOMI Handshake — A Client-Side Authorized Protocol for Health Context Exchange

The fragmentation of health data across institutions creates a recurring cost: patients must repeatedly explain their medical history, providers order duplicate tests, and clinical context is lost at every system boundary. Existing solutions — patient portals, health information exchanges, personal health records — are institution-centric. They allow patients to view their records. They do not, in general, give patients control over what context is shared, with whom, and for how long.

The ZKOMI Handshake is a patient-controlled, privacy-preserving protocol for transferring health context to a provider at the point of care. It is designed to ensure that only the minimum necessary information is shared, that the patient's identity can be protected, and that the clinical data itself is never stored on or transmitted through any server.

Terminology note: This paper describes a protocol that achieves its privacy guarantees through architectural design — client-side encryption, zero server knowledge of clinical data, and ephemeral sessions. It does not implement formal zero-knowledge proof algorithms such as zk-SNARKs or zk-STARKs. We use the phrase "zero server knowledge" as a design goal, not as a claim of cryptographic zero-knowledge. We recognize the importance of terminological precision and aim to be explicit about the distinction throughout.

This paper provides the technical specification of the Handshake protocol. We describe an implementation in development within the Zkomi application. The protocol is functional in prototype form. We invite review, critique, and collaboration from researchers and developers working on health data security, patient-controlled exchange, and privacy-preserving architectures.

The ZKOMI Handshake is a client-driven protocol comprising four phases. This section formalizes the participants, the data model, and the protocol flow.

2.1 Participants and Data Model

Let P be a patient who possesses a private data set D, representing their medical history. D is a vector of clinical data points, where each data point d_i ∈ D is a tuple (type, value, timestamp). The data types are defined by a set T (e.g., conditions, medications, allergies).

Let V be a verifier — a healthcare provider, a pharmacist, a customs official, or an emergency responder — who needs access to a subset of P's health context.

Let S be a selection vector of booleans, where s_i = 1 if the patient has selected data point d_i for inclusion in the Handshake, and s_i = 0 otherwise. The summary M = {d_i ∈ D | s_i = 1} is the subset of data the patient has chosen to share.

The Handshake Mode m ∈ {Emergency, Clinical, Travel, Specialist} is a pre-defined template for S, providing default selections that the patient may modify.

The Anonymous Flag a ∈ {0, 1} controls whether the patient's identifying information (name, date of birth) is included in M.

2.2 Protocol Phases

Phase 1: Setup (Patient-Controlled Data Preparation)

1. The patient P uses the Zkomi application to manage their medical data D. This process occurs entirely on-device, using local storage.
2. The patient selects a Handshake Mode m, which provides a default selection S for the summary. The patient may manually toggle s_i for any data point.
3. The patient sets the Anonymous Flag a according to the context and their comfort.

Phase 2: Generation (Creating the Handshake)

1. Once M and the parameters are finalized, the application generates a unique Session ID, sid.
2. The application generates a random symmetric encryption key k and encrypts M, yielding the encrypted payload E = Enc_k(M).
3. The application constructs a URL containing the Session ID and the encrypted payload. The specific transport mechanism — QR code, NFC, Bluetooth, or direct link sharing — is implementation-dependent. QR is one convenient transport, particularly for in-person clinical encounters, but the protocol is designed to be transport-independent.
4. The encrypted payload E is placed in the URL fragment — the part after the # symbol. The URL fragment is never transmitted to any server. It is only accessible to client-side code running in the recipient's browser.

Phase 3: Presentation (Provider Receiving)

1. The patient shares the Handshake with the provider V via the chosen transport mechanism.
2. The provider's application — a web browser or native application — receives the Session ID and the encrypted payload. The Session ID is used to retrieve a static HTML page from the server. The server receives only the Session ID. It never receives the encrypted payload.
3. The provider's application decrypts the payload using client-side code. The decryption key is embedded in the fragment and never transmitted to the server.
4. The provider's application renders the decrypted summary M for the provider to view. It displays the Handshake expiry time and the session ID.

Phase 4: Verification & Feedback

1. The provider V reviews the summary M. If a = 1, the patient's name is displayed. If a = 0, the provider sees "Anonymous."
2. After the consultation, the provider may optionally indicate whether the Handshake was helpful and add a note. This feedback is stored locally and is never transmitted to any ZKOMI server.

The ZKOMI Handshake achieves its privacy guarantees through architectural design. The key properties are:

Client-Side Key Management. The symmetric encryption key k is generated by the patient's application and is never transmitted to or stored on any server. Encryption and decryption occur entirely on the client side.

Zero Server Knowledge of Clinical Data. The server plays no role in storing, processing, or accessing clinical data. It serves only a static HTML page. The server has no knowledge of the encryption key k, the summary M, or any patient data. The encrypted payload E is placed in the URL fragment, which is never transmitted to the server.

Ephemeral Sessions. Each Handshake is a distinct session with its own sid, key k, and payload. The session expires automatically after a user-defined duration. Once expired, the URL is no longer functional.

Verifiable Authenticity. The provider can verify that the payload originated from a ZKOMI user by successfully decrypting it. The decryption itself serves as verification that the payload was encrypted with a key known only to the patient's application.

The current implementation achieves its privacy properties through architectural design. It does not implement formal zero-knowledge proof algorithms such as zk-SNARKs or zk-STARKs.

The distinction is important. Formal ZK-proofs allow one party to prove a statement is true without revealing the underlying information — for example, proving that a patient is over 18 without revealing their birthdate. The Handshake does not currently provide this capability. It protects data through client-side encryption and zero server knowledge of clinical data, not through cryptographic proofs of arbitrary statements.

Future work may explore integrating formal ZK-proof mechanisms for enhanced verifiability. This could enable use cases such as proving eligibility for a clinical trial without revealing the underlying condition, or proving vaccination status without revealing the date or location.

The Handshake protocol is implemented in prototype form within the Zkomi application. The Setup, Generation, and Presentation phases are functional. The Verification and feedback mechanisms are in development.

Device recovery and data persistence: The current prototype stores data locally on a single device. If the device is lost, fails, or is upgraded, the user's health data may be lost. We are actively exploring encrypted backup and recovery mechanisms that would allow users to securely transfer their data between devices without introducing server-side storage or compromising the privacy properties of the system. This is an open engineering challenge.

The protocol is not yet deployed in a production environment. We are actively seeking review and critique from researchers and developers with expertise in health data security, applied cryptography, and patient-centered design.

This paper describes a protocol in development. Several questions remain open.

What is the optimal encryption scheme for the payload, balancing security with performance on mobile devices? How should the protocol adapt for remote consultations where QR codes cannot be physically shared? What additional metadata should be included to enable verification by recipients with no prior relationship to the user? How should token revocation be handled after the token has been released and potentially stored by the recipient? What is the appropriate mechanism for auditing Handshake usage without compromising privacy?

We do not have definitive answers. We invite collaboration.

The ZKOMI Handshake is a patient-controlled, privacy-preserving protocol for transferring health context to a provider at the point of care. It achieves its privacy properties through architectural design — client-side encryption, zero server knowledge of clinical data, and ephemeral sessions.

It is a work in progress. We offer this specification as a starting point for discussion, and we invite researchers, developers, and clinicians to critique, extend, and improve upon it.

Published: July 2026
Archived: Internet Archive
Repository: GitHub
Hash: [SHA-256 — upon final publication]

Key Sources:

• Go, E.M. & Kim, S.R. (2025). Blockchain-Based Zero-Knowledge Proof Protocol For Privacy-Preserving Healthcare Data Sharing. Journal of Technology Informatics and Engineering, 4(1).
• Zkomi Research Team. (2026). Paper 004: The Zero-Knowledge Architecture. The Continuity Project.
• Zkomi Research Team. (2026). Paper 016: Memory Without Custody. The Continuity Project.
• Zkomi Research Team. (2026). Paper 019: Health Context Tokens — A User-Controlled Model for Selective Health Context Sharing. The Continuity Project.