From Credentials to Real-World Privacy: Designing Anonymous Verification for Everyday Use

Transcript

Hi again everyone. I'm Nicole from PSE at Ethereum Foundation. I'm a product manager responsible for implementing privacy focused protocol in real world use cases. Today I will share my current work which is designing anonymous verification for everyday use. I will talk about the problem we identified, how urgent it is, what's the protocol we implemented, and some case studies and lesson learned. So, let's get started. First, the problem.

Imagine you are picking up a package or buying an age restricted product or trying to prove you're a real person online. In each of these cases, the person who is trying to verify your eligibility, who we call verifier, usually needs only one fact which is if you are eligible. But now, but not your full identity or the full full information on the credential, right? For example, you want to enter a bar or a club when proving that you're eligible entering, you may use the ID card like this for verification. But there are so much personal information on the ID card that is unnecessary for

the verifier to know about. So, the question we first ask is very simple. How much information should you really have to expose to complete the simple check? This is the problem we want to start from. This matters now for some reasons. First, many verification systems still over share by default. Just like the few scenarios I share like picking up packages or buying alcohol, we often disclose a full identity in order to prove a single fact.

Second, in an AI-heavy environment, the demand for human verification is increasing. Platform services and marketplaces increasingly want to know whether there is a real person behind an account. But that does not mean the answer should be full identity disclosure. So, from the question of asking you how much information should you really have to complete a simple check? We now define the problem and ask ourselves, how do we increase assurance without normalizing unnecessary exposure?

I'll be using Open AC as a technical lens to see how this problem can be solved. Open AC is a lightweight and transparent anonymous credential design. It lets user to generate a proof on their devices to prove claims about their credentials without revealing unnecessary data. While staying compatible with existing digital identity systems. It sounds a lot, but I will further introduce it later. I'll be using Open AC as a technical lens, but this talk is not only about one protocol.

What I really want to explore is the gap between elegant anonymous credential design and the messy reality of deployment. Over the last period, we've been trying to understand that gap through actual implementation work. So, what I want to share today is not only what Open AC is, but also what changes uh when systems like this have to survive real use cases. This is the screenshot of the Open AC paper. It was just published this year by PSE and our grantees. You can also scan the QR code for the e-print. So, what is Open AC trying to do for this problem sorry

is like this. At high level, Open AC is trying to make anonymous credential functionality more deployable in environments that already have existing credential systems. So, we took European digital identity wallet requirements as the reference. For people coming from the identity world, you can think of this as adding an anonymous presentation layer on top of an credential ecosystems, rather than replacing the underlying issuance model.

The design goal here are important. No trusted setup to remove transparency concerns, no major issuer side changes, and compatible with existing credential workflows, so it's easier to adopt. Proving that it's practical enough to be realistic on mobile devices, because the user identity wallet is usually on the phone. And we make sure every proof generated and presentation shown by the user is unlinkable. Each time the credential is used, we re-randomize the proof, so repeated uses do not create a reusable fingerprint. It matters because otherwise digital ID would become a tracking mechanism that every use of

your credential could be connected across actions or services. So, Open AC is not just a circuit or framework in a generic sense, it is a protocol approach for anonymous or minimally disclosing verification on top of existing credential systems. It aims to be deployable, not just elegant. That matters because these systems do not live in a clean theoretical environments. To explain what Open AC tries to do step by step is uh starting from step one to three, uh you start with an existing credential issued by some trusted authority, like identity cards or driver's license.

Instead of presenting that credential directly every time, the user first prepares it on their devices, like the step four. Uh, that means verifying the issuer's signature, extracting the relevant attributes, and turning them into a hidden committed form. For example, when you try to show your ID to prove to prove that your age is above 18, it's not necessary to also reveal your name or even your birthday on ID, right? Then, before presentation and number five step, that pre-prepared state can be re-randomized with a nonce from the verifier. So, the different uses do not look the same. The That creates the unlinkability. So, no one can link the

actions between every time you present it. And finally, in the show step, the wallet proves only the statement the verifier cares about. So, the verifier learns the fact it needs, but not underlying data. That repeated uses are designed to be unlinkable as well. So, that's the core mental model I want you guys to keep for the rest of the talk. The first implementation I want to share is the human verification use cases for an online foreign platform. So, I'm from Taiwan, and one thing I noticed is every time when we're approaching the election, tons of robots and fake accounts appear on all kinds of platforms.

