Following up this question
There are 4 parties:
- Alice, who needs to prove a posession of some statement $m$, unique to her, say a street address, which is basically a string of some predefined format, to
- Bob, who consumes the proof.
- an Oracle, who "helps" Alice to prove $m$ by performing some external checks and signing a tuple of ("Alice", $m$, timestamp)
- A good Samaritan Sam, who wants to help Alice prove statement $m$ because he actually owns it
Normal protocol flow is as follows:
- Alice says "I can prove some unique info about me" to Bob.
- Bob composes $m$ and asks Alice to prove it.
- Alice asks Oracle(s) to help her prove $m$.
- Oracle(s) do their magic and issue a signed tuple ("Alice", $m$, timestamp) to some online storage for using later.
- Alice shares the ID of the signed tuple to Bob.
- Bob fetches the tuple from online storage, validates Oracle's signature, timestamp and rewards Alice with whatever they agreed on.
Now, for the attacks:
If Alice does not posess $m$ she might want to ask Sam to pretend he is Alice and pass the Oracle check for her. She might share her "Alice" identity (we'll define it later) to him.
We want to prevent this or to at least make Alice's and Sam's life very difficult in case they collude.
One way of achieving this is to track the public key that signed $m$ each time and perform penalty if it changes.
So, we ask Alice to sign each statement with a special ephemeral key before sending it to an Oracle. This ephemeral key has to be derived from her master secret using KDF(master_secret,$hash(m))$ which she can prove to Bob using some sort of ZKP. So the only way for Alice to use Sam would be to share her master secret with him.
It also allows Alice to sign different statements without being doxxed by figuring out that $m1, m2, m3$ were proved by the same person
So, the question is, is there a simpler way of achieving these goals than doing complex ZKP for KDFs?