View source for DECODE/DEC01 use case

= Use Case ID - Use Case title =

DEC01 -  Online voting platform with privacy

= Owner of Use Case = 

Stefano Bocconi - DECODE project

= Description =
The DECODE project is extending an existing online voting platform according to the principles of data minimisation and data ownership and sovereignty. This implies that:

* Users can vote anonymously. The only requirements to be able to vote are a proof of residence in the city where the poll is open and of being older than a certain age.
* Users must be able to vote at max once, but can change their vote.
* Votes must be registered and kept for accountability of the voting process.
* Users can decide, for the public good, to reveal additional attributes so that the results of the vote can be better analysed, such as per age range, gender, area of residence, etc.
 
== Is Sub-Use Case of ==
 
== Has Sub-Use Cases ==

= Requirements =

== Related functional requirements ==
* Eligibility for voting is based on and must be determined based only on two conditions: the user is resident in the area of the poll and the user is older than the minimum age to vote
* Each vote must be recorded so that final poll result can be calculated, without revealing the user identity
* The process must be verifiable for correctness by any party (transparency)
* Users can share more attributes than required to allow more analysis of the results

== Related non-functional requirements ==

== Requirement conflicts (if any) ==
 
== Requirement similarities (if any) ==
 
== Requirement subsets/refinements (if any) ==
 
= Component(s) =
* A digital wallet that each user has, containing verified attributes such as name, age, residency, etc.
* An authorisation system that requires particular verified user attributes to allow access (in this case to the voting system)
* A trusted authority (such as a municipality) that certifies the authenticity of (some of) the user attributes contained in the wallet
* A Distributed Ledger that records each vote.

= Types/classes of data involved =
* User attributes
* Votes
 
= Actors =
* A local municipality or other instances that want to put out a public poll
* Users that might want to participate in the poll
* A certifying instance (such as the same local municipality) 

= Preconditions =
* Users have (installed) a wallet
* Polling system supports attribute-based authorisations
* Users have means to certify their attributes
 
= Postconditions =
* Polling can be verified by any party for correctness. 
 
= Normal Flow =
* User interacts with a trusted authority that certifies (digitally sign) particular attributes of the user, such as residency and age
* User records these attributes in their digital wallet
* Local municipality publishes a public poll
* User is authorised to vote in the polling system by allowing their wallet to share the required attributes with the polling system (residency and age)
* User votes
* (Optional) User changes their vote
* (Optional) User shares their age range, gender, neighbourhood, etc.
* Local municipality closes the poll and calculates the results.
* Any party can verify the results of the poll

= Alternate Flows =  
* User interacts with a trusted authority that certifies (digitally sign) particular attributes of the user, such as residency and age
* User records these attributes in their digital wallet
* Local municipality publishes a public poll
* User is not authorised to vote in the polling system because:
** They do not allow their wallet to share the required attributes with the polling system (residency and age)
** They do not possess the correct attributes

= Evaluation of UC and requirements realisation =
(e.g. manual, automatically...)

= Categories of personal data involved =

* Attribute stating holder is resident of the city where the poll is held.
* Attribute stating holder possesses legal age to cast vote.

These attributes are cryptographically signed by an authority such as the municipality. 
These attributes are likely also not stored, they are used to access the poll only.

No other data such as name, date of birth, etc is necessary. 

The vote is stored on a public blockchain, and it is signed by the private key of the voter.

Optionally, the voter can decide to "donate" other personal data such as gender, neighbourhood, etc to aid the analysis of the vote.

= Purposes for personal data handling =

The purpose of the processing for the necessary attributes  is to assess whether the holder of the credentials has the right to cast a vote or not.
In  theory the data does not need to be stored, as it is an authorisation process.

On the other hand, the voter must vote at max once and can change their vote, so some storage of data can be required to guarantee those properties.

Since the voter can decide to donate other personal data to aid the analysis of the vote, additional personal data as mentioned in the previous paragraph will be used to get insights in the results of the poll.

= Different kinds of processing involved =

There is an authorisation process that verifies that:

* the digital cryptographic signature of the attributes is valid
* the attributes have the required values, i.e. resident of the city where the poll is held and legal age to vote

Once the vote is cast and the poll is closed, there is a process to count the votes.

There should also be a processing that verifies that each voter votes at max once, and that they can change their vote until the poll closes.

For the optional personal data items, very likely standard statistics will be used. This statistics will be applied to aggregated data and therefore not to be considered to be personal data.

= Data subjects, controllers, processors, and recipients involved =

The data subjects are the citizens of legal voting age of a particular city.

Since the vote is anonymous and public (the vote is recorded using a public blockchain), there is no need to specify recipients for the vote.

Regarding the attributes, the data controller is the municipality, data processors should not be applicable here.

For the optional personal data items, again the controller is the municipality, this data is aggregated and might not be in the form of personal data anymore.

= Storage & security aspects =

Public vote and aggregated personal data will likely be kept forever for legal reasons. This should happen under the control of the municipality.

Attributes used to authenticate the voting process might be discarded, if legally this is admissible, or kept for the period of time in which the poll can be legally challenged.

All this data is not directly linked to a person, so we can say that it is at least in pseudonymisation form.

= Means of legitimation for personal data processing =

For attributes required for authorisation, the ground should be legal obligation of the municipality.

For the optional attributes it should be an informed consent.