A Blueprint for Patient-Held Medical Credentials:Zero-Knowledge Proofs Anchored in Hardware
Research CompetitionWhy Zero-Knowledge Selective Disclosure Belongs in Hardware, Not Just an App
Think about two ways to prove you are vaccinated. In the first, you show a certificate containing your name, date of birth, and vaccination details, even when the verifier only needs a yes or no answer. In the second, you show proof that you meet the requirement without revealing the personal information behind it.
Many digital health credentials in use today, including the EU’s own COVID certificate, works like the first option. This is extremely fascinating, because the cryptography for the second option has been around for two decades, and it’s already been deployed at national scale. I use that deployment as evidence for a specific recommendation. New medical credential systems should be built on zero knowledge selective disclosure, with the patient’s credential secret held in dedicated hardware instead of inside a phone app. The cryptography has already shipped to millions of people and the hardware custody side has also already been demonstrated separately. What’s missing is a system that puts the two together and allows for proper scaling. This paper lays out that architecture and argues it’s a better default for medical data than what’s standard right now.
1. Introduction
Almost every health credential is answering a yes or no question. Vaccinated or not, tested or not, eligible or not. But almost all of them answer that question by handing over an entire document or groups of documents. A vaccination card, a lab result PDF, a QR code that unpacks into your full name, date of birth, and immunization history. Whoever needs to check the yes/no fact ends up holding all of it, whether they need it or not. This paper argues that default is wrong, proposes a specific alternative, and backs that proposal with evidence instead of speculation.
The EU Digital COVID Certificate (DCC), the standard used across the European Union starting in 2021, is a good example of the default I’m arguing against. It’s a digitally signed data structure that, once scanned, discloses the holder’s full name, date of birth, and vaccine or test details in the clear (Halpin, 2022). Halpin frames this as a tension between two things a credential system is supposed to have at once: unforgeability, nobody can fake a valid certificate and privacy, verifying a certificate doesn’t leak more than the fact being checked. His argument is that the DCC resolves that tension in favor of unforgeability, by design. A bar checking vaccination status, a border agent, an employer: they all see the same full record a hospital would.
The recommendation in this paper rests on two pieces of evidence. First, zero-knowledge selective disclosure for exactly this kind of credential has already been built and deployed at national scale, not just proposed on paper. The Netherlands, while building its own COVID pass, ended up shipping a zero-knowledge credential right alongside the fully disclosing DCC, for the same underlying fact, to the same population. Second, the other piece of the architecture I’m proposing, storing the credential’s secret key in tamper resistant hardware instead of a phone app, has also already been shown to work with the exact scheme the Dutch system used.
2. Background and Methodology
2.1 What is “Zero-Knowledge Selective Disclosure”?
Strip away the cryptography and a selective disclosure credential is just a signed set of attributes: name, birth date, vaccine, dose count, issuing authority. The holder decides at presentation time which attributes to reveal, and can prove the revealed ones are part of a validly signed set without revealing the rest. The verifier learns “this signed credential says dose count is at least 2” and nothing else about the other attributes on it.
There are two fundamental properties that are crucial to understanding this model. The first is selective disclosure: the ability to reveal a subset of attributes, or a predicate over them like “age over 18” or “dose count ≥ 2,” while cryptographically proving the rest exist and are validly signed, without ever revealing their actual values. The second is unlinkability: two different presentations of the same credential can’t be correlated with each other by an observer, even a colluding one, unless the holder chooses to reveal something that ties them together. Without unlinkability, selective disclosure only hides content on any single scan. It doesn’t stop a chain of scans from getting linked into a movement profile, which is the whole point of the second property.
The specific construction behind this paper’s case study is built on Camenisch-Lysyanskaya (CL) signatures, a signature scheme designed to support both properties, most widely deployed through the Idemix (Identity Mixer) protocol and its open-source descendant IRMA (I Reveal My Attributes, later rebranded Yivi). CL/Idemix credentials also have a documented hardware path. Vullers and Alpár (2013) built an efficient implementation of Idemix selective disclosure running directly on a smart card, meaning the signing key never has to leave a hardware boundary to produce a valid, unlinkable proof.
2.2 Methodology
This paper is a literature and primary-source review. The central claims rest on the Dutch Ministry of Health’s published technical documentation for the CoronaCheck system, specifically the Security Architecture document in the minvws/nl-covid19-coronacheck-app-coordination repository, and the production Idemix/CL implementation in minvws/nl-covid19-coronacheck-idemix. Both are maintained by the government body that built the system.
I also draw on independent academic analysis of the EU DCC’s privacy properties (Halpin, 2022) and of alternative privacy-preserving constructions for the same EU certificate standard (Dzurenda et al., 2023).
Finally, I use the foundational Idemix hardware-implementation literature (Vullers & Alpár, 2013) to support the claim that CL-based selective disclosure has a real, demonstrated hardware-anchored deployment path. This comes back in the Ledger Lens.
Where sources disagree, or where public reporting has been loose with the technical claim, I defer to the primary government documentation over secondary summaries, and I say so rather than picking whichever claim happens to be more convenient.
3. Case Study: EU Digital COVID Certificate
Between 2021 and 2022, a person in the Netherlands who wanted to prove their vaccination status could end up holding two different QR codes for the same underlying medical fact, generated by the same app, for two different audiences.
The EU-facing certificate (DCC). For international travel, the Dutch backend issued a standard EU Digital COVID Certificate: a certificate signed under the national CSCA-Health public key infrastructure, following the shared EU technical spec. Scanning it discloses the holder’s name, date of birth, and the specific vaccine, test, or recovery data in full (minvws, Security Architecture, n.d.). This isn’t a flaw specific to the Dutch implementation. It’s the EU standard working exactly as designed, and it’s the standard Halpin (2022) critiques directly: unforgeable, but not privacy-preserving, because the two properties were never built to coexist in that spec.
The domestic certificate (CTB, coronatoegangsbewijs, Dutch for “corona admission pass”). For domestic settings like festivals, restaurants, and indoor venues, the same backend issued a separately designed credential using CL signatures within the Idemix protocol. Per the same architecture documentation, this credential was built specifically for unlinkable presentation. The QR code refreshes roughly every 30 seconds, and each presentation yields a different signature over the same underlying attested facts. Each presentation generates a fresh proof over the same underlying attributes, preventing the proof itself from serving as a stable identifier across scans. On verification, the scanning app shows only the initials of the holder’s name and the day and month of birth. That’s the minimum a human verifier actually needs to match the person in front of them to the credential.
Both credentials came from the same source of truth, the same government, the same population, encoding the same fact during the same period. The only thing that changed was the disclosure design. One revealed everything on every scan and could, in theory, be used to build a profile of the holder by any verifier or group of verifiers who bothered to log what they saw. The other was built specifically to resist that.
The domestic CTB shows that zero knowledge credentials can work outside a research setting. It was deployed nationwide despite legacy verifiers, low-end phones, offline scanning, non-technical users, and a compressed timeline during a public health emergency.
It turns out that feasibility was not the main issue. The difference came down to the intended audience and the standard each credential had to follow. The DCC had to interoperate with a European specification that other member states also implement, and that spec doesn’t build in selective disclosure. The domestic credential had no such external interoperability requirement, so the team was free to choose the stronger design. So, existing standards determine which privacy protections make it into practice. When a shared specification does not support selective disclosure, interoperable credentials default to revealing more information regardless of what the underlying cryptography can support.
| EU DCC | Domestic CTB | |
|---|---|---|
| Cryptographic scheme | Standard certificate signing (national CSCA-Health PKI) | Camenisch-Lysyanskaya signatures via Idemix |
| Fields disclosed on scan | Full name, exact DOB, vaccine/test/recovery details | Initials only, day/month of birth |
| Unlinkable across scans | No | Yes, QR regenerates roughly every 30 seconds |
| Interoperability requirement | Shared EU-wide specification | None (domestic-only) |
| Selective disclosure by design | No | Yes |
4. Not a One-Off: The Standards Layer Is Catching Up
The case study above leads to a very specific claim. Technological capabilities are not an issue. The EU DCC used full disclosure because the shared European standard did not support selective disclosure, even though the necessary cryptography was already available. This tells us that a solution is not a better app or circuit, it’s a standard that other issuers and verifiers can build around.
In April 2025, the W3C published a Candidate Recommendation Draft of its Data Integrity BBS Cryptosuite, which defines how BBS signatures can support selective disclosure and unlinkable proofs. It’s a different cryptographic construction from CL/Idemix, but aimed at the same properties. This included selective disclosure and unlinkable proofs, built directly into the general purpose Verifiable Credentials data model instead of a national system (W3C, 2025). CoronaCheck’s domestic credential required a government to build and run its own Idemix stack from scratch. A BBS+-based credential is meant to be issued, held, and verified with off-the-shelf, standards-compliant wallets and libraries, which was the clear gap in the interoperability layer of the DCC solution.
Health specific versions of this pattern are now an active research area. Recent work has proposed zero knowledge anonymous patient authentication that works across both public and private blockchains (ScienceDirect, 2025). This work does not have CoronaCheck’s scale or track record yet, and that’s a big limitation. However, they place the 2021 Dutch deployment within a broader shift toward privacy-preserving health credentials and show how far ahead of the field it was at the time.
5. What This Case Study Doesn’t Settle
The domestic CoronaCheck credential also came with meaningful costs. Those costs matter because any healthcare system adopting the same approach would face similar decisions around revocation, recovery, performance, and privacy.
Revocation becomes more complicated when presentations are unlinkable. A standard certificate can be revoked by adding its serial number to a blocklist. An unlinkable credential has no stable identifier that can be blocked without making future presentations easier to connect. CoronaCheck addressed this by issuing credentials with short validity periods and refreshing them frequently. This worked for the domestic pass, although it leaves general revocation as an open engineering problem.
Recovery creates another challenge. If a device holding the credential’s secret key is lost, the patient needs a secure way to enroll again. That process may require the issuer to verify the patient’s identity a second time, adding operational overhead and creating another point where personal information must be collected.
Generating a selective disclosure proof also requires more client-side computation than presenting a standard signed certificate. During the CoronaCheck rollout, this raised practical concerns for older phones and lower-end devices. Similar performance constraints would need to be tested before deploying the system across a large and diverse patient population.
The privacy benefits also have a defined boundary. Selective disclosure limits the information revealed through the credential itself. Network metadata, application telemetry, and device fingerprinting could still connect separate interactions. Protecting the credential layer therefore reduces one source of exposure while leaving other forms of tracking to be addressed elsewhere in the system.
CoronaCheck shows that these tradeoffs can be managed in a national deployment. The Dutch team accepted them for the domestic credential because its design was not restricted by an external interoperability standard. This decision suggests that implementation costs alone do not explain why selective disclosure remains uncommon. Standards determine whether engineering teams have room to make those tradeoffs in the first place.
A Proposed Architecture for Hardware Anchored Medical Credentials
CoronaCheck demonstrated that selective disclosure could work at a national scale while keeping the credential’s secret key inside a phone application. This choice placed the key on a general purpose device that runs many applications and receives frequent software updates. Each of those components expands the number of ways the key could be exposed and potentially open doors to further issues and breaches down the line.
Ledger’s broader position on self custody offers an interesting way to examine this design choice. Sensitive keys are safer when they remain inside hardware built for a hyper-specific purpose. A payment key and a medical credential key authorize different actions, but compromising either one allows another person to act on the owner’s behalf. For a medical credential, that could mean presenting private health information or falsely proving eligibility for care. This section applies the principle of hardware anchored trust to that risk.
There is already evidence that this approach can work. Vullers and Alpár (2013) implemented Idemix selective disclosure on a smart card, showing that a constrained, tamper resistant device can generate these proofs. Smart cards use the same general class of secure hardware found in modern hardware wallets and NFC technology. Their work provides a foundation for moving medical credential keys out of a phone and into a dedicated device.
A hardware anchored medical credential would begin when a hospital, public health agency, or other trusted authority issues a signed credential to the patient. The credential could represent vaccination status, blood type, allergies, or other various categories. Its private key would be generated inside an NFC card, wearable, hardware wallet, or similar secure element device and remain there, in theory, forever.
At the point of care, the patient would tap the device against a compatible reader. The device would generate a selective disclosure proof for the requested information using a scheme such as CL/Idemix or BBS+. A pharmacy could verify prescription eligibility, for example, without receiving the patient’s full medical record. The reader would check the proof against the issuer’s public key and receive only the information required for that interaction. The private key would remain inside the device.
Credential freshness could follow the approach used by CoronaCheck. The issuing authority would create credentials with short validity periods and refresh them regularly, similar to popular 2FA systems like PingID. This avoids depending on a permanent identifier or revocation list that could make separate presentations easier to link. A healthcare deployment would need to determine how long credentials remain valid based on how frequently the underlying medical information can change.
The design extends a process that has already operated at national scale. CoronaCheck generated selective disclosure proofs inside a phone application. The proposed system moves the key and proof generation into dedicated hardware, building on the smart card implementation demonstrated by Vullers and Alpár.
Physical hardware introduces additional costs. Patients can lose or damage a card, and being unable to access a medical credential could delay care. A practical system would need a secure re-enrollment process and a way to provide care when the device is unavailable. Distribution also raises questions of cost and access, especially for patients who may struggle to replace a lost device. These requirements would need to be addressed before hardware held credentials could serve as a default across a healthcare system.
The evidence supports testing this architecture through a trial. CoronaCheck provides the strongest example of selective disclosure operating at scale, while the smart-card research provides a working model for hardware custody. Combining those ideas would give patients a way to prove specific medical facts while keeping both their records and credential keys under their own control.
6. Limitations and Conclusion
CoronaCheck shows that zero knowledge selective disclosure can operate at a national scale. Vullers and Alpár show that Idemix proofs can be generated on tamper-resistant hardware. A complete system combining these components has not yet been tested in a medical setting. Its performance across different healthcare systems, patient populations, and regulatory environments remains unknown. A pilot program would be needed to evaluate recovery, accessibility, issuer coordination, hardware distribution, and integration with existing clinical systems.
Emergency access presents another unresolved problem. A patient may be unconscious or unidentified and unable to present the credential or approve disclosure. A lost or forgotten device creates a similar problem even when the patient is conscious. A wearable could make the credential harder to leave behind, but it would not determine who should be allowed to access information when the patient cannot consent. A real deployment would need a separate emergency access policy for allergies, medications, and other information needed for immediate treatment. Possible approaches include a narrowly limited emergency dataset, an authorized break glass process, or access through a designated proxy. Each approach gives up some patient control and creates another opportunity for misuse. Emergency access would therefore need strict limits, audit records, and patient notification after the event whenever possible.
Even with these limitations, the evidence provides a strong foundation for testing hardware anchored medical credentials. The cryptographic model has survived a national rollout, and the hardware implementation has been demonstrated on constrained devices. The next step is to integrate them into a system designed specifically for healthcare and establish standards that issuers and providers can use in production.
Such a system would allow patients to prove any medical fact without handing over the rest of their record. Keeping the credential key inside a physical device would also give the patient greater control over when and how that proof is generated. It would give patients a practical way to hold and prove sensitive medical information on their own terms.
- Dzurenda, P., Ricci, S., Ilgner, P., Malina, L., & Anglés-Tafalla, C. (2023). “Privacy-preserving solution for European Union digital vaccine certificates.” Applied Sciences, 13(19), 10986. https://doi.org/10.3390/app131910986
- Halpin, H. (2022). “A critique of EU digital COVID-19 certificates: Do vaccine passports endanger privacy?” In Proceedings of the 17th International Conference on Availability, Reliability and Security (ARES ’22). ACM. https://doi.org/10.1145/3538969.3544459
- Ministry of Health, Welfare and Sport (minvws), Netherlands. (n.d.). Security architecture [CoronaCheck app coordination repository]. GitHub. https://github.com/minvws/nl-covid19-coronacheck-app-coordination/blob/main/architecture/Security%20Architecture.md
- Ministry of Health, Welfare and Sport (minvws), Netherlands. (n.d.). nl-covid19-coronacheck-idemix [Source code repository]. GitHub. https://github.com/minvws/nl-covid19-coronacheck-idemix
- Madine, M., Salah, K., Jayaraman, R., & Yaqoob, I. (2025). “Zero-knowledge proofs for anonymous authentication of patients on public and private blockchains.” Array, 28, 100590. https://doi.org/10.1016/j.array.2025.100590
- Vullers, P., & Alpár, G. (2013). “Efficient selective disclosure on smart cards using Idemix.” In Policies and Research in Identity Management (IDMAN 2013), IFIP Advances in Information and Communication Technology, vol. 396 (pp. 53–67). Springer. https://doi.org/10.1007/978-3-642-37282-7_5
- World Wide Web Consortium. (2025). Data Integrity BBS Cryptosuites v1.0 (Candidate Recommendation Draft). https://www.w3.org/TR/vc-di-bbs/
- World Wide Web Consortium. (2022). Verifiable Credentials Data Model v1.1 (W3C Recommendation). https://www.w3.org/TR/vc-data-model-1.1/
This paper is my own original work, written for the Ledger N3XT Research Competition. I used AI as a tool for research, literature discovery, and early drafting. The analysis, arguments, structure, and final writing are my own.
I am also a co-author of ZKHealth, a student project created for the Stellar Consensus Hackathon in 2025. Although that project helped introduce me to this area of research, it is not cited, analyzed, or used as evidence in this paper.
Drew Manley, University of Oregon, Oregon Blockchain Group, September 2026
