The identity industry has quietly agreed on something. Authentication is solved. If you don’t have passkeys yet, you’re late. But passkeys don’t answer every question.
What happens when a user loses their device? How do you know a real person approved a payment and not an AI agent holding their passkey? And how do you prove any of this without collecting more personal data than you need?
Those questions came up again and again in a recent conversation between Realeyes and one of Europe’s largest identity providers. This post pulls together what we heard about where the market is heading. It also sets out how our CPO Scott Jones sees zero-knowledge proofs fitting into VerifEye.
Authentication Is Solved. Recovery Isn’t.
The mood at this year’s Authenticate conference was clear. The FIDO Alliance community, the people who made passkeys happen, now treats login as a closed problem. Ping Identity, Google and others delivered the same message from the stage: passkeys are the answer for authentication. But having passkeys doesn’t mean you’re finished.
The weak points have moved. Attention is now on two parts of the identity journey that passkeys don’t cover:
- Account recovery. When a device is lost or replaced, the user still has to prove who they are. That fallback is often the easiest way in for fraudsters.
- Human presence. Some actions need proof that a real person is there, not just a valid credential. Agentic AI makes this urgent. If an agent can hold a passkey, a passkey approval no longer proves a human gave consent.
That second point matters more each month. A passkey tells you the right device signed in. It can’t tell you whether the user or a software agent acting for them pressed approve.
A passkey tells you the right device signed in. It can’t tell you whether a person or an AI agent pressed approve.
FIDO’s Next Bet: Verifiable Credentials
With passkeys settled, the FIDO Alliance is turning its focus to verifiable credentials. The thinking follows the passkey playbook. Passkeys didn’t take off because of a European standard. They took off because Google, Microsoft and Apple adopted them and made them a de facto standard.
The bet is that verifiable credentials could follow the same path. Big platforms adopt first and the market follows, whatever formal standards say.
That puts Microsoft in an interesting spot. It is often late to identity trends but present in almost every enterprise. What Microsoft announces at Ignite tends to shape what enterprise buyers ask for the following year. Anyone working in identity should watch it closely.
Europe Writes the Rules
Europe is taking a different route. Standards come first. The EU Digital Identity Wallet and its supporting specifications set out how credentials should be issued, held and presented. For age assurance, the European Commission’s proposed KIDS Act goes further. It would require certified, privacy-preserving age checks for social networks and video-sharing services, and it specifies zero-knowledge proof technology. Platforms would get a yes-or-no answer, never the user’s identity documents.
For European identity providers, this isn’t optional. They sit inside the consortia defining these standards. Any technology partner they choose has to fit that path.
Privacy Is Ranked, Not Assumed
Large identity buyers don’t take “privacy-preserving” at face value. They rank approaches by how safe they are, based on what is stored and what is left behind on the server. One common ordering puts these approaches from strongest to weakest:
- Fuzzy extraction combined with zero-knowledge proofs
- Fuzzy extraction alone
- Multiparty computation
The reasoning is about entropy. Fuzzy extraction alone may not hold enough of it. Too little and the system can’t tell people apart. Too much and genuine users get rejected. Combining fuzzy extraction with zero-knowledge proofs raises the security bar while still leaving nothing behind to breach.
Technology is only one part of the decision. Buyers increasingly score partners on three kinds of fit: technology, commercial and cultural. A solution can pass the first two and still fail if the teams don’t see the future the same way.
How Zero-Knowledge Proofs Fit Into VerifEye
Scott Jones co-chairs the Trust Over IP Zero-Knowledge Proof Task Force under the Linux Foundation. The group launched in July and works with Berkeley cryptographers and the EU Digital Identity Wallet benchmarking team. Much of its work is building a library of proven ZKP recipes.
The starting point is simple. “There is no single silver bullet,” Scott says. “The right mechanism depends on the use case, the security bar you’re trying to achieve, where it runs, the UX you’re trying to drive and the compute time.” Some proofs take 30 minutes to run. Others take milliseconds.
What a Zero-Knowledge Proof Does: An Age Example
Take a user who needs to prove they’re over 18. With VerifEye and a zero-knowledge proof running on their own device, the flow looks like this:
- Prove 18+. A relying party asks the user to prove their age.
- Face check. VerifEye estimates their age from a short selfie.
- Credential issued. The credential is stored in the wallet on the user’s own device.
- Proof built on device. A ZKP library builds a proof against that credential.
- Verified blind. The relying party checks the proof.
Prove 18+
User must prove their age to a relying party
Face check
VerifEye estimates age from a short selfie
Credential issued
Stored in the wallet on the user's own device
ZERO-KNOWLEDGE ZONE · ON DEVICE · NO SERVER
Proof built on device
A ZKP library proves against the credential
Verified blind
The relying party checks the proof. No face, embedding or exact age is seen
One proof can bundle, in a single step:
- Age rule is met
- Credential is bound to the device
- Verifier is trusted
- Issuer is trusted
The relying party learns one thing: this person is over 18. It never sees the face, the biometric embedding or the actual age.
Steps four and five happen in a zero-knowledge zone. All proving runs on the device, with no server dependency. The proof is presented using open standards: OpenID4VP and the Digital Credentials API.
One proof can confirm several things at once. It can show that the age rule is met. It can show that the credential belongs to this device and wasn’t copied. It can limit who is allowed to read the result. And it can confirm the credential came from a trusted issuer.
“There is no single silver bullet. The right mechanism depends on the use case.”
This is the real “why” of zero-knowledge proofs. The user proves what’s needed and nothing more. Their data stays with them.
Why Each Proof is Custom Work
Some parts already exist. Proof libraries, proof systems and web and native integrations are ready today. What has to be scoped for each use case is the credential design and the circuit that proves against it. The circuit is the logic that encodes exactly what must be proved and the conditions it must meet. Once built, circuits are portable across devices.
Scott puts the split at roughly 80% circuit work and 20% credential work. Every use case needs its own circuit. Proving someone is over 18 is a different circuit from proving they’re a unique human or that they match a credential. Each one also has to fit where it runs, the credential format, speed requirements and UX targets.
The usual guide is two to three months per proof. “Building these circuits is generally hard,” Scott says. “But the real point is it’s a known, buildable integration. It’s not a research project, and we know how to wire it in.”
Choosing a Mechanism That Fits EU Standards
Under the proposed KIDS Act, age checks would need to be certified and based on zero-knowledge proofs. ETSI, one of the EU’s official standards bodies, is working on the specification for these mechanisms. Here’s how the main options compare:
| Mechanism | Certifiable (ETSI) | How to choose |
|---|---|---|
| VegaMicrosoft | Yes | Designed to be post-quantum. Can be faster than Longfellow, sometimes at a higher memory cost |
| LongfellowGoogle | Yes | The mature, well-proven default. Also designed to be post-quantum. Slightly slower than Vega |
| BBS | Yes | Generally the fastest. Device binding needs an added construction. Not post-quantum |
| HashWires | No | Fastest on the web. Single-use only, with weaker unlinkability |
Post-quantum here describes the proof system, not the credentials beneath it, which often use ECDSA. These designs are new and still being validated. For most of the use cases we’re looking at, Vega or Longfellow is the right choice.
BBS is tempting for speed. The problem is what happens later. “You can’t swap out these circuits,” Scott says. You can’t replace the engine while the plane is flying. Start with BBS and you’ll rebuild from scratch when post-quantum resistance becomes a requirement. HashWires has the same catch. Certifiable options still take around 10 seconds in a browser, so HashWires is a useful near-term bridge for quick web demos. It isn’t a route to compliance.
“It’s a known, buildable integration. It’s not a research project, and we know how to wire it in.”
One ZKP Layer, Many Credentials
We’re building the zero-knowledge layer with specialist cryptography expertise, drawing on the proven recipes coming out of the ZKP Task Force.
That layer isn’t limited to VerifEye. It can support other credentials on a platform too, giving relying parties one privacy-preserving approach across every credential they accept.
Biometrics and Zero-Knowledge Proofs, Together
The market is asking for proof of human, safe account recovery and privacy that holds up under scrutiny. No single technology delivers all three. A biometric check proves a real person is present. A zero-knowledge proof makes sure nothing about that person leaks to the party checking.
That’s the hybrid we’re building. VerifEye brings the biometric expertise. Our ZKP partners bring the cryptography. Together they give relying parties a yes or no answer and leave the user’s face, embedding and personal details where they belong: with the user.
It builds on work already in market. Our partnership with GBG brings biometric reverification to the moments that matter most after onboarding, including the account recovery problem passkeys leave open.
It also fits where the industry is going. FIDO is moving toward verifiable credentials. Europe is writing ZKP into its age assurance rules. And agentic AI is making proof of human a requirement rather than a nice-to-have.
Exploring privacy-preserving verification for your platform?
Get in touch to talk it through with our team.