Can anyone explain a bit more about how this actually works in context here?
Do you hand your full PII "private key" or equivalent, to Google, or does any of the proving happen on your own device?
Then proofs are constructed to 3rd parties, proving certain properties of your data without revealing the underlying data? Are they live/interactive proofs or can static proofs be constructed for these type cases?
What is exactly being proved? Proving that you/Google knows a "private key" that can be found in a particular set of public keys published by the issuer? Or something like that?
>which will use digital IDs from Google Wallet to verify user identity and ZKP to verify age
This seems to imply you have to upload your information to Google first. But if you do that then what's the point of ZKP, Google might as well just send over a signed attestation token.
Speaking as one of the implementors of the ZKP system described in the article.
The identity document (e.g. driver's license) is granted by an issuer (e.g. department of motor vehicles) and stored in the user's device only. Google is not part of this flow and the document is not sent to Google or stored by Google. In fact, one major technical problem is how to make sure that the document cannot be used without having possession of the phone. To this end, the document is associated with the phone's secure element (think of a hardware yubikey already present in the phone itself) and cannot be used without the secure element.
Think of the document as a dictionary { "name": "foo", "address": "bar" ... }, although the reality is more complicated. One standard for these documents is ISO/IEC 18013-5, but other possibilities exist.
The proof itself proves the truth of a certain predicate on the document. The predicate is something like "The document parses correctly, it is bound to the device's secure element, and it contains zip_code = 012345".
The phone generates the proof at presentation time in about 1s. Another major technical difficulty is that past attempts at solving this problem required prover time of tens of seconds. Our proofs have the property that no entity, including a future quantum computer, can learn anything from the proof other than the predicate is true. See https://eprint.iacr.org/2024/2010 for the gory details. The specific predicate being proved is in Algorithm 10.
When you say "interactive" you probably mean "at presentation time", as opposed to "in advance". We generate a fresh proof at presentation time and not in advance. Be aware that the ZKP literature uses "interactive" in a different sense, in which the verifier keeps posing multiple challenges to the prover until the verifier is satisfied that the proof is correct. Our system is derived from an "interactive" protocol in this technical sense, and transformed into a "non-interactive" prover via a general transformation called "Fiat-Shamir". The net effect is that the verifier asks "tell me your age and nothing else", the prover sends one message with the proof, and that's it.