Re: [w3ctag/design-reviews] Trust Token API (#414)

Hello! @hober and I discussed this at our [face to face](https://github.com/w3ctag/meetings/blob/gh-pages/2019/12-cupertino/README.md) in Cupertino.

Two main points from us: 

1. What happens if the issuer is a bad actor?

This design only works in the way you've intended if the issuer is properly anonymising and randomising the tokens. What happens if the issuer isn't a trustworthy organisation?

And since the user has no role in selecting the issuer, the user then gets no say in who that might be. If we end up with an ecosystem of dodgy issuers, can the user protect themselves?

It seems like this could be mitigated by an approach like the one in [Web Payments](https://w3c.github.io/payment-request/#introduction), where the browser keeps a set of payment methods that the user is happy with. The shopping site has a list of payment methods it supports. At purchase time the site supplies its options; the browser picks from those. This is a nice quality: the user agent has a role in choosing. This is the role of the user agent.

We recognise that users can't express their preferences on advertisers at all. Could a similar approach work here?


2. We're concerned about the potential for trust tokens to be used as categories to identify or describe the users.

You've written in the explainer:

> The issuer can store a limited amount of metadata in the signature of a nonce by choosing one of a set of keys to use to sign the nonce and providing a zero-knowledge proof that it signed the nonce using a particular key or set of keys.

You say it's a limited amount of metadata: how many bits? Even a small number of bits could be risky with certain bad issuers.

We'll open issues in your github repo; these notes are here so that we have them.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/414#issuecomment-561320057