Privacy Invariants in Digital Identity

Thank you, Mikala. Yes, I am also a human. And recently, yeah, I've been getting interested in digital identity. So, digital ID systems, like WorldCoin, are being widely deployed all over the world. So, for instance, the EU Commission is rolling out the EU digital identity wallet next year.

And the more I looked into these systems, the more troubled I became. The EU digital ID wallet, for example, has selected a design that does not afford the user any privacy. Its user actions are fully linkable. And this is what they're going to deploy in 2026, in their own regulations, which specify the need for unlinkability. So, my question was, how is it that the EU Commission could sleepwalk into choosing such an inadequate design?

How can we prevent this? And how can we, furthermore, prevent the deployment of digital ID systems in contexts that are inappropriate, that don't need strong authentication? And how can we prevent deploying them in contexts where they're strictly worse than existing physical forms of verification? So, this talk introduces a threat modeling framework called privacy invariance, or invariance-centric threat modeling. And I propose this as one systematic way we can identify privacy violations in our protocols.

So, first of all, I want to introduce two related but distinct concepts, authentication and authorization. So, authentication refers to proving a unique identity, like a person, or just a single entity. Whereas authorization expands this access list to a set of size N. So, I am one of N citizens. I am one of N employees.

And, of course, in cases where this set is size 1, so, like, the set of people who can access Mykola's bank account is Mykola, this authorization reduces the authentication. Now, it's important to distinguish between them because a digital ID affords us the ability to authenticate people, to uniquely identify them. And they are, right now, being deployed in contexts that do not require such strong authentication. For example, age verification. That requires only weak authorization.

That requires you to prove membership in the set of people above 18. So, digital ID is not appropriate for such contexts. It should not be naively used for such contexts. And this principle is called purpose limitation. It's simply limiting the amount of data that you collect, limiting what you can even do with it.

So, in order to reason about the requirements of these applications, and in order to identify when our solutions violate them, one useful framework I found is invariant-centric threat modeling. So, if you guys are familiar with threat modeling, usually threat modeling frameworks, they approach the problem from, it's like, imagining possible attacks. So, like, enumerating all the possible adversaries and all the creative ways they could attack your system. So, the main drawback of this, like, attack centric framework is they are prone to a failure of imagination. So, invariant- centric framework starts with zero assumptions about your adversaries, and then it sets out, basically, the invariants that you want to preserve, the guarantees that you want to provide your users.

And so, it's building up this series of guarantees of invariants and identifying when they're violated. So, and the Zcash wallet application uses this framework, for example. So, I'm going to take us through two edge cases, two use cases, where digital identity is being applied. And, to me, these are edge cases, because I think these are cases where digital ID should not be applied. So, the first one is humanitarian aid distribution.

Basically, in the crisis zone, you're, like, an organization, like, the Red Cross is trying to distribute aid, but make sure that, for example, nobody double claims it, that everyone who claims it is a registered legitimate recipient, and so on. And, to do this, a bunch of organizations have simply created a digital ID system in the community of refugees. So, for example, the World Food Program in Yemen, Western Actors in Afghanistan, they built, in these two cases, a database of biometric data about refugees. And, in some cases, these were political opponents of the authorities of the regimes in power. And, when these external actors leave, they often leave behind these banks of biometric data that would endanger the refugees.

Another edge case is a very, very common age verification. So, I'm going to focus, in particular, on physical age verification, which means whenever you present your physical ID right now. So, in the pub, this, on your left, is a screenshot from the UK government that say, like, pubs, clubs, and shops will now start to accept digital IDs. And, the other screenshot is from my Colorado digital ID program. They are also partnering with physical businesses, breweries.

And, so, I'm going to argue here that digital ID is strictly worse in these cases. It should not replace physical IDs. So, the first edge case is aid distribution. So, this screenshot is from a research paper called Not Yet Another Digital ID System. So, these researchers were working with the Red Cross, and they basically argued that a successful aid distribution system does not need yet another digital ID system.

So, they set it up with these parties, whereby the recipient registers into the system, and then receives some credentials, and is able to then use them to redeem goods at the distribution station. And, another requirement of the system is that it needs to be auditable after the fact. So, the auditor needs to be able to access the logs in a privacy-preserving way. So, now we're going to go through the exercise of invariant-centric threat modeling. What are the privacy invariants that we want to preserve here?

So, firstly, the registration station, they are learning a lot of personal information about you, like your name, your household, your household needs, etc. So, they are learning all that. But, what they should not learn is how you're transacting in the system after you register into it. So, it's kind of like the WorldCoin app shouldn't learn about your transactions. The registration systems should not be able to observe you making a transaction.

