Requirements for Unlinkable Tokens for Fraud Prevention

[eriktaubeneck]

This is a break off from #41, specifically focused on the the requirements for using unlinkable tokens to prevent the submission of unauthorized (fraudulent) click reports. Summarizing the requirements from that thread:

1. Websites have the ability to participate in a protocol which can provide proof that they can trust the reports they later receive.
2. The reports sent from the browser (including any proof provided by /1) should be unlinkable to individual events.
3. Websites should only sign tokens when it's linked to a validated session/click.
4. The design should be as simple as possible:
   a. Simple for website developers to adopt and use
   b. Relatively easy for privacy experts to analyze
   c. To some extent, easy for browser engineers to implement.
   d. Avoid a solution that only works for websites with a large engineering team.

Other remaining open questions:

5. Does the unlinkable token need to be bound to the trigger_site as well as the source_site?
6. How often do keys need to be rotated?What is expected to happen if a client detects a key mismatch upon event upload?
7. What happens if the client's chosen nonce is not random? Does the solution depend on this being random, and if so, what assurance does the server have that the client generated this value honestly?
8. Does the protocol need to be compatible with the ability to work in the face of event-noising. See WICG/conversion-measurement-api#111
9. Does the protocol need to be compatible with the ability for this system to also work for aggregate reports (something like what is described in https://github.com/WICG/conversion-measurement-api/blob/main/SERVICE.md)

Given that there is limited time in the F2F, it seems useful to see if we can answer some of these questions async and spend that limited F2F time for the most difficult questions. cc @johnwilander, @csharrison, and @chris-wood, I've pulled these requirements and questions from your comments on #41.

[eriktaubeneck]

For question 7, unless I am misunderstanding something about the protocol, I believe that this needs to be random. The flow, as I understand the blind signature process is:

1. Client: Generate random nonce
2. Client: Blind(nonce), send to server
3. Server: Sign(Blind(nonce)), send to client
4. Client: Unblind(Sign(Blind(nonce)) -> Sign(nonce)
5. Client: wait for report, send with (Sign(nonce), nonce) to server
6. Server: Validate Sign(nonce) is a valid signature of nonce.

If the nonce is predictable, then the server would be able to effectively guess the nonce in Step 3, and if the server knows the nonce in Step 3, they can link a report sent in Step 5 back to the original signing request.

Please let me know if I'm potentially misunderstanding this. This is essentially the clarification/correction I'm proposing in #81.

[csharrison]

cc @davidvancleve

[hober]

cc @FredericJacobs