[cyberax]

I've been looking at the field, and I can't really see how most of this is useful. ZKPs and FHE add a lot of complexity to a pretty simple task: verifying the age and/or identity.

These tasks are so simple that you can _almost_ use the existing TLS client certificates for that. Their only drawback is that they're trackable. A simple asymmetric challenge-response system with a nonce easily fixes this:

1. The service provider generates a 128-bit nonce and sends it to me.

2. I use a verification system provided by my government, and it returns a document saying: "The owner is more than 18 years old, the nonce for the request was ......, and this proof is valid for this service name hash". This document is signed by the trusted government certificate.

3. I send this signed document to the service provider.

No need for range proofs and other stuff. I think this flow can even be expressed using OIDC and JWTs!

What am I missing that requires full-blown ZKPs?

[j2kun]

How would you prove to the government in step 2 that you are the person whose age they're certifying?

This also seems like a lot of effort to maintain uptime and security of a service like this as scale, when errors would potentially keep people locked out of essential services. A system that requires a one-time download of a user-specific secret key, which can then be used to interact with the service provider directly, would be much more scalable...

[cyberax]

> How would you prove to the government in step 2 that you are the person whose age they're certifying?

How would you prove to the black box ZKP that you are the phone owner? Same problem. An interpretive dance before the camera, singing the national anthem, scanning the passport, etc. Doesn't really change anything.

> This also seems like a lot of effort to maintain uptime and security of a service like this as scale, when errors would potentially keep people locked out of essential services.

This is also trivially solveable with classic crypto. Just pre-generate a few (hundred) tokens for each user. The user just needs to generate a bunch of one-time private/public keys and get the "user is at least 18" certificates for each of the public keys. Then the user can just use them one by one as needed.

Apple Pay works this way, btw. That's why you can make payments with an Apple Watch while it's completely offline.

[j2kun]

> How would you prove to the black box ZKP that you are the phone owner?

My point was that your described flow was just shifting the burden of identity verification from one service to another. I think the ZKP solution has the benefit of the government not having to coordinate with other services. They can ship one set of cryptographic material to your device (with a single time when you have to do your annoying passport scan) and then you can do age verification with any service indefinitely. Heck, with a range query you can get that material when you're 16 and you're issued an ID and use it for age verification checks at 16, 18, 21, 25, whatever. I think there's a lot to be said for flexibility of the application here.

[Ar-Curunir]

ZKPs don’t require you to interact with a government service, and don’t need an internet connection at all.

[cyberax]

How would this work? What happens if a child picks up my unlocked phone and copies the authentication data to another device?

I guess you can put the proof-generating code inside some kind of a secure enclave? But then it's still not any better than classic asymmetric exchange, except that the government provides you a certificate that signs the private key held inside the TPM.

Or are you thinking about using a ZKP for a biometric proof? But then this still doesn't solve the issue of a malicious user just taking biometric pictures once, and then re-feeding them to the verifier.

I don't think this is solveable without some kind of trusted computing environment, at which point the classic asymmetrical crypto is fine anyway.

[tripplyons]

To answer your question, ZKPs can enable the verification step to be done privately in your example. Another use case could be allowing cloud computing hosts to prove that they did not tamper with the results of a computation.

[cyberax]

In this case, the government service doesn't get to know anything about the service (it only gets to see the salted hash of the service name)? And the service doesn't get to know anything about me, except for the "age certificate".

You can add more layers there, if needed for non-repudiation, all within the bounds of classic asymmetric crypto.

> Another use case could be allowing cloud computing hosts to prove that they did not tamper with the results of a computation.

What is the exact scenario here?

[saltpath]

The concrete scenario is AI agent execution. Agent calls a third-party API at 3am — you have your logs, they have theirs, and if there's a dispute you're comparing two mutable records. Sealing both the request hash and response hash with an RFC 3161 timestamp before the agent proceeds gives you a neutral third-party witness. Not zero-knowledge — content is visible — but for audit and dispute resolution it covers 90% of real cases and is deployable today without ZKP overhead.

[tripplyons]

Got it.

The scenario I'm describing there is how a service like AWS has the ability to tamper with your code or its output. If instead, each response came with a ZK proof showing that the inputs you provided lead to the outputs it returned, you could efficiently verify that nothing was modified.