The distribution systems should not learn anything about you beyond whether or not you're registered. So, yeah, they should only be able to authorize you and not authenticate you. The auditors looking at the logs should not be able to tell whether two transactions were made by the same recipient. So, they should not be able to trace a single recipient through the logs. So, yeah, this is, I really like the privacy requirements, privacy invariants framework here, because then we can sort of analyze different alternatives, different solutions, according to whether or not they preserve these invariants.

So, a lot of aid distribution systems still use manual pen-and-paper solutions. So, to register people, they create lists of registered households, and they then give it to the distribution system. So, after you're registered, they cannot track you anymore because you're not leaving a trace of your actions. Sorry, because the distribution stations are not communicating anymore with the registered stations. But the distribution stations do receive all your information, all your particulars, your name, and they request that data from you at the point of distribution.

So, for them, it is extremely clear who is receiving aid from which station. So, this violates the privacy invariant that this distribution station should not learn any information, any personal information about you. And the auditors, after the fact, also get access to the logs that the distribution system used. So, they learn basically the same information that the distribution stations do. Now, this is not an optimal solution, but biometrics are even worse.

So, in the case of biometrics, the registration station, like WorldKind, scans, say, all your irises. And then the distribution station afterwards checks against the database whether or not your iris appears there. So, I guess if you actually use WorldKind, the distribution station could just check that you're in the stat of participants. But as they're deployed in these aid distribution systems, the distribution station literally scans your iris and asks the registration station if you're in the list. And because these transaction logs are personally identifying, once again, any auditor would be able to trace your transactions.

So, what this research paper concluded was that digital identity is way too strong of a system for humanitarian aid distribution. And really, all we need is a weak authorization that preserves certain security invariants. So, all we need to do is check that you're not double-claiming. All we need to do is check that you're registered. And we don't need to know any personal information about you beyond what you've given at registration.

So, basically, they introduced a system where the registration station blindly signs tokens and distributes them to households so that at the point of distribution, there is no way for the registration station to identify that it's your token. And there's no way for the distribution station to learn anything about your identity. And at the same time, these tokens are stateful. So, they encode how many times they've been redeemed within a certain time period. And so, an auditor only needs to track that the tokens add up to the total amount of aid distributed without learning any personal information.

So, yeah, I recommend everyone read this paper, Not Yet Another Digital ID, because it's really questioning the premise of whether digital ID is appropriate in many situations. So, yeah, the other use case that I wanted to go through is physical age verification. So, this is another edge case because it's replacing a physical interaction with a digital interaction. And that is strictly worse. So, how it's been proposed, like the eDigital Identity Wallet, for them, age verification is one of their main use And how they propose to do it is you, the holder, you get some kind of credential, let's say your passport from your government, and you're able to make proof about this credential and present, let's say, a proof that you're over 18 to a verifier.

So, this is very nice because the verifier doesn't need to phone home to the issuer, get your credential. So, you can locally make a proof about your credential. Now, what are the privacy invariants that we want to preserve here? So, first of all, as before, the issuer should not be able to link presentations to a holder. So, by looking at transactions happening in the system, the issuer should not be able to relate two transactions to one holder.

The verifier, once again, should not learn any personal information about the holder. They should only learn that she is above 18. And similarly to the issuer, the verifier should not be able to tell whether or not two presentations came from the same holder. So, the solution currently proposed by the E-Digital Identity Wallet is something called SDJETS, Selective Disclosure JSON Web Tokens. And these violate the privacy invariant about linkability.

So, SDJETS allow issuers and verifiers to link transactions to individual holders. How it works, just really quickly, is that it takes the credential and it kind of obfuscates the plain text values by hashing them with some salt. So, the issuer, instead of signing the plain text credentials, signs the salted hashes of them. And the idea is that the holder can then present, can then disclose a subset of these hashes while keeping the other ones closed. So, I could choose to just open the hash, my name, and then leave the other two as random strings.

The issue with this is that the hashes themselves are unique. They are random, but they are unique. And so, if I present the same hash twice, even if I don't open them, I can be linked. So, this is the solution that the EU Commission settled on and will likely roll out next year. Yeah.

So, most ZKID solutions that you might be familiar with try to improve this by concealing these salted hashes as private inputs in a ZK-SNARK. So, this does solve the problem. Yeah. And the project I'm working on is trying to integrate these and propose it to the EU Commission. So, yeah.

If, once again, we compare these protocols according to privacy and variance, we'll find that, yeah, the SDJETs, they do not, they violate linkability for both issuer and verifier. They actually do preserve selective disclosure. So, that's a typo there. Whereas physical ID presentations are not linkable, like the issuer has no idea when you're, who you're showing your license to. The verifier is not recording your license, and so does not have a log of credential presentations that it can link.

