Comment by donmcronald
3 days ago
> It derives an age attribute such as "over 18" from a passport or ID, without disclosing any other information such as the date of birth.
How? If it’s analyzes my ID 100% client side I can fake any info I want. If my ID goes to a server, it’s compromised IMO.
I think the zero proof systems being touted are like ephemeral messaging in Snapchat. That is, we’re being sold something that’s impossible and it only “works” because most people don’t understand enough to know it’s an embellishment of capabilities. The bad actors will abuse it.
Zero proof only works with some kind of attestation, maybe from the government, and there needs to be some amount of tracking or statistics or rate limiting to make sure everyone in a city isn’t sharing the same ID.
Some tracking turns into tracking everything, probably with an opaque system, and the justification that the “bad guys” can’t know how it works. We’ve seen it over and over with big tech. Accounts get banned or something breaks and you can’t get any info because you might be a bad guy.
Does your system work without sending my ID to a server and without relying on another party for attestation?
There's no dynamic analysis done, necessarily. In the Swiss design, fex, SD-JWTs are used for selective disclosure. For those, any information that you can disclose is pre-hashed and included in the signed credential. So `over_18: true` is provided as one of those hashes and I just show this to the verifier.
The verifier gets no other information than the strictly necessary (issuer, expiry, that kind of thing) and the over 18 bit, but can trust that it's from a real credential.
That's not strictly a zero knowledge proof based system, though, but it is prvacy-preserving.
The issuer knows everything and can help track if the wish to. The issue here is lack of trust in any corporate or government entity.
Well, yes, if they use something completely different to what's published and designed.
But no, we're not talking about the case where there's no trust at all in the government, because then you don't get verifiable credentials at all. We're talking about building privacy-preserving credentials that actually have a use.
> If it’s analyzes my ID 100% client side I can fake any info I want. If my ID goes to a server,
amplifying your point, there is effectively no way for the layperson to make this distinction. And because the app needs to send data over an encrypted channel, it would be difficult at best for a sophisticated person to determine whether their info is being sent over the wire.
This is a fairly weak argument though: the layperson also cannot verify the software updates we push to their phone/computer or any number of other critical devices in the chain.
All of this is reputation management: if technical experts broadly agree the system does what it says, then all of us have to accept that in aggregate that's probably good enough and significantly better then many other areas.
> And because the app needs to send data over an encrypted channel, it would be difficult at best for a sophisticated person to determine whether their info is being sent over the wire.
Devices are built from the ground up to prevent even sophisticated users from tapping them to verify we aren't being lied to. The average person thinks that "hackers" will mobilize if things get too bad and they're completely wrong.
Tamper proof, encrypted chains of trust start from the second a device gets power and it's infecting everything from appliances to phones to computers. Get ready for a future where your rented toaster has parts serialization that can't be bypassed.
Oh -- how do I ensure that the device is running only the software I installed, with exactly the patches I added, rather than a possibly malicious vendor -- for example, if the local government of the country I'm visiting has a court order for phone vendors to silently backdoor phones, it would be nice to know that only the software I personally signed is running.
As someone that patches their OS on the regular, this would be pretty interesting.
Attestation from government sounds like the ideal solution. This could actually provide _more_ privacy because we can begin using attestation for things we currently use IDs for such as “Has the privilege of driving a car” or “Can purchase alcohol”
Amazing how fast these systems go from "zero knowledge" to "route the request through the government system every time you use your ID"
there is no "route the request through the government system every time you use your ID".
you get your sd-jwt document signed once and you reuse it for like 30 days or so.
8 replies →
Except it wouldn't need to be every request. Just the first one.
All these services have accounts, and the only time you need to do an age check is when the account is created.
Yes it does actually. You load your ID into your phone with the MRZ and NFC. The cryptographic proof inside your ID is used to verify that it was issued by an official government. So your ID is not being sent to a central server.
The reusing another ID is an issue. In some countries they will have a in person check to verify only you can load your ID into your phone. But then you still have the problem of sending a verification QR code to someone else and have them verify it. This might be solved by rolling time-gated QR codes and by making it illegal to verify someone else's verifications. But this is a valid concern and a problem that still needs solving.
> If my ID goes to a server, it’s compromised IMO
Might be breaking news, but the state already has your passport ID in a server.