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

1) The crypto in this scheme is resilient against a bad actor on either side (preventing token forgery from the client and preventing loss of anonymisation from the issuer). The issuer would only be able to subdivide the users of that issuer based on the presence or absence of the token (and in the private metadata case, the value of that bit of information).

There are some issues that can occur if you are running a large number of issuers attempting to be malicious, where each issuer uses the bit of information they have to divide their userbase via different non-trust related metrics. Having a allow/block list that the UA supports would help mitigate this issue.

2) Depending on the use case, different numbers of bits may be reasonable. For the web anti-fraud use case, there are compelling arguments for having one bit (to avoid the presence of a token from telling a malicious actor they've successfully passed the fraud system/captcha/etc), beyond that each UA would need to consider the privacy/usecase tradeoffs carefully. This may interact with ideas such as a [privacy budget](https://github.com/bslassey/privacy-budget)

-- 
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-561325890