But, yeah, physical ID does not preserve the selective disclosure and variance because you are showing everything of that yourself. Whereas anonymous credentials, ZKID preserves the variance. I think I'm at time now. But, yeah, just to wrap up, there's this final privacy and variance that is unique to physical ID, which is repudiation. As I mentioned just now, a physical ID presentation does not create any logs, and meaning that after presenting the ID, you can plausibly deny having made that transaction.

Like if I buy alcohol at the liquor store with cash, I can later just deny that I did that. Whereas, like, for example, SDJETs do not allow you to do so, and anonymous credentials using ZK's NARC may or may not, depending on which fields you reveal. So, that's the end of my talk. Thank you for your attention. Thank you.

Questions, questions? Hello, thanks for this speech. I was talking to a colleague of yours, both in terms of as a human and as a cryptographer, and he's also thriving for making this LD less a catastrophe. And he was telling me that from a code point of view, from a cryptographical point of view, like, it's like just a disaster. And so I was wondering why, what do you feel is missing?

Because actually, I feel being a little bit close to these kinds of institutions that there is not bad intentions behind this, behind this, like, very bad deployment or theory. I think for sure there is like lack of diversity in the team that then go to deploy these systems and work on these digital systems. But I'm wondering, like, for this friend of mine, you know him, he's a matter of, it's a matter of lacking of meritocracy. And so given that, I really feel that there is not bad intentions behind, like, let's build shitty systems so that we can rape all the identities. I'm wondering, what is for you lacking that, what's missing?

And why there are not good cryptographers working on this? And how do you feel we can manage to actually speak with these institutions and help out to build something more meaningful? Because I think that there are many good people there around. And I think personally, my take on this is that, don't disturb me, please. I personally feel that, thanks, I got lost.

I personally feel that what's missing is good. I think I have a hypothesis on what's missing as well. So the EU Commission actually do have a series of requirements and guidelines that have strong privacy requirements, for example, unlinkability. They themselves wrote it there. And so given already, a list of privacy invariants, I think what was lacking was a systematic analysis of whether their solution violated or preserved these invariants.

So like, I think we need an easy framework that can make it very, very clear when they are in violation of a great privacy invariant. So yeah, because there's really no way they can deny it. Once they're shown an analysis that's laid out so clearly. And in fact, that's what happened. They asked for cryptographers feedback on a protocol.

And this consortium of cryptographers like just ripped it to shreds. So we need like to start with these privacy invariants. And then we need a systematic way to analyze whether or not they're preserved. Thank you. Other questions?

Can we change something? Can we complain to the Commission in order to raise awareness for them to change this? That's what I've been wondering too. So the cryptographers feedback is public. And in response to that, they are actively looking for other solutions.

So they are considering their knowledge proofs as a solution. But I think the damage has been done in many ways. And the reason I say this is that many other countries are following the EUDI. So I know, for example, the Taiwan digital ID wallet has chosen as the debt. And they're gonna have the same unlinkability problem.

So the question of, like, in Taiwan, for example, there's a very strong civil society. There are these groups that make a lot of noise that can pressure the government that can raise awareness that can communicate to the public. And I think that's very powerful. In fact, the first iteration of the Taiwan digital ID was so unpopular that they had to, like, prematurely stop it. And this is their second iteration.

So I think that in countries with a strong civil society, where the government can be pressured by these groups, it's absolutely worth it to raise awareness and to advocate for privacy. Yeah. Do you know what the name of these groups have been? Yeah, there's like the Open Culture Foundation. There's like, well, I can tell you offline.

Yeah. There's a few. Audrey Tang is an advocate for privacy in Taiwan as well. And also there, by the way, agencies that audit ministries. So if we can get the auditors to change their guidelines and requests, then we force the ministries in that way to be compliant with these guidelines.

Yeah. Questions? Then I would ask this one, like, you're dealing with the government officials and you're going through the maze of bureaucracy from this team. How the so-called the three builds the language and mutual understanding with, like, government officials? And how we should build collaboration?

And where we should, sort of like, as a culture, put heart no or heart stop? Because generally speaking, this transition is about changing power dynamics also from the government. That's a good question. Yeah, I think I was speaking with Audrey Tang a little bit. She has experience and sort of playing the game, but she was an activist and then she was sort of brought into the Ministry of Digital Affairs as a reverse mentor.

So it's a combination of understanding the processes of government, for example, like targeting the auditing agency, as well as educating the government officials, like, yeah, communicating, like, at a high level, what privacy and variance you have and what technologies you have to achieve them. So my experience, I've been just trying my best to just integrate, to meet them where they are, to integrate with, like, their existing APIs, to demonstrate to them, like, how simple it is. Yeah, a lot of it is about understanding that government projects operate on a really long scale and they involve multiple layers of contractors and subcontractors. So I think always the principle is to keep it simple and to remember, like, your objective is to get understanding from the other party. Yeah.