[ortichic]

Lots of bias in this thread. But maybe we can have a technical discussion?

I'm not into this topic, so maybe someone else can answer this: How "zero-knowledge" is this actually?

As far as I understand, there are three parties here: 1. Me, the user; 2. The site I want to access; 3. The attestor (google? my government?). What do they know about each other?

Does the site know who I am?

Does the site know who my attestor is (and therefore, for example, that it doesn't like Winnie-the-Poo memes)?

Does the attestor know what site or kind of content I want to visit (and therefore e.g. if he agrees with it)?

Does the attestor know who I am?

Do I always know who the site and attestor are, and when this proof happens?

[amwet]

I have some experience with zkp, so I’ll try to answer your question to the best off my ability. First on the terminology, the “attester” in this case I assume is whoever is anchoring the data or issued the credential you’re trying to prove. For the canonical example, let’s say you’re trying to prove age >= n via a government ID.

1. The site does not know who you are. This is the whole point. You generate a mathematical proof you possess a valid government ID that says “age >= n”

2. Yes. You are generating a zkp based on information anchored by the attester. In this case the ID issuing gov. That attester can be something other than a gov, but zkps are a bit useless if the site doesn’t know what exactly is being proved. In this case you are proving “I possess a government ID saying age >=n”. You must know about the government to care about this proof.

3. Not in this case. The attester only knows it has issued you an ID, but does not need to be further consulted. You could certainly construct a scheme such that you require a ZKP of recent written permission from some entity, but this is not inherent to ZKPs.

4. This is a UX question. If the ZK wallet and website are implemented in such a way that it’s always displayed when a credential is requested and what credential that is, then yes.

[oceansky]

Does the "attester" knows who is requesting the information?

Can they map which places requests which person?

[rocqua]

The attestor gives you a credential once. You can think of it as a dob (in e.g. days since 1900) with a digital signature.

Then when you want to access something age gated, you locally generate a proof that says “I have a credential signed by X, with DoB N, and N < CutOff date” where X and the CutOff date are public but the credential and the value N are hidden through the ZkP.

The attestor isn’t involved so doesn’t learn anything. The Verifier only learns the public information, and generally won’t be able to tell if two proofs are made with the same credential.

[rcxdude]

AFAIK, If the scheme is designed properly, then no. The attestor only knows who they have issued certificates to and the verifier only knows that they have a user that has been verified by that user. Neither the attestor or the verifier can link the two any further than that, even if they collaborate.

[sizero]

That depends on the setup but is not related to the ZKP part. “who is requesting the proof that person X has a gov ID where age >= N” is irrelevant in the context of the proof.

[mindslight]

There is an important question you haven't asked: As presented, is this system secure for the implied use cases?

And the answer to that is a resounding no. As long as you can run software of your choosing, then it is trivial to proxy a zero knowledge proof such that a third party can provide proof of the given property for you to use. If the system is really zero-knowledge, then that third party will suffer no repercussions for defeating the purpose of the system. And we can easily imagine people willing to provide this service (for ideological reasons and/or simply payment).

To be secure, all of these schemes rely on an unstated assumption of remote attestation that will prevent users from running their own software. Locking down computing is Google's basic agenda, but saying this would make the systems less appealing to people, so they obviously downplay it.

[rcxdude]

This is a big one, yeah. It looks like the current proposed system in the EU requires attestation that the relevant keys are stored in a certified HSM that will e.g. rate-limit the generation of keys.

(I found a list of requirements for them here: https://eudi.dev/2.4.0/annexes/annex-2/annex-2-high-level-re... )

[abricq]

I'm not an expert either, but i've studied it a little and tried some of these stuffs.

First, the attestor is not google. Google here only provides the infra (to generate proof and verify them). Let's call the attestor the issuer, and it's the trusted authority that gives you a proof of identity.

A possible flow is:

1. (pre-req) Some issuer (a state, bank, mobile operator, etc.) issues a signed credential to my wallet (stored on my phone, for instance). This could be a full digital ID, or a narrower “proof of age” attestation.

2. Later, a site asks my browser for a proof that I satisfy some predicate, e.g. age >= 18. The site provides the "zk-program" (circuit) that needs to be executed, and awaits for proof (which are essentially proof of executions of the program on trusted yet undisclosed inputs).

3. My phone generates (ideally locally, but not ready today yet) a ZK proof that it knows a valid issuer-signed credential whose hidden attributes satisfy that predicate. Essentially, it is executing the circuit with some inputs (some are public, like public key of issuers, some of private, like the issued ID)

4. The site verifies the proof against public inputs: the issuer public key, the circuit being used, the predicate being requested, and a fresh nonce/challenge.

So to answer some of your questions.

> Does the site know who I am? Not from the ZK proof itself, it will know who has issued your ID.

> Does the site know my attestor? Yes, it knows their public key.

> Does the attestor know what site I am visiting? No.

> Does the attestor know who I am? Yes

> Do I know who the site and attestor are, and when proof happens? I guess there are multiple possible ways to do this, depends on the UX.

[hoppp]

Its not really possible to know.

the system is valid zkp but any of the services in practice can still collect personally identifiable information from their users.

There is also nothing stopping the attestor to collude with the site you want to access, to reveal information about you.

[rcxdude]

If you are controlling the middle part of the zkp (or at least can validate it), then identification should not be possible through the zkp even if the attestor and and site collude with each other (they could maybe collude based on some other information, like IP address or browser fingerprinting, ofc).

[hoppp]

I think if google provides the attestation and they also provide a client side dependency for the site, then they can collect all the data they want.

Also, nothing stops a site from having a flow like: 1. Please enter your age 2. Verify that it's correct using a proof

The zkp is valid as far as the tech is concerned but the sites can still do whatever they want.

[rcxdude]

Yeah, if the entities share data they'll share data, but ZKPs give a way to, in principle, verify that they cannot link two parts of that together by doing the verification. I'm not sure I understand your flow example though. If they ask you to enter an age, but will accept a zkp that you're over 18, then you could enter any age over 18 in the first part and they would have no way of knowing.

[ongy]

I tried to find something definitive, but it would take more time than I have right now. So to some degree this is assumptions, though generalized.

* Does the site know who the user is: No. That's the entire purpose here.

* Does the site know who the attestor is: Yes, they need to validate asymmetric crypto on the proof, so they need a list of public keys (which they can attach attestor identity to).

* Does the attestor know what kind of content I want to visit: They should not. With the JWT you can validate without telling the attestor which user's proof you validate. OTOH, if there's some "is this one revoked" type of API one could easily re-introduce such an information channel on accident.

* does the attestor know who the user is: Yes (or at least have some bits of information about you they are willing to attest to others. In practice assume it's Google/Apple/MS with information associated with your account, or your bank or ...)

* Does the user always know site/attestor: From a technical perspective yes. From a practical human one... doubtful.

--Googler, though far removed from this project, so no internal knowledge.

[mohsen1]

Computer Scientist Explains One Concept in 5 Levels of Difficult

https://www.youtube.com/watch?v=fOGdb1CTu5c

This video is very beautifully explains it