An interesting new multi-authority selective-disclosure credential scheme called Coconut has been recently released, which has the potential to enable applications that were not possible before. Selective-disclosure credential systems allow issuance of a credential (having one or more attributes) to a user, with the ability to unlinkably reveal or “show” said credential at a later instance, for purposes of authentication or authorization. The system also provides the user with the ability to “show” specific attributes of that credential or a specific function of the attributes embedded in the credential; e.g. if the user gets issued an identification credential and it has an attribute x representing their age, let’s say x = 25, they can show that f(x) > 21 without revealing x.
A particular use-case for this scheme is to create a privacy-preserving e-petition system. There are a number of anonymous electronic petition systems that are currently being developed but all lack important security properties: (i) unlinkability – the ability to break the link between users and specific petitions they signed, and (ii) multi-authority – the absence of a single trusted third party in the system. Through multi-authority selective disclosure credentials like Coconut, these systems can achieve unlinkability without relying on a single trusted third party. For example, if there are 100 eligible users with a valid credential, and there are a total of 75 signatures when the petition closes, it is not possible to know which 75 people of the total 100 actually signed the petition.
The motivation behind this feature is to help prevent petitions from being vulnerable to corruption or interference, and help provide a fairer result for the participants. As seen with the events happening in Barcelona, a censorship-resistant feature could have been useful to prevent corruption or seizing of specific ballot boxes; our e-petition system is censorship resistant as long as enough authorities are honest. Hiding the metadata regarding who voted for whom, would be useful in such a scenario as well. Also, unlinkability is preserved, even if all authorities collude to try and breach a user’s privacy (i.e. providing perfect ballot secrecy).
The architecture consists of 3 types of parties, the client/user, the signing authorities, and the petition owner/creator, as seen in the figure below. Note that for use with a blockchain, the ledger acts as a layer between the user and the authorities or the petition owner/creator communications.
Implementation & Demo
First, the client must obtain a valid credential from the authorities by clicking on the blue button shown below. In practice, a user would prove their identity manually or by showing a picture of valid identification (similar to how an account on cryptocurrency exchanges is created).
Next, when the client gets their credential, they must locally randomize it so that they will not be to be linked to their identity when showing/using the credential to vote.
When the credential is randomized, an input form appears, where the user is able to input the petition ID (the unique identifier of the specific petition) and whether they would like to vote for or against.
For more information, please see the Coconut paper. My code is available under an open-source license with a branch at the stage where the general Coconut system was ready in order to be used as an open source template.