So, scam has always been a big issue in Taiwan. In fact, it's so serious that Chinese are really aware of the scams. So, scammer even trained their people in Taiwan. Meaning, if you can scam Taiwanese, you can basically scam people in any other countries. And now, in 2026, there is another round of election taking place in November. We wonder if we can solve it with OpenAC. So, we work with an anonymous forum, which is like the Reddit in Taiwan, and build a verification feature using OpenAC. And this is the link to the demo and the link to the spec, but you'll need to have a valid Taiwanese

credential to play with the demo. Just letting you guys know. The goal in this implementation was to help the platform establish that a user is a real legible human and is Taiwanese without um requiring the platform to collect more identity information than necessary. What made this case valuable is that it put us into contact with the real abuse problem, real infrastructure, and real multi-stakeholder process. It involved coordination with external organizations like the forum, the credential issuers, and discussion across different kinds of stakeholders.

And a lot of translation between cryptographic design and non-cryptographic requirements. You don't just say that, "Oh, I generate a ZK proof for you and you can send the proof to the forum to verify it." You remove all the draggins, so you can build trust and better UX with users. This is uh this implementation taught us several important things. First, spec legibility matters a lot. It is not enough for a design to be technically sound. It also has to be understandable to people who are not cryptographers, and in many cases, not even blockchain native.

Second, legacy constraints show up very quickly. Once you start interfacing with existing infrastructure, you inherit awkward signature choices, fixed formats, system assumptions, and organizational limitations. For example, OpenAC was originally designed with EUDI style requirement in mind where additionally issued credentials often use relatively compact signature schemes like ECDSA. But in this implementation, the government issued credential use an older and much heavier uh format is RSA with X.509.

So, that is exactly the kind of thing you cannot optimize for and protocol design, but you will repeat repeatedly run into in deployment. And once you do, it affects everything from circuit design to proof size to performance expectations. Third, desirable um features are not free. Uh I will take revocation as an example. Revocation means if the user lost their ID or even they've passed away, the system will need to revoke their credential. So, it will be noted as invalid credential and prevented from being misused.

This sounds like a obvious and critical feature, but there are actually very few credential issuers are actively maintaining such revocation list. In our case, we were lucky enough to find a list that was actually actively maintained, but because there had been large-scale uh credential loss in the past, the list itself had become very large. So, once we tried to integrate revocation properly, it uh we found that a feature that looked straightforward at the requirements level could become a performance challenge in practice.

I also want to make it clear that this is not just a story about one forum. This use case connects to a much broader class of online problems. How do you reduce fake accounts and coordinated abuse? How do you rate limit participation without forcing people into full identity disclosure. How do you create stronger assurance that there is a real person behind an account while still preserving privacy? Those questions are increasingly relevant in environments shaped by scalable automation and AI-assisted abuse.

So, even though this case is specific, the design questions it exposed are much more general. That is also why I think this kind of work connects naturally to broader discussions around personhood-style privacy-preserving verification that we will be continuing to work on. The second use case is quite different. This one focuses on age verification for online alcohol purchase in a government wallet ecosystem. In Taiwan, we don't allow online alcohol purchase since we worry that the underage can access alcohol too easily, and we even make a law to regulate it. But, what if we can design a way that allows you to prove

that you're eligible for buying alcohol in the privacy-preserving way? This time, we took Taiwan digital identity wallet as the target, which is the wallet in production and with valid credentials embedded. Here, the goal was to prove eligibility for an age-restricted purchase without forcing the merchant to receive unnecessary identity data. What made this use case especially interesting was that the surrounding wallet ecosystem already existed. So, we don't we do not invent a new stack from scratch, but integrate a privacy-preserving proof layer into a live environment with minimal changes.

That changed the nature of the work. We had to think not just about the proof generation, but also about the SDK design, merchant side verification, the flow, and the verifier UX. This second implementation sharpened a few different lessons for us. First, retrofit is often much more realistic than replacement. If you can add a privacy-preserving layer without forcing issuers to rebuild their systems, the adoption path becomes much more plausible.

