[TimJRobinson]

The ID would need to have some government digital signature for the ZK circuit to work. The proof would be "this digital ID that has this valid government signature shows XYZ".

The verifier would need the government public key and then can see "This ID that has been signed by the governments private key shows XYZ"

[cyberax]

And the next question is: why bother? We have well-established protocols for the ID card: a police scanner creates a nonce and sends it to the card, the card signs it with its private key, and provides a certificate signed by the government.

The police scanner then verifies the signature and checks that the certificate is correctly signed by the government's public key.

No need for ZKP.

[TimJRobinson]

You think peoples licenses / passports are little computers with API's built into them that return arbitrary information on demand? Over the internet?

[cyberax]

> You think peoples licenses / passports are little computers with API's built into them that return arbitrary information on demand?

Literally yes, in some places. Passports have a chip in them, and licenses in some countries as well.

> Over the internet?

Tunneling private information over untrusted networks is literally how you're seeing this message.

[TimJRobinson]

Yea the chip gives the information written on the device. It doesn't answer arbitrary questions about the data.

The whole point of ZK proofs is the zero knowledge part. If you don't care about the person being able to see the information of course there's no need for them.

[bschmidt1]

First you described exactly the concept of password hashing, now you're describing something else entirely:

> It doesn't answer arbitrary questions about the data.

Why would you need a "ZKP" to prevent anyone from "asking arbitrary questions" you simply don't build that functionality.

When I create a web server and allow people to login through an endpoint, they can't ask arbitrary questions about user data either - how would that functionality even exist without me writing it? Typically the server doesn't even know passwords. It simply compares a hash - the hash is computed client-side and the server never sees the real password.

Any peripheral user data you want to return is up to you. Identity is not "built in" to conventional programming languages.

Furthermore, none of the ZKP libraries on npm do anything. Most of them are utility libraries with functions like "generateUUID" and "leftPad". The ones from providers like Cloudflare (their least popular stuff) are just private/public key encryption libraries that they call "ZKP".

[TimJRobinson]

I didn't mention hashes anywhere in this thread, you were the one claiming you can prove someone's age just based on a hash of it (and still haven't shown how other than breaking the hash with a rainbow table).

I posted this earlier (and it's in the article...) but will reiterate again: ZK proofs are used when the prover (server) and verifier (client) don't trust each other and don't want to give each other data on each other. If you trust the server you can just give it a copy of your passport, if the server trusts the client they can just show a checkbox asking if they're old enough.

I linked to a working library earlier, it's here https://github.com/zk-passport/openpassport