Yes it does. Not fully trustlessly, but trust (in ZKorum) is still minimized. For the email-based functionality: - 1 community email address (= "uid") = 1 community credential issued by ZKorum. For the external community credential (e.g,: issued by your college or company): - your credential's unique college/company ID ("uid") can only be registered to one unique ZKorum account. You'd generate a proof with a deterministic pseudonym (Pedersen commitment) based on your "uid" attribute when associating the credential to your User Profile. Note that the User Profile is unlinkable with the user posts. For both use-cases: - One and only one "timebound" Secret Credential is issued to each user. Each poll expects a pseudonym generated from {scope+secret+uid}. Scope is a public value that's specific to each poll. "secret" is an attribute of the Secret Credential, and "uid" is an attribute of the community credential. Both are unique per user. A unique set {scope+secret+uid} deterministically generates the same pseudonym. So there is only one pseudonym per user per poll. That's how the server counts results to a poll. Note that knowledge of a pseudonym does not give knowledge of "secret" or "uid". And "secret" is only known by the user's device, so even the Issuer that knows "uid" cannot know who's behind the pseudonym. That's why it's anonymous, with privacy in the hand of the user. So long as the "secret" remains private in the user's device, anonymity is guaranteed, even when the proof is made public. - in case of revocation of "timebound" Secret credential on recovery when the user devices are lost, the user cannot respond to polls that were created before the recovery was initiated. That's because the user lost the unique "secret" attribute together with the credential, so the user's new "timebound" Secret Credential won't hold the same "secret" as attribute. This mechanism prevents malicious users from responding multiple times to the same poll after they recovered their account. That's why there are two "Secret Credential" per user: the "timebound" is only used for responding to polls or votes, and the "unbound" is used for everything else. The "unbound" Secret Credential is not subject to this condition on recovery. Feel free to join our Discord community if you have more questions.
Does this ensure a user voted only once?
Yes it does. Not fully trustlessly, but trust (in ZKorum) is still minimized.
For the email-based functionality:
- 1 community email address (= "uid") = 1 community credential issued by ZKorum.
For the external community credential (e.g,: issued by your college or company):
- your credential's unique college/company ID ("uid") can only be registered to one unique ZKorum account. You'd generate a proof with a deterministic pseudonym (Pedersen commitment) based on your "uid" attribute when associating the credential to your User Profile. Note that the User Profile is unlinkable with the user posts.
For both use-cases:
- One and only one "timebound" Secret Credential is issued to each user. Each poll expects a pseudonym generated from {scope+secret+uid}. Scope is a public value that's specific to each poll. "secret" is an attribute of the Secret Credential, and "uid" is an attribute of the community credential. Both are unique per user. A unique set {scope+secret+uid} deterministically generates the same pseudonym. So there is only one pseudonym per user per poll. That's how the server counts results to a poll. Note that knowledge of a pseudonym does not give knowledge of "secret" or "uid". And "secret" is only known by the user's device, so even the Issuer that knows "uid" cannot know who's behind the pseudonym. That's why it's anonymous, with privacy in the hand of the user. So long as the "secret" remains private in the user's device, anonymity is guaranteed, even when the proof is made public.
- in case of revocation of "timebound" Secret credential on recovery when the user devices are lost, the user cannot respond to polls that were created before the recovery was initiated. That's because the user lost the unique "secret" attribute together with the credential, so the user's new "timebound" Secret Credential won't hold the same "secret" as attribute. This mechanism prevents malicious users from responding multiple times to the same poll after they recovered their account. That's why there are two "Secret Credential" per user: the "timebound" is only used for responding to polls or votes, and the "unbound" is used for everything else. The "unbound" Secret Credential is not subject to this condition on recovery.
Feel free to join our Discord community if you have more questions.