Second, integration design matters a lot. An SDK is not just a convenience. It can be one of the main reasons a privacy-preserving approach becomes institutionally acceptable. Third, verifier UX matters just as much as holder privacy. A system can be cryptographically correct and still fail if relying party experience is confusing, fragile, or operationally burdensome. And finally, a working POC can do more than prove technical feasibility.

It can also become a communication tool inside institutions by showing that stronger privacy is not necessarily incompatible with existing systems. That's also what our POC contributes to showcase the that privacy-preserving solution within user-friendly UI/UX. So, even the people who work for government and don't know ZK at all, they can still understand what this technology can provide them. Looking across both cases, um a few lessons become clearer to me. First, verifier usually need less information than current systems collect. The

foreign doesn't need to see your Taiwanese ID to know that you're a Taiwanese. The alcohol vendor doesn't need to know your birthday to prove you're above 18 and sell you alcohol online. Second, deployment is much more about retrofit than replacement. Most real environments, they don't allow you to redesign everything. And third, privacy goals are always interacting with legal, operational, and UX realities. They do not exist in isolation, so communication among people from different backgrounds, design a system that includes all the whole stakeholder map is important.

And maybe the most importantly, the proving system is only one part of a much larger trust environment. So for me, the most interesting question is no longer whether anonymous credentials are possible. It is under what condition they remain good and useful once they meet the real world. And although these implementations happen only in Taiwan, I do not think the core lessons are local. The same questions are emerging in many digital identity environments. How What does the verifier actually need to know? How much can be added without changing issuer? And where do trust assumptions remain? That is one reason

we think this work have relevance beyond these specific use cases, including future privacy-preserving digital identity standards and broader conversations around interoperable wallet ecosystems. So these implementations provided us a way to learning of learning how deployment-oriented privacy actually demands. So what's next for us? We want to make sure the approach are more compatible, more reusable, and more secure over time. So we want broader compatibility that includes support for more VC style credential options in real-world use case implementations. And we want

privacy-preserving verification to be easier to integrate in real systems, which means better SDK, better developer experience, and more reusable implementation paths across different credential ecosystems. Another direction is expressiveness. Right now, a lot of real-world use cases depend on relatively simple checks. But, over time, we want to support more generalized predicates or multi-VC linking. So, that services can ask richer questions without defaulting back to raw disclosure.

You can also check the QR code here to see our ongoing work on that regarding like generalized predicates and multi-VC linking. And the last is policy control. One important lesson from this deployment is that privacy is not only about what can be proven, but also about what verifiers are allowed to ask for. We'd like to explore how to make sure a verifier requests only the information actually needed for the use case, and not more.

We hope to turn what we learn from this POC into a more deployable privacy-preserving verification stack. So, before we end this talk, to summarize, my main point will be anonymous credential become truly impactful only when they survive contact with reality. That means surviving legacy systems, surviving mobile constraints, surviving verifier needs, surviving institutional inertia, operational rollout, and legal requirements.

The challenge is not only to invent stronger privacy primitives. It is to design privacy-preserving verification systems that can actually be adopted. That is why we have been trying to learn through these implementations. So, if you're working on a related use case, I'll be very happy to talk to you and we also build Open AC studio here to help you quickly identify how Open AC may be able to help you with your use case and feel free to try that out. I will also stay around if you have any question.

>> Um hello. Thank you for the speech. And so I wanted to ask you you mentioned the Taiwanese elections where you need to verify that someone is human without exposing any sensitive information. But you also need to record who has voted so that you prevent like duplicate votes, right? So how do you do that if you if the user has not exposed any sensitive or any information at all. >> what? >> Exposed like when voting you need to verify he's a human.

>> Yes. >> But the he you don't want to expose any sensitive information or the voter does not want to expose anything about himself and verify he's a human, right? >> So the question is how do we >> How do you prevent double votes then if you How do you know who has voted and who did not if they >> voted? >> Yeah, in the elections. >> Do you mean the use case you are talking here is the voting use case? >> Yeah. >> So for that kind of use case, uh it may not be fully compatible with Open AC. So what Open AC is mainly doing here for you is unlinkability. That means your action every time we ran we randomize

the action so the verifier cannot track your actions. But for voting I imagine you are only vote voting for once. You don't do this several times, right? So, that may not be exactly compatible with the protocol I'm sharing here. >> Yeah, okay. Thank you. Any other questions? >> Thank you, Nicole.