WICG / trust-token-api

Trust Token API
https://wicg.github.io/trust-token-api/
Other
422 stars 84 forks source link

Use case clarification: voting #63

Open johncrim opened 3 years ago

johncrim commented 3 years ago

I've read Getting started with Trust Tokens but have not reviewed other published documents in depth. One of the use-cases that is mentioned in this article is voting, and I'm confused about how this would work.

I'm assuming that this statement is a bit of an exaggeration (or at least requires qualification), since stronger "users only vote once" guarantees seem to require strong identity - without identity, a user could use different browsers/devices, and even in the same browser + device what's to prevent a user from using multiple tokens (can a redeemer site query for previously redeemed tokens?).

Does the trust token API only handle the question "is this a real user voting (not a bot)?" question, and not the "has this user previously voted on this topic?" question. Or is there a way to implement vote counts as well (within a single browser)?

Put another way, it seems like trust tokens could be used for Medium's "clap for this article" feature, but not for Microsoft's uservoice "vote for features or bug fixes". Correct?

dvorak42 commented 3 years ago

Yeah, you're exactly right. The Trust Token usage there is just for figuring out whether the user is real or not, there needs to be some separate mechanism for answering the voting-only-once question.

The idea being that a site can somewhat push off needing to determine the user being real to redeeming a token from a trusted issuer, rather than needing to run all its logic itself (really this is similar to the CAPTCHA being used as part of the 'voting' action).

FlantasticDan commented 3 years ago

I think there's a lot of value in being able to anonymously prove eligibility to vote whilst answering the vote-only-once question as well.

As I understand the Trust Token API now it's almost there as long as you're willing to setup a separate mechanism to handle identity and eligibility. For example, say I have users.example as an issuer and voting.example as a redeemer, and I want to my users to vote on something but I don't want any record of how each user voted. I could have users.example handle identity and issue a single Trust Token per user and then voting.example redeems that trust token before counting the user's vote. I believe this implementation would work with the API as it exists today.

But, if I wanted to scale this system up to have multiple groups of users each eligible for different polls I couldn't rely on Trust Tokens to ensure users only voted in polls they were eligible for. Similarly, if a single user was eligible for more than one poll, Trust Tokens wouldn't stop them from voting twice in a single poll instead of once in each poll.

This may be outside the goals of the Trust Token API but I think this use case could be facilitated if issuers were able to scope a trust token to specific redeemers, and if the enforcement of that scope was carried out at the browser level.