Data entitlements, licences and privacy by design in DECODE: a first design case study

The DECODE project aims to empower users accessing services and civic infrastructures with finer control over the dissemination and use of their personal information. Our principles are that sharing information, to contribute to collective decision making, can be beneficial to all, but also that it has to be done on the basis of users’ consent, and providing gradual options in terms of protecting privacy. In this short blog post, I will outline our first design – for an electronic petitions site – and use it to illustrate the technologies underlying DECODE privacy controls, as well as the architectures that enable this vision.

Our first pilot design, involves a city electronic petitions system, on which citizens may post a petition; may show approval or disapproval for a posted petition; and that allows the public as well as civic organizations to get a sense of the overall support, as well as support within certain demographics or localities in the city. We are keen to clarify that this is not a full binding electronic voting system – which would require very strong receipt freeness. Yet, petitions can be very important vehicles for civic debate to inform policy-making.

The architecture of the DECODE e-petitions system follows closely a distributed application based on a smart contract. The petitions smart contract supports users posting petitions, and posting their views on them. It runs on a distributed set of DECODE nodes coordinated by the Chainspace smart contracts platform, that we designed specifically for the purposes of the project. Using a transparent distributed ledger to execute the petitions contract provides a number of advantages: everyone may view the dataset of posted petitions and support; everyone may audit that their view was taken into account; and everyone may check that that the results relating to the degree of support are correct.

However, using distributed ledgers to host such a petition also comes with serious privacy challenges: all DECODE nodes in the infrastructure, and the public at large, has access to a full record of all petitions posted and the support their received as such, the contract has to implement advanced cryptographic mechanisms to ensure both correctness as well as privacy. In particular no personal information can appear “in the clear” on the distributed ledger.

To support privacy we use two key technologies, to support privacy friendly attribute authentication, and privacy friendly aggregation of support:

• Homomorphic Encryption: Instead of users posting their support or lack of support for a petition in the clear, they do so in an encrypted manner. As a result, an observer can observe someone interacting with a petition, but cannot discern if an action on a petition represents support or not. The encryption scheme used is homomorphic – which means that different encrypted messages can be aggregated by authorities to get an overall picture of how many people agree or disagree with a petition, without anyone decrypting individual preferences. This enables aggregate “wisdom of the crowd” statistics – without compromising individuals’ views.

• Attribute Based Credentials: It is important to ensure that petitions are signed only by a relevant constituency – but requiring citizens’ of a city to authenticate themselves in the clear would link their real identities to a particular action related to a petition. To avoid this we use attribute based credentials (ABC): such an ABC is issued by the city authorities attesting that a user is a citizen of a city as well as having some other demographic attributes – such as age or location. To express an opinion on a petition, a user has to prove they are a citizen, and optionally disclose some of their demographic attributes. ABCs ensure that only this information is revealed, without linking the user to any other long term identifier.

The two mechanisms work well in conjunction with each other: it is possible, for example, to aggregate all responses to a petition by some demographic, in order to understand the degree of support per age or location in a city. At the same time, each record in the distributed ledger is proven authentic by the use of an ABC – without linking it to a unique person – and the actual opinion besides general demographics is only disclosed in aggregate.

This initial petitions smart contract illustrates the privacy by design approach of DECODE. We only disclose a minimum amount of information; de-identify it as early as possible; only require minimal attribute based authentication; allow the user to choose what they disclose; and release data in an aggregate form where possible. In its simplest form petitions realize a user providing an entitlement to the community to gather an opinion.

More advanced forms of data entitlements are also possible, and we might consider them as part of of further pilots. For example, instead of disclosing an attribute in clear when supporting a petition, a user may choose to encrypt to to a specific organization. The organization, in turn can produce more fine-grained demographic aggregates of support and publish those. In extremis one could use a smart contract as well as ABC to encode complex rules about who can have access to specific data, and use encryption to ensure only authorized parties get access. However, details on how to best do those depend on the maturation of the pilots, and we will be writing further posts describing them in detail.