4 ms·

> None of them are part of the Age Verification discussion because kids are not the actual point of Age Verification. The EU age verification solution says imp

• crote 11mo ago
  If privacy is an explicit goal, why isn't it a MUST? Why even bother with the initial batch issuance phase? And what's stopping them from silently adopting a batch size of 1?
  • magicalhippo 11mo ago
    > Why even bother with the initial batch issuance phase? This is a solution that requires non-trivial interaction between many paries. It seems very reasonable to want to get the parties started on the implementation so they can iron out issues in the infrastructure they're building while they work on the details of the ZKP aspects.
• mzajc 11mo ago
  Is there a good explanation of how ZKPs prevent attestation providers (which presumably know your identity) from linking an issued proof back to you if, for example, the website elects to store it? I can wrap my head around RSA and ECC and PKI, but I haven't managed to make sense of this yet. Assuming that's even a goal, of course. The cited paragraph mentions RPs (the websites, from what I understand), but makes no mention of attestation providers.
  • MatteoFrigo 11mo ago
    This is, of course, very technical, but here is how it works at a high level. In the non-ZKP presentation, the "holder" (phone) sends the credential to the relying party (website), and the RP executes some verification algorithm. In the ZK presentation, the holder executes the verification algorithm and sends to the RP a proof that the algorithm was executed correctly. The "proof" has this magical property that it reveals nothing other than the check passed. (You will have to take on faith that such proofs exist.) In particular, if the check was the predicate "I have a signature by ISSUER on HASH, and SHA256(DOCUMENT)==HASH, and DOCUMENT["age_gt_18"]=TRUE", anybody looking at the proof cannot infer ISSUER, HASH, DOCUMENT, or HASH, or nothing else really. "Cannot infer" means that the proof is some random object and all HASH, DOCUMENT, ISSUER, etc. that satisfy the predicate are equally likely, assuming that the randomness used in the proof is private to the holder. Moreover, a generating a proof uses fresh randomness each time, so given two proofs of the same statement, you still cannot tell whether they come from the same ISSUER, HASH, DOCUMENT, ...
    • parineum 11mo ago
      If it's not linked to an identity, why can't a kid use a parent's key?
      • MatteoFrigo 11mo ago
        Excellent question. More generally, what prevents me from copying the credential and giving it to somebody else? The currently favored approach works like this. The DOCUMENT contains a device public key DPK. The corresponding secret key is stored in some secure hardware on the phone, designed so that I (or malware or whatever) cannot extract the secret key from the secure hardware. Think of it as a yubikey or something, but embedded in the phone. Every presentation flow will demand that the secure element produce a signature of a random challenge from the RP under the secret key of the secure hardware. In the ZKP presentation, the ZKP prover produces a proof that this signature verifies correctly, without disclosing the secret key of the secure hardware. In your example, the parent could give the phone to the kid. However, in current incarnations, the secure hardware refuses to generate a signature unless unlocked by some kind of biometric identification, e.g. fingerprint. The fingerprint never leaves the secure hardware. How does the issuer (e.g. the republic of France) know that DOCUMENT is bound to a given fingerprint? This is still under discussion, but as a first bid, a French citizen goes to city hall with his phone and obtains DOCUMENT after producing a fingerprint on the citizen's phone (as opposed to a device belonging to the republic of France). You can imagine other mechanisms based on physical tokens (yubikeys or embedded chips in credit cards, or whatever). Other proposals involve taking pictures compared against a picture stored in DOCUMENT. As always, one needs to be clear about the threat model. In all these proposals the biometric identification unlocks the secure hardware into signing a nonce. The biometrics themselves are not part of the proof and are not sent to the relying party or to the issuer.
• baobun 11mo ago
  One thing to keep in mind when reading about any "ZKP protocol" is that on its own the term has the same inherent vagueness as "end-to-end encrypted" - especially when like here there are more than two parties concerned to solve a single verification. What information is not disclosed to whom? In what way is it ZK? One example is Googles "zero-knowledge age verification" where AFAICT, Google still has full insight into all the sensitive data and metadata. It's not like they inherently need to be the designated middleman but that is how the scheme is designed. Therefore I find it ingeniously marketed. A bit like saying "Facebook Messenger protects all your messages with end-to-end encryption", which is arguably technically true but misleading and not an honest statement.
  • Terr_ 11mo ago
    > same inherent vagueness as "end-to-end encrypted" Recent HN discussion example: How Kohler Inc. has a toilet feces analysis camera with "end to end encrypted", except they're one of the ends so it is deceptive advertising. https://news.ycombinator.com/item?id=46129476 https://news.ycombinator.com/item?id=46129476