DECODE Whitepaper v1.0

Denis Roio Francesca Bria James Barritt

Jaap-Henk Hoepman Mark de Villiers Priya Samuel

George Danezis Tom Demeyer Shehar Bano Oleguer Sagarra

Monday, 29 January, 2018

Abstract

Today’s Internet and digital platforms are becoming increasingly centralised, slow-

ing innovation and challenging their potential to revolutionise society and the economy

in a pluralistic manner. The DECODE project will develop practical alternatives,

through the creation, evaluation and demonstration of a distributed and open archi-

tecture for managing online access and aggregation of private information to allow a

citizen-friendly and privacy-aware governance of access entitlements. Strong ethical

and digital rights principles are at the base of DECODE’s mission, moving towards

the implementation of open standards for a technical architecture resting on the use

of Attribute Based Cryptography, distributed ledgers, a secure operating system and

a privacy focused smart rules language.

Contents

Abbreviations 4

Outline 6

Introduction to DECODE 6

What is DECODE and why is it important? . . . . . . . . . . . . . . . . . . . . 6

The goals of DECODE: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

History and current state of the art . . . . . . . . . . . . . . . . . . . . . . . . . 7

Architectural principles 9

Free and open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Modularity and interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Reuse don’t re-invent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Decentralisation and federation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Privacy by design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Privacy design strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

User friendliness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Conceptual foundations 12

Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Attribute provenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Attribute veriﬁcation with ABC . . . . . . . . . . . . . . . . . . . . . . . . 18

Entitlements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Entitlement policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Implementation (access control) . . . . . . . . . . . . . . . . . . . . . . . . 22

Distributed ledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Querying the ledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Operating system architecture 28

Process separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Privilege escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Security implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Technical implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Political implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Application modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Smart-rules engine 33

Language Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Syntax-Directed Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Satisﬁability Modulo theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

DECODE architecture 36

Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Validating Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Wallets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

The ledger implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chainspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Smart rules engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Operating system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Hardware Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Keys and smart cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

IoT connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

DECODE applications 46

What is a DECODE application? . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Example - participatory democracy through petitions . . . . . . . . . . . . . . . 46

Example - participatory citizen sensing (IoT entitlements) . . . . . . . . . . . . 48

Example - peer to peer identity and reputation veriﬁcation . . . . . . . . . . . . 49

Example - digital commons and open data . . . . . . . . . . . . . . . . . . . . . 50

Conclusion 52

DECODE Glossary 53

Bibliography 58

Abbreviations

2FA - 2 Factor Authentication

3FA - 3 Factor Authentication

ABC - Attribute Based Credentials

ABE - Attribute Based Encryption

AI - Artiﬁcial Intelligence

AWS - Amazon Web Service

BFT - Byzantine Fault Tolerance

BLE - Bluetooth Low Energy

CRUD - Create Read Update Delete

DECODE - DEcentralised Citizen-owned Data Ecosystems

DRM - Digital rights management

EA - Early Access

ELF - Executable and Linking Format

EVM - Ethereum Virtual Machine

FST - Flying STone

GDPR - General Data Protection Regulation

GNU - GNU’s not Unix

HMPO - Her Majesty’s Passport oﬃce

ICT - Information and Communications Technology

IP - Internet Protocol

IPFS - InterPlanetary File System

IRMA - I Reveal My Attributes

IoT - Internet of Things

JSON - JavaScript Object Notation

JSON-LD - JavaScript Object Notation for Linked Data

JWT - Json Web Token

NGO - Non-governmental organization

OCR - Optical Character Recognition

OS - Operating System

OSHWA - Open Source Hardware Association

PbD - Privacy by Design

POSIX - Portable Operating System Interface

RBAC - Role Based Access Control

RFID - Radio-frequency IDentiﬁcation

SDK - Software Development Kit

SNARK - Succinct Non-interactive ARgument of Knowledge

SSO - Single Sign On

URN - Uniform Resource Name

U2F - Universal 2nd Factor

XML - Extensible Markup Language

ZK - Zero Knowledge

Outline

This document describes the design of the DECODE (https://decodeproject.eu/) architec-

ture.

It provides an overview of what DECODE is, why it is important and how it relates to the

landscape of decentralised applications. It reviews the conceptual foundations on which

it is built and how they combine to achieve its purpose. It describes at a high level the

core components of the architecture and what role they play and ﬁnishes with illustrative

examples of how it can be applied in the real world.

Introduction to DECODE

What is DECODE and why is it important?

DECODE (DEcentralised Citizen-owned Data Ecosystems) is an experimental project to

enable practical alternatives to how we manage our personal data and interact on the

internet. DECODE will develop technology that puts people in control of their personal

data, giving them the ability to decide how it is shared.(Tom Symons, 2017) The current

models of data sharing enable service providers to collect citizens’ data in exchange for

services. Given the high value of this data to service providers, a vast number of them

appropriate data to create value without providing people with a comparable compensation.

DECODE focuses research and development eﬀort on novel notions of trust and privacy

that can be operationalised in new governance frameworks, and innovative economic models

based on digital commons. The digital commons are a form of commons involving the

distribution and communal ownership of informational resources and technology (Fuster

Morell, 2014). Resources are typically designed to be used by the community by which

they are created. In particular, the distinction between digital commons and other digital

resources is that the community of people building them can intervene in the governing of

their interaction processes and of their shared resources (Eleonora Bassi, 2017).

In DECODE, Entitlements attached to private data will be searchable in the public domain

but will grant access only to those parties that have the entitlement to access it. This novel

concept of data rights and entitlements also applies to data being sent to or consumed by

connected IoT objects in order to perform actions on the real world, allowing citizens to

manage and control their devices and the data they generate.

DECODE enables participants to choose who they share their data with and what data is

being shared with the recipient. The aim of DECODE is to provide state of the art tools

to give people better control of their data on the internet. The project will contribute

to enabling a free and open digital commons into which people can share their data in a

secure and anonymous way. This will mean that all of society can beneﬁt from the insights

that can be gained from data.

The project will develop and test a free, open source, distributed, privacy aware, and

trusted technology architecture for decentralised data governance and identity management.

(Symons, 2017)

Figure 1: Digital commons

The goals of DECODE:

We identify the following key goals for DECODE:

•

allow participants to manage access to their private data, by granting and revoke

access through entitlements

•

allow operators to write smart rules sign them and get the authorisation to run them

on DECODE

•

allow smart rules to access private data based on entitlements and matched attributes

•

allow everyone to record entitlements on a distributed ledger whose integrity is resilient

and veriﬁable

History and current state of the art

Decentralised technology ecosystems have been around for decades, and more recently

there has been an explosion of decentralised platforms powering the rise of cryptocurrencies.

In 2008-09, Satoshi Nakamoto implemented the ﬁrst decentralised currency combining

advancements in public key cryptography with a consensus algorithm widely known as

“proof of work”. This was a breakthrough in building a completely decentralised ecosystem

that was centred around the transfer of ‘assets’ from one individual to another. Since then,

there have been several advancements in using blockchain for creating both fungible and

non-fungible assets.

Ethereum (Buterin, n.d.) provides a blockchain implementation that can be used to

encode arbitrary state transitions, enabling it to be used as a decentralised ‘back-end’

for applications. Ethereum takes the very speciﬁc distributed application of bitcoin and

generalises it to provide a massively decentralised computing infrastructure. Nodes in

the network execute decentralised applications via “Smart Contracts” and record the

state transitions on a public blockchain. These smart contracts are executed through a

computing virtual machine called the “Ethereum Virtual Machine” (EVM).

Monax (published on the hyperledger project as Burrow) is an open platform for developers

to build, ship, and run blockchain-based applications. It provides an abstraction over the

underlying ledger techology and by default includes the Tendermint ledger engine and the

Ethereum Virtual Machine. Tendermint have also released a combination of these called

Ethermint which eﬀectively allows ethereum applications to run on Tendermint. Public

ledgers such as Ethereum are both anonymous and permissionless systems, i.e any user

can run validating nodes, and the inherent nature of the cryptography that is the basis for

mining determines that an attacker would need to control more than 50% of the network.

The decentralised and distributed nature of the network combined with the cost of proof

of work, forms the basis of its trust model.

Identity on the internet has evolved from being implemented as centralised silos to federated

identity models. Federated identity enables single sign on available across several large

service provider platforms. Service providers continue to be data controllers, in both

centralised and federated models. Sovrin (Drummond Reed, 2016) is a blockchain based

identity platform, providing the user control, security, and portability.

DECODE is an evolution of the concept of decentralised systems which leverages state

of the art cryptographic techniques such as Distributed Ledgers and Attribute Based

Credentials to build a system that provides its Participants the capability to store data

securely, give control and transparency over with whom and for what purpose data is

shared and transact with other participants or organisations.

At a high level we can describe DECODE as being composed of the following:

• a set of speciﬁcations for distributed ledgers to support decode

• a free and open source reference implementation of a distributed ledger

• a smart rule language that can be translated and graphically represented

•

a GNU/Linux based operating system that can execute signed smart rule applications

•

the documentation needed for operators to write and deploy smart rules that request

access to private data

•

an intuitive graphical interface for participants to allow smart rules to access their

private data

• an ontology of attributes for private data that is aggregated by operators

• an attribute based cryptographic implementation that can grant access to data

Architectural principles

DECODE is composed of both hardware and software components - each component will

adhere to the core architectural principles described below. The underlying philosophy

adopted is that of the Unix philosophy (Raymond, 2003) following key principles of modu-

larity, clarity, composition, separation, simplicity, parsimony, transparency, robustness,

representation and least surprise.

Free and open source

All work produced by DECODE will be published as free and open source according to

licenses approved by the Free Software Foundation Europe and emerging open hardware

standards. The openness of the platform will enable innovation and citizen participation.

DECODE adopts free software, however free software projects cannot be entirely considered

as digital commons. As a matter of fact, writing a code and publishing it with a free

license are not suﬃcient conditions in order to realize a free software. There are other

necessary conditions, among them:

• the reputation inside the community

•

the adoption of the good practices diﬀused in the community (for instance public

repository, - continuous free upgrading, an eﬃcient system of bugtrack and feedback

the quality of the code, including its documentation to allow understanding of the

code;

•

the software’s coverage, as the presence of automatic tests for evaluating the absence

of bug on high percentages in the written code. (Eleonora Bassi, 2017)

Modularity and interoperability

Adopting the key unix principle of modularity (simple parts connected by clean interface),

enables building independent components which can be reused and combined to form a

ﬂexible eco-system of software products. DECODE will develop modular privacy-aware

tools and libraries that integrate with the operating system backed by a state of the art

blockchain infrastructure supporting smart contracts and privacy protections.

DECODE will adopts a layered architecture, with components that build on top of each

other. As opposed to building privacy aware applications solely in the application layer

(layer 7) of the Operating System, privacy will be built into the lower layers as well, such

as transport, network and data-link layers.

Reuse don’t re-invent

DECODE aims to be built upon the solid foundations of existing well proven software

wherever appropriate. For example, “DECODE OS” is based on the well known and solid

Debian OS.

Decentralisation and federation

The current era in technology has seen a shift from large monolithic systems to distributed

decentralised systems, this is to meet the requirements of system - scaling, resilience and

fault tolerance but also provides for decentralised governance models. DECODE builds

upon decentralised models for data and identity management.

Privacy by design

DECODE aims to develop a privacy preserving data distribution platform to foster

commons-based sharing economy models, where citizens own and control their data. This

asks for a privacy by design based approach, for which the concept of privacy design

strategies have recently been developed.(Jaap-Henk Hoepman, 2017)

The General Data Protection Regulation (GDPR), as well as other data protection or

privacy protection laws and regulations, deﬁne data protection in legal terms. These terms

are soft, open to interpretation, and highly dependent on context. Because of this inherent

vagueness, engineers ﬁnd such legal requirements hard to understand and interpret. The

GDPR also mandates privacy by design, without describing clearly what this means

exactly, let alone giving concrete guidelines on how to go about implementing privacy by

design when actually designing a system. Intuitively, privacy design means addressing

privacy concerns throughout the system development lifecycle, from the conception of a

system, through its design and implementation, proceeding through its deployment all

the way to the decommissioning of the system many years later. In terms of software

engineering, privacy is a quality attribute, like security, or performance. To make privacy

by design concrete, the soft legal norms need to be translated into more concrete design

requirements that engineers understand. This is achieved using privacy design strategies.

Software can however enable or hinder an organisation in achieving GDPR compliance.

As DECODE is designed with privacy in mind from the ground up it naturally aﬀords a

good foundation DECODE will provide transparency for participants about exactly where

their data is and with whom it has been shared which will also enable GDPR compliance.

Further, many of the privacy by design principles will correlate with needs of GDPR

compliance, for example right to be forgotten.

Privacy design strategies

As described in (Michael Colesky, 2016) a privacy design strategy speciﬁes a distinct

architectural goal in privacy by design to achieve a certain level of privacy protection.

It is noted that this is diﬀerent from what is understood to be an architectural strategy

within the software engineering domain. Instead our strategies can be seen as goals of the

privacy protection quality attribute (where a quality attribute is a term from software

engineering describing non-functional requirements like performance, security, and also

privacy). In the description of privacy design strategies we frequently refer to processing of

personal data. Engineers should be aware that the legal concept of processing is broader

than what a typical engineer understands processing to mean. In what follows we use the

legal interpretation of processing, which includes creating, collecting, storing, sharing and

deleting personal data.

The eight PbD principles proposed for DECODE are:

(1) Minimise: Limit the processing of personal data as much as possible.

(2)

Separate: Prevent correlation of personal data by separating the processing logically

or physically.

(3)

Abstract: Limit as much as possible the amount of detail of personal data being

processed.

(4)

Hide: protect personal data, or make them unlinkable or unobservable. Prevent

personal data becoming public. Prevent exposure of personal data by restricting

access, or hiding its very existence.

(5)

Inform: provide data subjects with adequate information about which personal data

is processed, how it is processed, and for what purpose.

(6)

Control: provide data subjects mechanisms to control the processing of their personal

data.

(7)

Enforce: commit to a privacy friendly way of processing personal data, and enforce

this.

(8)

Demonstrate: provide evidence that you process personal data in a privacy friendly

way.

User friendliness

Building user-friendly tools and applications for end-users, and app developers for easy

adoption is a core principle for DECODE. Using an outside in lean approach, where

requirements from users’ are researched and analysed, and prototypes are tested on target

community groups will allow DECODE to develop open, interactive and user friendly

interfaces.

Conceptual foundations

This section describes the foundational concepts that are combined to achieve the purpose

of DECODE.

DECODE is built upon several foundations:

• Decentralisation of trust

• A distributed ledger

• Zero knowledge proofs

• Attribute Based Cryptography

• Cryptographically veriﬁable entitlements

• A “Smart Rules” language to express governance of participants data

• A highly veriﬁable and controlled execution environment

A key concept behind DECODE is to build a system which aims towards a model of

decentralised trust. This means that as much as possible, the control over the system

should not be in the hands of a small number of entities over whom the participants of

the system have no inﬂuence or recourse. For example, even though Bitcoin began life as

a model for decentralisation, the current state is that the hash power is controlled by a

few large mining pools. DECODE will seek to explore alternative, decentralised models

and economic incentives (See section on Distributed Ledgers).

A distributed ledger with decentralised governance provides a public, resilient, tamper-

resistant and censorship resistant record which allows any party to be able to verify some

“fact” recorded within it. This veriﬁcation is demonstrable through the use of cryptography.

The public nature of the ledger is in tension with a desire to maintain the privacy of the

participants of the network. DECODE applies the concept of Zero knowledge proofs to

allow the cryptographic proof of a transaction to be recorded in the ledger without needing

to publicly record the data within the transaction itself.

In addition to the participant’s transactional data, a key element of privacy is to allow

a strong control over data which is directly related to Identity. In DECODE all data is

represented as Attributes. DECODE takes an approach to identity which states that what

a participant discloses about their identity should only be related to the minimum transfer

of information required for a particular interaction. Further, this transfer of information

should occur through a privacy preserving mechanism.

The cryptographic implementation of this mechanism is Attribute Based Credentials. This

mechanism allows a participant to prove something about themselves without transferring

any other identifying information to the relying party (The entity that requires proof).

Underlying this selective disclosure mechanism is often a Zero knowledge protocol to

allow for multi-show unlinkability. For example a participant can cryptographically prove

their residency of a particular city without exposing sensitive information such as data

of birth, national Id number, or the actual address. This mechanism can also be used to

provide strong guarantees about authenticity of an interaction whilst preserving a level of

individual anonymity, particularly relevant for scenarios of participatory democracy.

Building on its veriﬁable public record and privacy preserving cryptography and design,

DECODE adds a mechanism for participants to declare and enforce agreements about how

their data is consumed. DECODE refers to this mechanism as the entitlements a participant

agrees to over their data. These entitlements are cryptographically veriﬁable and can be

extended to be cryptographically enforceable through Attribute Based Encryption.

We can extend this data sharing capability to datasets for wide sharing - for example we

can consider individual contributions to an aggregate dataset. This is often called the

Digital Commons (Eleonora Bassi, 2017).

Based on the principle of User Friendliness, giving participants access to a means to express

and understand these entitlements is a further aim of DECODE, which is expressed through

the development of a Smart Rules language and user interface.

Finally, DECODE considers the full technology stack within which all of the above founda-

tions executes. This includes the underlying hardware platforms Hub and the Operating

System on which the software executes. DECODE terms this the controlled execution

environment and explores ways to provide assurance, transparency and reproducibility of

the execution environment.

Each of these conceptual building blocks are explored within the following sections which

should provide the basics required to understand how the implementation functions. Each

of the topics is a deep area of study in its own right so we provide references to allow

further exploration.

A fundamental concept within DECODE is that all data is represented by

attributes

described below. This allows us to build a conceptual model of how DECODE fulﬁls its

purpose.

To describe how data (hereafter

attributes

) is produced and consumed we ﬁrst specify

the entities and roles within the DECODE ecosystem. That is, the set of systems, people

and organisations that in combination fulﬁl the purpose of DECODE.

Real world entities that play a deﬁned role in the DECODE ecosystem are:

• Individual citizens

• Organisations

– Public authorities

– Businesses

– NGO and civic society organizations

Within DECODE we deﬁne several roles that these individuals or organisations play within

the ecosystem.

• Participant

• Operator

• Attribute Veriﬁer

• Node Host

Participants represent the end consumers of DECODE - in this role an entity is storing

data and interacting with applications. Applications are operated by operators who are

entities that code and maintain applications that run in the DECODE ecosystem. Attribute

veriﬁers are entities which have the ability to verify claims associated with a particular

attribute, and provide cryptographic evidence of the claim. For example a public authority

can verify that a participant is a resident of a particular city or country. Node hosts are

members of the DECODE ecosystem who operate the underlying infrastructure of the

DECODE network. Most commonly they will be hosting and running the nodes within

the network, but may also run specialised services such as meta data services or online

wallet services.

All interactions within DECODE are cryptographically linked back to an Account. In

its most basic form this can be thought of as a public / private key pair. In eﬀect the

controller of an account will own a private key and therefore there is some cryptographic

evidence that this control can be demonstrated. This is common to all distributed ledger

systems. As with these, it makes the security of the private keys a prime concern.

Applications within DECODE are subject themselves to a high degree of veriﬁcation and

transparency. All applications must be transparent about what attributes they wish to

access / manipulate for a Participant. We refer to this set of attributes as a Proﬁle.

A key concept to understand about DECODE is that attributes are strongly linked to

applications. This provides a level of control and traceability over the system. It says

that attributes can only be “created” (or “captured”) by applications and that there is a 1

to 1 relationship between attributes and applications. This means that e.g. even if two

applications both capture a First Name, in DECODE these represent separate instances

of attributes.

Creating a structured model around attributes provides a foundation allows us to build

higher level constructs such as Smart Rules and User Experience which make it straight-

forward for Application Developers to produce high integrity, privacy aware Applications

without needing access to highly specialised experts in the ﬁeld of cryptography. It allows

Participants to have a highly transparent view and control of their data also without the

necessity to become cryptographic and privacy experts themselves. A key principle of

DECODE is “User Friendliness” for both Application developers and participants.

Attributes

Data items alone provide little value, for example the string “Paris” could mean many

things to many people. In order to be able to make a useful system that can process data,

and in particular provide additional value for the purpose of data privacy and integrity,

DECODE implements a conceptual model that attaches meta-data to an attribute. This

model allows us to make

claims

about attributes. We begin with a basic structure of the

form:

ATTRIBUTE = (SUBJECT PREDICATE OBJECT)

Where the SUBJECT is the entity to which the attribute relates (in DECODE terms, the

account), the PREDICATE describes the relationship between the SUBJECT and the

OBJECT and the OBJECT is the value of the attribute.

Thus we might say (e.g. in JSON):

locality : [" decode - account :543232" ,

" schema : addressLo cality ", " Paris "]

^ ^ ^

| | |

ATTRIBUTE SUBJECT PREDICATE

OBJECT

where schema and decode-account are URNs. schema expands to https://schema.org/.

This already provides a lot of value. However DECODE adds two further concepts to the

model, PROVENANCE and SCOPE.

ATTRIBUTE = (SUBJECT PREDICATE OBJECT PROVENANCE SCOPE)

Figure 2: Key conceptual terminology and relationships

PROVENANCE provides traceable evidence to support the claim we are making. This

evidence currently consists of two parts, the source of the attribute, by which we mean

the application which captured it or generated it, and optionally one or more veriﬁcation

elements which are links to a cryptographic demonstration of that attribute. In our

example this would be an Attribute Based Credential issued by the city authority of Paris

associated with the private key of the account.

SCOPE relates to the agreement that is made between the application and the owner of

the attribute (usually the Participant), in terms of entitlement. In DECODE terms, this

is a link to an entitlement policy.

One element of attributes that is still under consideration and review is the lifespan of

an attribute, or the time frame within which it exists. It is possible that attributes have

an expiry and certain that attributes are dynamic with respect to time. For example I

may move house and unavoidably become older with the passing of time. The thinking

so far in these areas tends towards representing data as append only, immutable event

streams. That is to say that you never “overwrite” or “mutate” an attribute, only add a

new instance that represents the new value. The most common reference model to think

about this is your bank account, consisting of a set of debits and credits. You can’t go

back and “undo” a withdrawal, but you can make a compensating transaction and make a

deposit of the same amount which in real terms ends at the same outcome.

Identity

Identity within DECODE inverts the current world position whereby participants know

little about the operators of the services they are registered with but the services know

everything about the identity of the participants. “Vendor relationship management” so

to speak; where the vendors are DECODE-enabled applications. In DECODE, the focus

is on strengthening the position of the participant in terms if understanding exactly what

organisations are operating applications and what those applications are doing with the

participants’ data.

Participants

The identity of the participants is irrelevant to the DECODE system, and

also to the applications that run in the DECODE ecosystem. What is relevant are the

attributes that are related to the participants. We would go as far as to say that identity

is a concept not needed at all. In the real world we live and act in many diﬀerent contexts,

these activities and the relations in those contexts each deﬁne a perspective on who we

“really” are. There is overlap, sure, but there is no context in which

all

aspects of us are

relevant. So, what is our identity?

There are three options:

1. identity is what we think we are (i.e. self)

2. It is how the state deﬁnes us, typically through a number or code assigned at birth

3. It is the combination of all perspectives from all contexts combined

In the DECODE ecosystem we will keep the diverse and subtle ways of addressing aspects

of our lives and selves in diﬀerent (online, digital) contexts, and leverage the capacity

of the medium to improve upon this in a privacy enhancing fashion. When thinking of

identity in this ecosystem, option one, above, is irrelevant, and option three is ﬁne in an

abstract way, but fraught with privacy issues when it would be possible to address and

use practically. That leaves the extremely narrow deﬁnition of the government assigned

civic number. Apart from the issue that people exist without such numbers, this is just a

single attribute of a person, at best a strictly formal (or legal) deﬁnition of identity, but

missing out on just about everything we are.

Better to avoid discussion and confusion and

not

to use the word identity at all, and talk

about diﬀerent collections of attributes, relevant in diﬀerent (online, or even DECODE-

supported oﬄine) contexts (or applications).

Let’s call such a collection a proﬁle for now.

In the end we are talking about physical people (AI’s with civil rights are a ways oﬀ), even

when assigning attributes that are purely abstract, or are transferable, these are about, or

related to a person. This person is represented in the DECODE ecosystem as a proﬁle,

but

not uniquely

. One physical person will have control of the data related to multiple

proﬁle. These may overlap (in the values of certain attributes), or may not.

These proﬁles aren’t entities in the DECODE system, they are a way of talking about

application-deﬁned collections of attributes. Proﬁles are the subject of

entitlements

even when, for instance, the only attribute needed for the online alcohol-buying app is the

age, that app would, in its use,

deﬁne

a proﬁle with an age, and nothing else at all. For

the sake of argument we leave out practicalities as payment, and the address to send the

purchase to.

The connection to the real person in the real world is through a DECODE account that

the person will authenticate against in order to interact with DECODE applications. This

account is not part of the DECODE data that these applications have anything to do

with, although the authentication app or apps (multiple means of authentication) could

be seen as a special kind of DECODE enabled applications.

Authentication usually involves a participant providing various personally identifying facts

to a system such as date of birth, passport id / driving licence number, potentially with

additional oﬄine checks and questions of the participant. For example in signing up to the

UK’s Gov.uk Verify you register with a federated identity provider (e.g. The Post Oﬃce).

The post oﬃce has a mobile app that can capture images of your passport, OCR the details

and conﬁrm them against the HMPO (Her Majesty’s Passport oﬃce) and then takes a

photo using the phone camera in order to compare against the photo on the passport.

A participant demonstrates control of these

attributes

through some cryptographic means

(essentially by holding a private key). This private key may be embedded on a physical

device that the participant owns, such as a Ubikey or Smart Card issued by a civic

authority. In the case of a device issued by an authority it may also contain attributes of

interest to other DECODE applications, such as the fact that one lives in a particular city.

These attributes, when stored, record the provenance and the semantic meaning of the

relation in their URN, and can so be “oﬃcially veriﬁed” attributes that certain applications

may require (such as voting in participatory budgeting applications, see below).

Taking this approach to “identity”, also has the beneﬁt of following a privacy by design

principle of only providing the minimum set of information that is absolutely required for

a particular interaction.

Attribute provenance

Accountability of systems

Of course digital systems cannot be held accountable in any legal sense (yet), but we’ll

need to address the fact that consequences of using digital and ‘autonomous’ systems are

no longer as pre-cooked as they once were.

No longer is it guaranteed that the mechanisms and processes though which technology

interacts with the world are clear and understandable, even to the engineers who build the

systems; the bias in the training data is invisibly and irretrievably encoded in the trained

models. This means that technology needs to be able to be held accountable in itself, not

only through the people running it or the engineers building it. In order to enable this,

accountability needs to be designed into the systems, needs to be part of the systems, and

thus, in a certain sense, systems need to be able to reﬂect on their actions; at least in

response to queries.

Data transparency

Taking stock of this accountability design challenge leads us to a couple of preconditions

to a possible solution or implementation. One of the most important of these, especially

in a DECODE context, is

data transparency

. What type of data was used, where,

when and for what purpose was this data collected? In a system for data management

(such as DECODE) the relevant metadata needs to be recorded and made available when

needed, either directly to the user in response to queries, or to aggregation algorithms

that produce data that itself needs to be able to provide an account of its provenance.

The accountability mechanisms may not be part of DECODE, the data formats needed to

make them possible are.

In DECODE the provenance metadata is provided through the application. When a

participant stores some data in a DECODE-enabled system, the participant

always

does

this through an application. Similarly, the application may generate data on behalf of the

participant and store it (or a link to it) through DECODE. The data recorded or stored

always has the relationship recorded that it comes from this particular application (The

source).

Attribute veriﬁcation with ABC

In order to provide a stronger assertion about the

provenance

of attributes in DECODE,

we incorporate the cryptographic mechanism of Attribute Based Credentials (ABC)

An attribute in this case is any indivisible piece of personal information that can

be described by a bit-string, such as an identiﬁer, a qualiﬁcation or a property

of an entity. (Alpar, 2015)

Informally, an Attribute-Based Credential (ABC) is a cryptographic container of

attributes that can provide security assurances for all participants in the system.

(Alpar, 2015)

For example, when selling a bottle of wine, a vendor has to verify that their customer is

over the age of 18. The customer shows their credential; an identity card issued by the

government, to convey the information ‘date of birth’ to the shop owner, in order to prove

that they have the attribute ‘being over the age of 18’. ABCs provide a cryptographic way

to authenticate using selectively disclosed personal attributes. This means that in the

above example, we can use an ABC credential to convey just the property of ‘being over

the age of 18’, without revealing any of the other attributes in our credential, and even

without linking this event to previous interactions.

A diﬀerent example, proves the usefulness when attempting to digitise a membership

system.

Classically, a library card allows a member to borrow a book. This credential reveals

no more information about the borrower than their membership of the library. When

building a digital library card system, it is diﬃcult to verify active membership without

cross-referencing the card with a list of authorised members. ABCs allow the showing of a

membership credential, without having to check the list of authorised members. In addition

it can provide multi-show un-linkability of the credential showings, which prevents them

from leaking information about the speciﬁc member through logging of the interactions.

There are three parties involved in the use of ABCs: the Issuer of the credential, the user

or Owner of the credential (in DECODE terms, the Participant, and the party that wishes

to verify a credential (Relying Party).

The proposed model for ABCs in DECODE is based on Idemix (Jan Camenisch, 2001)

(IBM Research, n.d.), since the DECODE implementation requires multiple veriﬁcations

of non-identifying credentials to be unlinkable. A tested implementation of ABCs is IRMA

by the Privacy by Design Foundation. Credentials can be part of a claim.

So how are claims actually veriﬁed in the ﬁrst place? In the example, the entity responsible

for veriﬁcation would be the city of Barcelona. This could be a physical process, or could

be done online (as in the Dutch DigiD mechanism), and involves some exchange between

Figure 3: User requests a credential

Figure 4: User presents credential

the city and the individual. The result of this exchange would be a cryptographic token,

signed by the city, which, invoked with a speciﬁc smart rule would result in an attribute

with veriﬁed provenance and value being set in the DECODE platform. This whole process

could take place through a website which is run by the city of Barcelona (and thus is a

DECODE enabled application). Required will be a mechanism by which the DECODE

network can

trust

the public key of the city of Barcelona, i.e. there will need to be a

registration protocol to establish this trust.

ABCs could provide both the trust mechanism for externally veriﬁed attributes, and the

initial cryptographic tokens can be produced through a process of proving (possibly in

zero-knowledge) the control of a credential.

The User Journey for this interaction would involve the person authenticating this website

and then creating a “city_of_residence: Barcelona” credential signed with the city’s

private key. In this example there would be a validity time limit on the attribute, a month,

perhaps, within the credential. People move. Because the choice of using applications that

accepts this credential is in the hands of the participant they have strong control of how

this link is used. In a P2P sharing application a diﬀerent proof-of-residency attribute may

be good enough, for instance.

In order to make it straightforward for developers to build DECODE applications, the

mechanisms for interacting with and validating external or “oﬃcial” claims will be a core

part of the language that is used to express Smart Rules.

Entitlements

We deﬁne two parties in any given data exchange, the

data owner

and the

data con-

sumer

. An

entitlement

is an agreement of disclosure controlled by the

data owner

. A

data entitlement

concerns the sharing of data. In DECODE an

entitlement

is deﬁned

in a policy and implemented with the application of cryptography.

Entitlement policies

The DECODE architecture is inherently distributed and as such the management of

entitlement policies will need to respond to some well understood challenges :

Challenge of embedded decisions

The entitlement policy for a piece of data would

need to be consistent wherever that data is stored - the data may be sharded or replicated

or both.

Challenge of lack of overview

Distributed entitlement policies make it diﬃcult to

gather and understand policies governing the data.

Challenge of identity integration

A data entitlement system within the context of a

distributed system may need to interface with one of many identity systems.

Challenge of expression

A formal expression of an entitlement policy should have a

rich model of expression.

There are 4 key elements to an entitlement policy :

• What attributes are being shared

• With whom is the data owner sharing data

• For what purpose

•

Under what

conditions

will the data consumer use the data (e.g. https:

//opendatacommons.org/licenses/pddl/)

• What is the timeframe within which this entitlement is valid (Expiry date)

• How does the entitlement respond to changes to the value of the attribute

This last point is a subject of further research and exploration - how should an entitlement

be considered when the underlying attribute is superseded. For example, if a participant

provides a new address to the application, does the entitlement automatically apply to the

new address? It may be possible to express such “rules” using the Smart Rules language.

Rather than attempting to build a hierarchical entitlements system by classifying certain

attributes into privacy groups, such as “sensitive, personal, public” DECODE speciﬁes all

entitlements at the granularity of individual attributes.

DECODE deﬁnes three possible access levels:

Access level Description

owner-only Subject can see

neither the existence

of this attribute, or its

value

can-discover Subject can see that

the data item has a

value for this

attribute, but not

what it is

can-access Subject can both see

that the data item has

a value and read that

value

In most cases, the participants in the system will not be creating the entitlements directly,

they will be interacting with DECODE applications. These applications will have the

ability to declare what entitlements they require and the participants can agree to them,

in much the same way that users can accept authorisation grants using OAuth.

Implementation (access control)

Deﬁning and declaring entitlements is a matter of describing access rules. In order for

these to be useful we require a mechanism to enforce them. In a traditional system we

would simply “trust” that the system has been coded to take account of the entitlement

declaration - for example we might install an authorisation server product to deﬁne and

store entitlements and rely on the developers of the system to code appropriate controls

into the system that communicate with the authorisation server.

DECODE moves towards a more decentralised model and ultimately will explore ways in

which both the data and the mechanisms of access control can be decentralised, including

the issuing and veriﬁcation of credentials.

An intermediate position which provides for low investment integration to existing systems

is to leverage the core foundations of a distributed ledger and attribute credentials to

improve on the more “traditional” access control methods.

The following sections describe both of these scenarios, starting with leveraging crypto-

graphic credentials in a “standard” data access scenario and then expanding on this to

move towards a more decentralised data storage and optimisation of encryption through

Attribute Based Encryption.

The possibility of having completely decentralised credential issuers is currently a research

topic and will be explored as the project progresses. It is imagined that the ﬁrst scenario

will integrate with the existing applications sooner.

Using ABC as an authorization mechanism

In this scenario, we leverage a “traditional” architecture whereby a central entity stores

data of many people and protects it by means of access control implementations. DECODE

allows for the possibility to be integrated with such systems as the source of authorisation

information. By referring to entitlement policies stored within DECODE, the application

can then accept Attribute Based Credentials presented by users and validate them against

the policy, in order to make an authorisation decision. This model allows for DECODE to

be easily integrated to existing systems whilst still providing state of the art cryptographic

security.

The implementation of this will be based around the Json Web Token (JWT) speciﬁcation.

Using ABE as an access control mechanism

Evolving the model towards a more decentralised approach, DECODE proposes that

data can be encrypted in order that it can be stored in the open (for example on a

massively distributed ﬁle sharing system such as IPFS. A baseline implementation of

this would be simply to encrypt the data with the public key of every user who has the

entitlement. DECODE will explore the use of Attribute Based Encryption (ABE) a state

of the art cryptographic mechanism which is an evolving topic but that has the potential

to signiﬁcantly reduce the overhead of allowing groups of people cryptographic access to

an encrypted data source.

At a high level, it relates cryptographically an attribute that the participants possess to

the encryption of the data. In one way this can be seen as each participant owning a key

which is unique to them, where the encrypted data can be decrypted by any of the keys.

For example a participant “Charlie” may want to share their monthly energy usage with

other members of their block of ﬂats. Charlie can use ABE to encrypt using the public

key of the attribute “member of block of ﬂats” such that anyone else in the block can

decrypt it. In this model, DECODE enables the owner of the data to enforce the access

control as opposed to relying on a third party as in the previous scenario.

ABE allows users to encode more complex access conditions. For example you can encrypt

a party invite only for your neighbours:

( NOT ('being under the age of 18')AND

'being a resident of my block')

The data can be encrypted in such a way that only

individual agents with those particular set of attributes in their wallet can decrypt the

message.

The main models for ABE come from previous work on ‘Attribute-based Encryption for

Fine-grained Access Control of Encrypted Data’(Goyal et al., 2006) and ‘Ciphertext-Policy

Attribute-Based Encryption’(Bethencourt et al., 2007). Reference implementations are

Figure 5: ‘Data vault’ access control

Figure 6: Attribute based encryption

available, but at the time of writing none have been selected to be supported by DECODE.

The design of DECODE will try to support this method of user controlled access policies.

One of the complexities with ABE is the scheme by which keys are issued. Many existing

schemes rely on a central party to issue and manage keys. DECODE will explore more

decentralised models in this space.

However, if the participants wished to broadcast their data to a larger, but still restricted,

set of users; this method of access control will turn into a key-distribution problem; which

is outside of the scope of the main functionality of DECODE at this stage.

Controlling access to large datasets or streams of data

We require a mechanism for controlling access to either large datasets or streams of data.

Perhaps a participant wishes to publish a dataset including all their movement data from

their phone for the last two months and yet control access to certain attributes.

This is also an ongoing research topic within DECODE.

Potential options are:

• Encrypt each data item in the list as above

•

Separate the data into “columns” ie. each data attribute is becomes an array of

values and these are then encrypted using ABE

•

Investigate DRM tech for encrypting large streams (e.g. video). Can similar approaches

be applied to user data?

Distributed ledger

Within DECODE, the ledger provides for two characteristics, Integrity and Availability.

This is an important distinction within DECODE. Privacy (or Conﬁdentiality) is not a

core function of the ledger but is rather enabled by its features and design.

In combination with ABC and ABE, DECODE achieves privacy through the core principle

that no private data must be stored on the ledger. Privacy is one of the classic issues

faced by decentralised systems (the other being scalability). For example while Bitcoin

provides some level of anonymity, all nodes have access to all transactions and all the data

within them. The same is true for Ethereum, although it is moving in this direction by

integrating features from ZCash to allow zk-SNARK computations from solidity, in the

upcoming metropolis release. Other ledger implementations are exploring diﬀerent designs

by which privacy can be obtained, for example R3 Corda.

DECODE puts this principal at the centre of its Privacy by Design strategy. The

cryptographic mechanism by which this is achieved is through Zero Knowledge proofs.

In short these allow a participant to perform an action (transaction) and record a veriﬁable

proof of that transaction which has no relation to the data used within the transaction.

The proof can be stored quite safely on any number of nodes since it contains no private

data. It is also possible for multiple nodes to validate the transaction and build up a level

of conﬁdence in it (Integrity) and enable redundancy of the proof (Availability).

In practical terms for example, in combination with attribute based cryptography, this

allows for anonymous yet veriﬁable petitions (see examples section). The resulting petition

has a high degree of integrity because the ledger provides a Byzantine Fault tolerant

replication mechanism and a high degree of Availability because it is decentralised and

Figure 7: Attribute based encryption access control

therefore not under the control of a single party or system. This makes it extremely

resistant to many forms of failure or attack.

In summary the key requirements of a distributed ledger for the purposed of DECODE

are:

• Byzantine Fault Tolerance

• Decentralised network

•

Ability to implement contracts that transaction execution from veriﬁcation via ZK

Proofs

•

An environment that allows a higher order language to be created (See Smart Rules)

• Ability to scale horizontally

• Open source

Querying the ledger

Having a robust and veriﬁable source of truth for transactions is of little value if applications

cannot make use of the record. To this end, DECODE will provide a query interface over

the ledger which will be a separate capability. This area is still under development and

updates will be provided via. the whitepaper as it evolves.

Authentication

DECODE recognises two scenarios involving Authentication.

a) Authentication to DECODE wallets and nodes

This is the means by which the participant protects access to their wallet. In its most

basic form this will be the standard option of a password credential.

DECODE also supports and will explore the concepts of more sophisticated authentication,

for example external hardware security devices and leveraging biometric capabilities of

devices.

b) The use of decode as a federated authentication provider

It is possible for

operators

to provide a “Login with DECODE” option. In this scenario

the operator would enable an integration whereby the participant would be redirected to

their DECODE wallet, authenticate there as above and then an exchange of application

speciﬁc cryptographic credentials would be passed back to the website, allowing them to

be authenticated.

A key principle at work with this scenario is that the operators must themselves be

transparent to the participants. This means in practice that in order to allow login with

DECODE the operator must ﬁrst register with DECODE and itself be cryptographically

auditable in any actions it takes in the DECODE system.

This raises questions around the governance of the DECODE ecosystem which will be

explored as it is ﬁeld tested and evolved.

Operating system architecture

The DECODE OS is the base operating system running all software designed, developed

and deployed for the DECODE project. This operating system is based on the renown

Devuan GNU+Linux distribution, a fork of the now 20 years old Debian distribution,

maintained by the Dyne.org foundation and an open community of volunteers. Devuan

forked Debian to preserve the simplicity and minimalism of the SystemV tradition in UNIX

systems, still running modern software applications and inheriting the security patches

from Debian.

The ﬁrst release of the DECODE OS is made available at the Internet address https://ﬁles.

dyne.org/decode/OS and it incudes fully functioning virtual machine images (Vagrant/vbox

and Qcow2/Qemu formats) implementing a base architecture (kernel and base system

tools) to build, run and connect a diverse range of future applications. The DECODE OS is

provided to developers of the DECODE project along with comprehensive documentation

and tools to reproduce its build, benchmark and audit its functioning, as well with a

dashboard for live monitoring.

The primary goal of the DECODE OS can be explained in brief by deﬁning it as a

“controlled execution environment” where, from the making of its base to the execution of

every single application, all steps are recorded on a ledger of events that can be saved,

analysed and shipped along with every instance of the operating system. A secondary goal

of this development is that of making the results of such a recorded sequence of operations

reproducible.

The DECODE OS both as a product but also as a well deﬁned process leading to its

release aims primarily at satisfying the following main objectives:

•

Adopt free and open source software compliant with any of DECODE’s approved

licenses. Make the source-code of any running software immediately available for

audit. Avoid any dependency from proprietary software.

•

Rely on widely used, peer-reviewed and stable applications and standards from

GNU/Linux/BSD software traditions for its base functions.

•

Make the whole building process transparent and auditable, providing schematic

information about all adopted components that can be short and to the point, as well

machine parsable.

•

Realise a minimal, lean and resource aware operating system running as less processes

as possible, to avoid complexity and to facilitate the controlled execution of micro-

services.

•

Rely on a continuous-integration infrastructure (see D4.2) able to integrate the

dependencies and applications of DECODE developers with as less friction as possible.

•

Provide an optimal developer experience by providing two distinct proﬁles: “-dev” for

development and “-prod” for production use and a way to switch between development

and production that is seamless.

•

Maintain an exact history of changes made to the OS as well builds triggered, reﬂected

in the ﬁnal product and auditable according to a map of liabilities drawn during the

build process.

•

Integrate benchmarking tools and a live monitoring dashboard to facilitate quality

assurance assessments and the review of resource management under diﬀerent condi-

tions. Also allow the customisation of the dashboard to include future application

speciﬁc indicators.

•

Target a wide range of hardware architectures and well-established chipset standards,

virtual machines and cloud providers, without requiring any signiﬁcant change in the

base system, just a diﬀerent setup of the continuous-integration pipeline.

•

Refer to well established UNIX standards for the conﬁguration of the system and

process control. Avoid any binary conﬁguration format and adopt as much as possible

input and output formats that can be both read by humans and easily parsed by

machines.

•

Enforce full-spectrum process separation between all diﬀerent applications running

on the DECODE OS, making it possible to isolate problems and eventually recover

functionality.

Process separation

DECODE’s implementation of a distributed computational system aims to be solid and ﬁt

for mission critical purposes by leveraging well established standard practices in the UNIX

world. Contrary to the monolithic applications implementing blockchain functionalities

in a single runtime environment running in application space, our implementation of a

“DECODE NODE” (see D1.1) is a controlled execution environment unit for Smart Rules

grafted on the classic concept of a UNIX-like operating system, keeping POSIX.1b and

SystemV compatibilty. This approach brings several advantages:

•

The system is familiar to system administrators and can be monitored and managed

using existing well known tools. A DECODE NODE is backward compatible with

the vast majority of existing entreprise infrastructure.

•

Planned and documented integration between application speciﬁc functions and the

underlying OS, verticalising the full stack and providing a fully certiﬁed environment

for smart rule execution.

•

The security of the DECODE NODE is granted by means of stable Linux based

access control lists (ACL) and ﬁrewalling.

•

The diagnosis of problems occurring on running nodes is fully compatible with already

established practices of logging, tracing, proﬁling and debugging processes.

•

Components can be mixed in a modular fashion, allowing reusal of existing im-

plementations in diﬀerent roles, including production ready software for network

orchestration, p2p networking, data storage presentation, cryptographic operations

and immutable ledger functions.

Privilege escalation

Intelligence communities use the concept of “need to know” as a way to minimize in-

formation leaks and only grant access to secrets when it is absolutely necessary for the

performance of an agent’s action. In computer security, the same concept can be translated

for privilege escalation: the need for a program to execute actions not normally available

to its calling user. Often used oﬀensively to gain control of a target machine or extract

information, privilege escalation has also legitimate use, for example to enable a desktop

user to perform administrative actions such as rebooting a running system or upgrading

its software packages.

In case of the DECODE privilege model for data access the intention is to maintain defense

in depth by granting the integrity to the underlying operating system in addition to the

cryptographic security model implemented by the application layer, because a node that

is compromised by a rogue process escalating its privileges could anyway jeopardise the

validity of results provided by the smart rules computations happening on it.

In order to avoid such a situation, DECODE adopts a privilege escalation model based

on a hard-coded hash-table that is inscribed into its operating system. The standard

C (POSIX.1b) implementation for this model is called sup, currently maintened by

Dyne.org and well known to the security community especially in the context of embedded

development. Its website is visible at https://sup.dyne.org

The sup binary runs as root (with suid bit on) to facilitate the privilege escalation needed

to execute certain programs as superuser, for instance to open a listening port below 100,

for a web or an SMTP server. In order to regulate the privilege escalation sup handles a

few conditions to authorize execution, all hard-coded in a static ELF binary.

For the DECODE OS an “allow list” is provided to sup at the time of building the ISO

installers and SD card images, so that running “sup application” will escalate the privileges

of application without the need of any password, in case the application is included in

the “allow list”. In order to extend the list of applications allowed to escalate privileges

within the execution environment of the DECODE OS, a new build of it must be provided.

Binaries change their contents across builds that are targeted to diﬀerent architectures

(i386, amd64, armhf, arm64, etc.) therefore the hashes in the allow list will change for

each targeted build.

The sup binary itself is authenticated by the “root” signature of each DECODE OS which

is shipped along with the ISO or installer or SD card or virtual machine image formats.

The cryptographic signature of DECODE OS veriﬁes all the binaries of the system in their

current state as released, including sup whose unique binary footprint changes at every

change of its privilege escalation hash table. Therefore any change in any binary that can

escalate its privilege via sup will lead to a change in the sup binary itself, which will lead

in a change in the signature of the whole DECODE OS.

This way of authorising the execution of software applications is not only implying that a

particular binary can escalate privileges, but also that a particular build of that program

can. It means that even if the binary is substituted with another one by modifying the

installer image of the DECODE OS, it will not be able to be executed with privileges,

denying the possibility to run eﬀectively counterfeited DECODE OS images, as this check

is combined with the check of a cryptographic signature for the whole OS image.

Security implications

This privilege escalation model improves the overall security of the DECODE OS as a

system where it can be pre-determined what needs to run with privileges, harnessing the

main diﬀerence with desktop systems that are interactively conﬁgured and whose privilege

model can be changed by users. When this model is used in combination with a security

enhanced Linux kernel, it constitutes a very robust foundation for the realisation of a

secure operating system that executes a predetermined set of computing processes.

DECODE’s privilege escalation model provides overall better security against the breach

of the system integrity, but it cannot be considered a blanket solution for the security

and integrity of the whole DECODE architecture. It is a reasonably strong measure to

insure the integrity of operations at the core of the DECODE OS, granting integrity for

the execution machine.

Technical implications

For the developers involved, DECODE’s privilege escalation model means that every

software application, be it binary compiled or scripted executable, needs to be registered

with its hash inside the OS at build time. To change such an application a whole new

build of the DECODE OS needs to be triggered. This is of course a setting necessary to

produce production ready installers, but it can be de-activated for testing environments.

The other main implication is that each and every program executed with privileges cannot

arbitrarily execute other programs that are conﬁgured at runtime. For instance a privileged

process cannot have a variable that can be conﬁgured at runtime to call another program.

An exception to this rule can be the implementation of a mechanism to drop privileges

inside the program, which should be throughly reviewed: such implementations exist in C,

however the need for such an exception should be avoided.

Regarding updates, patching a running system would entail a reboot after downloading

a new OS version, which will be distributed in a “squashed” bundle (squashFS). This

wouldn’t mean to reinstall the entire OS, but to download and reboot into a new signed

binary system.

Political implications

The model by which privilege escalation is granted to processes running in the DECODE

OS is intentionally resistant to changes, which need to be implemented and recorded in

the history of revisions before the build process. This model forces a clear negotiation

of privileged process, allowing a debate on such choices that is extended to all technical

stakeholders. The process of privilege escalation should be in fact seen as a political

negotiation about which algorithms are allowed to deal with more delicate parts of the

operating system.

Application modules

Considering a ﬁrst abstraction of functionalities, mostly resulting from the study of user-

cases and currently adopted pilots in DECODE, it is already possible to envision a set of

modules whose functionalities can be satisﬁed by a considerable number of stable software

implementations. The following ﬁgure shows the functionalities that can be contained

in a DECODE node, each of them can be a diﬀerent software application running as an

isolated process, whose communication channels can be speciﬁed at the time of building the

DECODE OS and cannot modiﬁed unless the design of the OS is re-negotiated according

to clear needs and speciﬁed patterns.

The modules listed in the ﬁgure above are: - Smart Rules language interpreter and

controlled execution environment - Entitlements ACL layer based on attribute based

cryptography - Distributed Blockchain providing an immutable ledger - Data storage

Figure 8: DECODE application modules diagram

(Vault) in diﬀerent possible formats (Document or Graph) - Peer to Peer Networking

Orchestration System and VPN

The modules listed can be implemented by new software developed by the DECODE

consortium as well as by existing and well established open source standard implementations.

Being this the ﬁrst release of the DECODE OS it is well out of the scope of this document

to envision which software will satisfy these roles, as well the listed modules may be subject

to further adjustments as new needs and reﬁnements become manifest in the coming

research iterations.

What matters to us now is the fact that there is a clear way to include such SOFTWARE

modules inside a coherent and well documented system built from source and that the

overhead to substitute a module with another implementation is minimum. Each applica-

tion is an installed software package that is ran at startup, whose health is monitored by

the system and whose failure does not propagates to other system components.

This architecture also allows to map the inner architecture of a NODE as well to envision

the possibility to produce diﬀerent NODES that are tailored ad-hoc to diﬀerent use-cases.

As a last note, the architecture also includes the possibility to have an optional application

to be ran inside the NODE and interact with some of the components inside it: this is

an opportunity DECODE OS can leverage for special applications requiring intensive

communication with inner components of the DECODE NODE.

Smart-rules engine

The main way to communicate with a DECODE node and operate its functions is via a

language, rather than an API. All read and write operations aﬀecting entitlements and

accessing attributes can be expressed in a smart-rule language, which we intend to design

and develop to become a robust open standard for authorisation around personal data.

The DECODE smart-rule language will aim to naturally avoid complex constructions and

deﬁne sets of transformations that can be then easily represented with visual metaphors.

What we call smart-rule language in DECODE is a computable (Sober, 1978) sociolect

(Louwerse, 2004) that can be parsed into a semantic model referred to a ﬁnite ontology

and executed by a distributed computing cluster. It is of central importance to grant

participants the access to such a language and clear understanding of what it expresses

and of the consequences of its execution.

The open nature of the smart-rules is extremely important when compared to the popular-

ization of “sharing economies” that apply mostly unknown rules that are opaque to the

participants and undemocratically adjusted by third parties who are not participating in

the economy, but in most cases just proﬁting from it.

The DECODE project plans the development of a language for “smart-rules” that is not

conceived to stay behind the scenes, but to be understood and modiﬁed: this a diﬀerent

approach to data management rather than CRUD-type interaction, an approach that

is also necessitated by the distributed and write once immutable nature of blockchain

technologies.

DECODE’s smart-rule language is conceived as a trust framework which is both usable

(can be executed) and expressive (can be understood) to encode smart-rules and contracts

relating to the governance of personal and other data in the DECODE architecture. The

possibility to understand and not only to execute a language is of paramount importance

to allow algorithmic sovereignty (Roio, 2017). Algorithms are law (Lessig, 1999) in their

own speciﬁc domain and just as law they must be subject to reviews, critiques and

transformations according to societal needs and techno-political negotiations.

The objective is to achieve compliance with privacy regulations and digital right by

converging them in a usable and expressive integrated approach (crossing the domains of

social, legal, economic and technical modeling) formalised by smart-rules that represent

social contracts and entitlements. The design of the smart-rule language should promote

clarity and avoid ambiguities. The rules should ensure the respect of the decisions of the

data owner (for example, citizens, or the city administration or an organisation processing

data) as well regulations and legal obligations on application providers.

The data management and policy enforcement according to rules is deﬁned by the user inter-

acting directly with rules or with a facilitate abstraction of them, graphically representing

their ﬂow, facilitating progressive level of understanding by all participants.

Arguably, a task-oriented mindset should be assumed when re-designing a new blockchain

language for DECODE. The opportunity for innovating the ﬁeld lies in abandoning this

approach and instead build an External Domain Speciﬁc Language (Fowler, 2010) using

an existing grammar to do the Syntax-Directed Translation. The Semantic Model can be

then a coarse-grained implementation that can sync computations with blockchain based

deterministic conditionals.

Language Security

The research made on “Language-theretical security” should be the underpinning of

DECODE’s smart-rule language. Here below we include a brief explanation condensed

from the information material of the LangSec.org project hosted at IEEE, which is informed

by the collective experience of the exploit development community, since exploitation is

practical exploration of the space of unanticipated state, its prevention or containment.

In a nutshell [. . . ] LangSec is the idea that many security issues can be avoided

by applying a standard process to input processing and protocol design: the

acceptable input to a program should be well-deﬁned (i.e., via a grammar), as

simple as possible (on the Chomsky scale of syntactic complexity), and fully

validated before use (by a dedicated parser of appropriate but not excessive

power in the Chomsky hierarchy of automata). (Momot et al., 2016)

LangSec is a design and programming philosophy that focuses on formally correct and

veriﬁable input handling throughout all phases of the software development lifecycle.

In doing so, it oﬀers a practical method of assurance of software free from broad and

currently dominant classes of bugs and vulnerabilities related to incorrect parsing and

interpretation of messages between software components (packets, protocol messages, ﬁle

formats, function parameters, etc.).

This design and programming paradigm begins with a description of valid inputs to a

program as a formal language (such as a grammar). The purpose of such a disciplined

speciﬁcation is to cleanly separate the input-handling code and processing code. A LangSec-

compliant design properly transforms input-handling code into a recognizer for the input

language; this recognizer rejects non-conforming inputs and transforms conforming inputs

to structured data (such as an object or a tree structure, ready for type- or value-based

pattern matching). The processing code can then access the structured data (but not the

raw inputs or parsers temporary data artifacts) under a set of assumptions regarding the

accepted inputs that are enforced by the recognizer.

This approach leads to several advantages:

1. produce veriﬁable recognizers, free of typical classes of ad-hoc parsing bugs

produce veriﬁable, composable implementations of distributed systems that ensure

equivalent parsing of messages by all components and eliminate exploitable diﬀerences

in message interpretation by the elements of a distributed system

mitigate the common risks of ungoverned development by explicitly exposing the

processing dependencies on the parsed input.

As a design philosophy, LangSec focuses on a particular choice of veriﬁcation trade-oﬀs:

namely, correctness and computational equivalence of input processors.

Syntax-Directed Translation

For the initial design phase the LUA language interpreter is adopted for the syntax-

directed translation of smart-rule language semantics. Lua is an interpreted, cross-platform,

embeddable, performant and low-footprint language whose popularity is on the rise in

the last couple of years. Simple design and eﬃcient usage of resources combined with its

performance make it attractive for production web applications even to big organizations

such as Wikipedia, CloudFlare and GitHub. In addition to this, Lua is one of the preferred

choices for programming embedded and IoT devices. This context allows to assume a

large and growing Lua codebase yet to be assessed. This growing Lua codebase could

be potentially driving production servers and extremely large number of devices, some

perhaps with mission-critical function for example in automotive or home-automation

domains. (Costin, 2017)

Lua solidity has been well tested through a number of public applications including the

adoption by the gaming industry for untrusted language processing in “World of Warcraft”

scripting. It is ideal for implementing an external DSL using C or Python as a host

language.

Lua is also tooled with a working VPL implementation for code visualisation in BLOCKS,

allowing the project to jump-start into an early phase of prototyping DECODE smart-rules

in a visual way and involving directly pilot participants.

Satisﬁability Modulo theories

Satisﬁability Modulo theories (SMT) is an area of automated deduction that studies

methods for checking the satisﬁability of ﬁrst-order formulas with respect to some logical

theory of interest (Barrett et al., 2009). It diﬀers from general automated deduction

in that the background theory need not be ﬁnitely or even ﬁrst-order axiomatizable,

and specialized inference methods are used for each theory. By being theory-speciﬁc

and restricting their language to certain classes of formulas (such as, typically but not

exclusively, quantiﬁer-free formulas), these specialized methods can be implemented in

solvers that are more eﬃcient in practice than general-purpose theorem provers.

While SMT techniques have been traditionally used to support deductive software ver-

iﬁcation, they are now ﬁnding applications in other areas of computer science such as,

for instance, planning, model checking and automated test generation. Typical theories

of interest in these applications include formalizations of arithmetic, arrays, bit vectors,

algebraic datatypes, equality with uninterpreted functions, and various combinations of

these.

Constraint-satisfaction is crucial to software and hardware veriﬁcation and static program

analsysis (De Moura and Bjørner, 2011) among the other possible applications.

DECODE will beneﬁt from including SMT capabilities into the design at an early stage:

even if not immediately exploited, their inclusion will keep the horizons for language

development open while permitting its application in mission critical roles.

DECODE architecture

DECODE is at the core a distributed P2P network of “nodes” that together provide data

privacy and integrity services to application developers.

The overall architecture is similar to other distributed ledgers and we have followed familiar

terminology, such as “Wallet”. We describe here the roles and responsibilities of each of

the components and how they work together to achieve our goals.

Data storage

There are three signiﬁcant types of data which are stored within the DECODE system:

1. Attributes

2. Ledger Transactions

3. IoT Data streams

Attributes

are stored in the

Attribute Store

. In the simplest case the implementation

is to store in encrypted form locally to the wallet. This will be the starting point for

the implementation of DECODE. It is however possible that a

distributed storage

mechanism could be provided using a P2P protocol such as IPFS. This capability would

be exposed via the attribute store interface. The advantage of a distributed store are:

• Resilience / backup

• Access same data on multiple devices

•

Wallet itself need not have storage capabilities (can act purely as a crypto engine /

key manager)

A distributed store could take advantage of the existing P2P network of DECODE

validating nodes or be formed of a separate network, either an existing network or one

that is formed by DECODE participants.

Ledger Transactions

will be stored in the ledger node system, dependant on the

implementation of the ledger. Our privacy by design principles ensure that no private

data will be stored on the ledger. It is possible that encrypted data could be stored on the

ledger.

IOT Data streams

IOT data represents a special case of data in that it is likely to involve

larger volumes of time series data. DECODE will continue to explore this space as it moves

into implementation. A key question will be how to leverage existing IOT data stores /

aggregators such as the AWS IOT. Following our principle of “Reuse don’t Re-Invent”,

one option is to provide tools that allow decode to be integrated as an entitlements and

access control mechanism over such existing aggregators and data stores. A more involved

option is for DECODE to provide a custom store (based on open source stack such as

Cassandra or Elastic Search). Elastic search for example already provides a mechanism

for Role Based Access Control (RBAC) which may provide a starting point.

The theme of data storage will continue to evolve and will be published via the whitepaper.

Validating Nodes

The integrity and resilience of the network is provided through a distributed network of

Validating nodes. One of the key architectural features of DECODE is that it separates

Figure 9: Decode Network Architecture

execution of logic (contracts) from the veriﬁcation of that logic, which allows for privacy

aware execution.

The validating nodes are key to providing the integrity and availability of the DECODE

network. Therefore we build them from the ground up with a strong emphasis on veriﬁa-

bility by basing them on the DECODE OS. Each node will also contain the distributed

ledger node and any other libraries and software that is required to participate in the DE-

CODE network. This is likely to include cryptographic functionality and P2P networking

capabilities to allow dynamic and evolving P2P networks to be formed. It is possible that

the P2P networking capabilities can come from the underlying ledger implementation, or

be augmented with custom protocols.

It is important to note that DECODE does not mandate that every participant host a

validating node. The minimum software you need access to in order to participate is a

DECODE Wallet.

A key research question for DECODE is how to cover the cost of computation for these

validating nodes? Who operates them? What are their motivations? The bottom line is

that it incurs a cost to purchase hardware and consume electricity. For example, Ethereum

has created a self sustaining network by oﬀering a ﬁnancial incentive to those nodes who

execute the transactions, which is a straightforward economic model.

DECODE seeks to explore alternative incentive models that do not involve direct ﬁnancial

reward and this will be an ongoing initiative for the project. It looks to models that work

for the common good of citizens and will be exploring scenarios that move towards an

“economy of the commons” as opposed to the centralised concentration of wealth within a

few large organisations, which is the current dominant force in the data economy.

Wallets

The wallet is the minimum component a person requires to interact with DECODE. Every

participant will have their own wallet. The wallet has several core functions:

• Store securely cryptographic material (e.g. private keys)

• Securely store Attribute based credentials, linked to private keys

•

Execute DECODE transactions (via Smart Rules) and submit them to the Ledger

for veriﬁcation

• Store, encrypted the participant’s attributes

• Deﬁne and publish entitlement policies based on interactions with applications

•

Provide the participant with a graphical user interface that allows them to manage

their attributes, entitlements and applications.

Optionally a participant can push the cryptographic functions of the wallet onto a hardware

device, similar to Trezor, Ledger Nano from the blockchain world. A discussion of these

options is to be found in the hardware section.

We have identiﬁed two options for participants to obtain a wallet and begin interacting

with DECODE. This is a topic of research for the DECODE system and is likely to evolve

as we move into ﬁeld testing with real communities of participants.

User experience

The wallet will be one of the primary interfaces between DECODE and the participant,

the other being the applications themselves. The wallet interface will be explored through

a user centric design process which will aim to provide a state of the art experience for

participants focused on transparency of who they have shared their data with. The Wallet

will also be the point at which a participant interacts with smart rules.

a) Download a Wallet

The wallet will be available as a standalone application that a participant can download

to their device (either laptop or mobile device). In combination with a hardware security

device this will form the maximum level of protection that a participant can achieve.

Whenever the participant must perform a cryptographically sensitive activity such as

signing a transaction, they will be redirected to their wallet to perform this.

a) Wallets Hosted by Operators

We recognise however that requiring participants to download software and engage with a

registration process may be a barrier to adoption. We plan to explore this through user

research and ﬁeld experiments. With this in mind, the architecture of DECODE also

supports the concept of an hosted wal let.

DECODE intends to provide tools and documentation to allow

operators

to host

wallets on behalf of their existing users. This is a low barrier to entry for an operator,

involving minimal integration whereby the operator maintains any existing authentication

mechanisms they have in place and links existing accounts to a DECODE wallet. It

also preserves any existing authentication structures the application may have, allowing

DECODE functionality to be added in a decoupled and safe manner.

It might be possible for 3rd Parties to create an online wallet hosting service, however we have yet to

explore the demand for this scenario.

To maintain the core values of DECODE however, a constraint of this scenario is that the

user must be aware and consciously agree to the connection between their account and

DECODE. Whilst the process itself maybe “1 click” for the user, the user journey must

include a “connect my account to DECODE” phase. The exact design guidelines for how

this is achieved will be developed on an ongoing basis.

There is a tradeoﬀ with this scenario in that while it allows for lower barrier to adoption,

it also diminishes the true value of DECODE as a decentralised system. In this scenario,

the trust relationship has not been decentralised, i.e. the participant is still trusting the

operator as an organisation with all their data.

The ledger implementation

Chainspace

As part of the mission of DECODE, we present a distributed ledger implementation

Chainspace

(http://chainspace.io) which has been designed deliberately with privacy and

scalability in mind and is fully aligned to the goals and principles of DECODE. The full

technical details of this implementation can be found within the Chainspace whitepaper

(George Danezis, 2017).

In summary, Chainspace provides a highly scalable, BFT fault tolerance ledger which

separates transaction execution from veriﬁcation. In implementation it provides for this in

an entirely technology neutral and decoupled manner.

Chainspace contracts

can be written in any language and are composed of two asym-

metric but cryptographically related components. These are the contract and the checker.

The contract is responsible for executing the transaction, deﬁning the constraints that are

required. The result of the execution of a contract is a proof which has no data from the

transaction but which can be cryptographically veriﬁed by the checker. The network of

Chainspace nodes are responsible for verifying transactions and publishing the veriﬁcations

as a blockchain. In implementation, Chainspace creates multiple blockchains, please see

the Chainspace whitepaper (George Danezis, 2017) for more details.

Alternatives

The architecture of DECODE, following the guiding principles of being modular and reusing

code, is not restricted to the implementation of Chainspace to provide the underlying

ledger capability. It is possible for example that with the cryptographic advances in

Solidity already mentioned, that it would be possible to build DECODE using any ledger

system that also incorporated the solidity VM, either Ethereum itself or for example, the

Hyperledger Burrow project from Monax.

As the project evolves alternatives will be explored and tested as they may solve for

diﬀerent tradeoﬀs, these will be documented in the public whitepaper.

Smart rules engine

What we call “Smart Rules” in DECODE are a computable (Sober, 1978) sociolect

(Louwerse, 2004) that can be parsed into a semantic model referred to a ﬁnite ontology

Figure 10: Decode Overview

and executed by a distributed computing cluster. It is of central importance to grant

participants the access to such a language and clear understanding of what it expresses

and of the consequences of its execution.

The open nature of the smart rules is extremely important when compared to the popular-

ization of “sharing economies” that apply mostly unknown rules that are opaque to the

participants and undemocratically adjusted by third parties who are not participating in

the economy, but in most cases just proﬁting from it.

The DECODE project plans the development of a language for “smart rules” that is not

conceived to stay behind the scenes, but to be understood and modiﬁed: this a diﬀerent

approach to data management rather than CRUD-type interaction, an approach that

is also necessitated by the distributed and write once immutable nature of blockchain

technologies.

The underpinnings of the smart rules implementation are explained in-depth in the

forthcoming deliverable D3.3 “Data Privacy and Smart Language requirements, its initial

set of smart rules and related ontology”.

Operating system architecture

The DECODE OS is the base operating system running all software designed, developed

and deployed for the DECODE project. This operating system is based on the Devuan

GNU+Linux distribution, a fork of the now 20 years old Debian distribution, maintained

by the Dyne.org foundation and an open community of volunteers. Devuan forked Debian

to preserve the simplicity and minimalism of the SystemV tradition in UNIX systems, still

running modern software applications and inheriting the security patches from Debian.

The primary goal of the DECODE OS can be explained in brief by deﬁning it as a

“controlled execution environment” where, from the making of its base to the execution of

every single application, all steps are recorded on a ledger of events that can be saved,

analysed and shipped along with every instance of the operating system. A secondary goal

of this development is that of making the results of such a recorded sequence of operations

reproducible.

DECODE’s implementation of a distributed computational system aims to be solid and ﬁt

for mission critical purposes by leveraging well established standard practices in the UNIX

world. Contrary to the monolithic applications implementing blockchain functionalities

in a single runtime environment running in application space, our implementation of a

DECODE Node (Jill Irving, 2017) is a controlled execution environment unit for Smart

Rules grafted on the classic concept of a UNIX-like operating system, keeping POSIX.1b

and SystemV compatibility.

The DECODE OS is explained in depth in the project deliverable “First Release of the

DECODE OS” (I. J. Denis Roio, 2017).

Hardware Hubs

We use the term “Hub” to refer to any underlying compute infrastructure that can execute

either the wallet software or a validating node. In this sense a hub can be any one of the

following:

• Physical server or PC

•

A virtual machine in a public or private cloud infrastructure (e.g. AWS, Google Cloud,

Azure)

• A single board computer for e.g. OLinuxXIno Lime.

• A smart card running limited cryptographic code

• A mobile device such as a phone or tablet

This section provides a high level description of the requirements of the hardware, and a

section speciﬁcally around the use of hardware for improving security.

In general, a participant who has more control over the full stack execution environment

also has more control over the DECODE platform. Ultimately this is down to the hardware

level and DECODE aims to provide details of how a participant or an operator can operate

DECODE nodes that are entirely open source and auditable.

DECODE will support and explore a wide range of hardware software conﬁgurations,

following the principle of being open and modular. This will allow participants to customise

the level of security and control they adopt. There is a tradeoﬀ between investment on

the part of the participant to purchase and conﬁgure hardware devices vs the extra level

of control and reduce need for trust of a third party.

A key principle is that DECODE should not mandate the use of custom hardware by

participants, in order to allow for greater adoption. It remains to be seen if participants

“vote with their feet” and choose hardware devices, once DECODE is operational.

Requirements

We list ﬁve key requirements of the hardware hubs here:

• Ability to run DECODE OS

• Transparency

• Deployability and availability

• Hardware security

• Connectivity

Ability to run DECODE OS

The processor of the Hub must be able to run the DECODE OS. To assure compatibility

of a speciﬁc processor, it must be made a target of the DECODE OS SDK (I. J. Denis

Roio Vincenzo Nicosia, 2017). The DECODE OS SDK is modelled after the Devuan SDK

and supports all its architecture targets.

Additionally the following capabilities are required:

• Network connectivity (either wireless or ethernet)

• Processing power and memory to support:

– cryptographic operations

– embedded web server operations

– execution of smart rules language

• Local storage in the initial phases at least enough to store attributes

The exact requirements of these will be determined as the project moves forward. Diﬀerent

conﬁgurations will have diﬀerent requirements - for example there will be signiﬁcantly

more minimum compute power required for a validating node than just running a single

wallet, which is should be possible to run on a mobile device.

Transparency

One of the goals of the DECODE platform is to create a level playing ﬁeld that enables

developers from all backgrounds to contribute to society by implementing innovative

applications and opening up new economical, technological and social values based on the

new infrastructure that DECODE will provide. To facilitate the participation of these

developers, all the elements of the DECODE architecture should be open source. For that

reason any device speciﬁcally designed to operate as a DECODE Hub should be open

source and compliant with the Open Source Hardware Association (OSHWA). Schematics,

design ﬁles and documentation should be available for designers to build upon. DECODE

will encourage hardware designers to join their eﬀorts in creating a more secure and open

hardware.

Deployability and availability

Deployability is key to ensure the adoption and success of DECODE. Therefore, the Hub

must be easily available. The most available potential Hub is any commercial computer.

According to Barcelona data-sheet 20171 the Household ICT penetration is 88.3 in 2015

(% on population 16 to 74 years with a computer at home). Despite most of commercial

computers not being open source this is a viable alternative for promoting an early adoption.

For scenarios where an embedded device with a small form factor is required, low cost

open source single board computers (SBCs) are a good alternative for the DECODE Hub.

Hardware security

The need for privacy and conﬁdentiality diﬀer according to the use cases of the platform.

For instance, noise quality data requires less security than biometric health-centered data

that’s being sent to a physician. This requires encryption on many diﬀerent levels. To

build trust in the platform, the DECODE hub needs to respond to the level of security

for each separate use case. Software-based security means that access conditions can be

hacked and logs can be tampered with. In addition, the data itself cannot be considered

secure if left unprotected on a regular PC.

For this reason the DECODE oﬀers Participants the option to adopt hardware-based

security when a higher level of conﬁdentiality is required. The interaction with these

security measures should be easy and eﬀortless for the end-user.

Potential hardware security features for the Hub:

• Multiple factor authentication:

The security protection provided by a single

authentication method, e.g. a password, have proved to be weak. To make access

conditions more secure, the system can ask for a multiple factor authentication. This

could be the combination of a password with some token that the user have (like an

RFID or BLE device) or biometric data like ﬁngerprint readers or voice recognition.

• Secure processors:

Secure microcontrollers with built-in cryptographic engines and

secure boot loader can guard against threats such as cryptanalysis intrusions, physical

tampering, and reverse engineering. These secure microcontrollers are equipped with

silicon-level anti-tampering features that allow to make them tamper resistant and to

provide tamper evidence. The security keys, used to run cryptographic algorithms,

need to be stored in a secure memory managed by a secure microcontroller and

should only be accessible by the secure microcontroller and not from the outside of

the memory.

• Tamper avoidance:

Anti-intrusion sensors can be incorporated into the electrical

design to ensure someone tampering physically with the device would not have access

to any sensitive data.

• Side channel attacks protection:

Side channel attacks consist in attacks based

on information gained from the physical implementation of a system, rather than

brute force or weaknesses in the algorithms. For example, timing information, power

consumption, electromagnetic leaks or even sound can provide an extra source of

information, which can be exploited to break the system. The ﬁrst step to protect

against this types of threats is the reduction of the electromagnetic and sound

radiations. Other measures include random calculations and delays introduced

between normal operations and try to balance the power consumption of diﬀerent

data values.

• Access attempt detection:

Any attempt to access the system data remotely is

detected. If the access is illegitimate (unauthenticated, coming from an unknown IP

address, etc.), access is denied and in some cases data can be erased.

Connectivity

Decentralized transactions will be continuously being carried by the Node. This will result

in the Node using the network resources in an extensive manner. To reduce the latency

in the communication and to avoid bandwidth bottlenecks, a high speed Ethernet port

should be part of the speciﬁcations.

Keys and smart cards

The DECODE architecture will provide an authentication method to interact with the

system, as described, the main entry point will be via the Wallet.

Traditional authentication mechanisms consist in only one factor authentication like

a pin code or password. But password based security has proven to be insuﬃcient

to prevent unauthorized access to websites, networks and hardware devices. For this

reason, users are now requiring multiple factor authentication, usually called 2FA for

Two-factor authentication, 3FA for Three-factor authentication, etc. By combining several

authentication factors, the authentication process is made more secure. Authentication

factors include:

•

Knowledge factors: The users needs to prove knowledge of a secret that only themselves

know. Typical secrets include passwords, PIN codes, answer to secret question etc.

•

Possession factors: An object that the user owns is used as a key to access the system.

Typically, objects used in authentication include passive or active tokens, smart card

chips packaged in a variety of form factors (key, token, ring, badge, etc.).

•

Inherent factors: something associated with the user, such as biometrics, are used

as a key to access the system. Examples include ﬁngerprint readers, retina scanners,

voice recognition etc.

In order to make access more secure DECODE will optionally support hardware based

authentication with login tokens that provides 2FA via the U2F standard. The login

token can safeguard and manage digital keys for strong authentication and provide crypto

processing. These modules traditionally come in the form of a plug-in card or an external

device that can be attached directly to a DECODE Hub.

Open source examples for hardware security modules and login tokens:

Authentication keys:

• Nitrokey:

Nitrokey is an USB key that enables high security encryption, signing of

data and login to the Web, networks and computers. Both Hardware and software

are Open Sourced.

• U2F zero:

U2F Zero is a USB key that works with all services that support U2F. It

works for 2 factor authentication and sometimes password replacement. There is a

button on the key that the users press to authenticate themselves.

• FST-01 (Flying stone):

This is a small 32 bit computer that comes in the shape

of a USB key

Hardware secure modules:

• CrypTech Alpha:

“The CrypTech Alpha is an open source standalone prototype

key-storage and hardware cryptography platform.”

• Pitchfork:

Project PITCHFORK is a small dedicated computer for handling your

cryptographic operations and keys.

IoT connectivity

A core use-case for the DECODE project is to provide a set of tools to enable personal

IOT data to be securely managed.

Integrating with the plethora of IoT devices on the market is a non-trivial problem and

one that the DECODE project considers solving by :

Normalisation

Data from devices range from high level representations in JSON and

XML to a series of bytes. Normalisation is the process of transforming into a common,

open format. JSON-LD (https://json-ld.org/) is an example of one such format.

Semantic Understanding

Once data is normalised it is important to understand the

meaning of the data. To add this understanding you could use an ontology such as the

M3-Lite (http://ontology.ﬁesta-iot.eu/ontologyDocs/m3-lite.owl#).

An example of a tool that provides this approach is the device-hub software oﬀered by

Thingful. The tool is available at https://github.com/thingful/device-hub

DECODE applications

What is a DECODE application?

A DECODE application is any software application capable of interacting with the

DECODE nodes, constituting the main endpoint for human interaction with DECODE.

A DECODE application is composed of several parts:

• Systems external to DECODE such as websites, databases and mobile apps

•

Smart rules created by the application developer and deployed to the DECODE

network. These represent core contracts of the application

•

A DECODE account cryptographically controlled by the Operator of the application

which is linked to the application

•

A Proﬁle which declares which attributes an application requires and their related

metadata

The systems which are external to DECODE will interact with DECODE via a Wallet

that is connected to the account of the operator. This will provide the ability to deploy

contracts and execute transactions.

As previously mentioned, applications will be able to query the ledger to obtain information

about transactions (see section “Distributed Ledgers”). Although at time of writing this

is still an evolving topic.

An important aspect of applications is that they should provide a high degree of trans-

parency as to who operates them, what data they will require / generate and for what

purpose. To this end, DECODE will require all applications to be registered in an ap-

plication register which will provide references to evidence concerning the operator. For

example, in the UK there is a public record of companies which can be referenced e.g.

https://beta.companieshouse.gov.uk/company/04091535.

DECODE will continue to explore and evolve the concepts around operators and their

trust relationship with participants. Please refer to the decode project website for the

latest news on how DECODE is being applied and tested in the ﬁeld.

The range of applications for DECODE is wide. In order to bring together the concepts

presented here and illustrate how they work together in a more concrete way, we consider

here several applications as illustrative examples of the way in which the various DECODE

components interact to provide a service.

These are:

• Participatory Democracy

• Participatory Citizen Sensing (IoT)

• Peer to peer veriﬁcation of credentials

• Digital commons and Open data

Example - participatory democracy through petitions

In this example a City Authority would like to allow citizens to participate more directly

in decision making. One way to do this is to provide support for Citizens to support

proposed initiatives through signing a petition. This example of course can be generalised

to any context in which a group of people wish to create a petition and is closely related

to an example where participants vote between choices, either as a Poll or a vote.

It is important to note that actual Legal voting is somewhat beyond the scope of DECODE

at this stage as it requires many more legal constraints, however it can be seen as a step

in that direction that exempliﬁes the use of cryptography and ledgers.

There are several important invariants for this system:

(1)

It should not be possible for any entity to be able to connect the real world identity

of a signatory of the petition to their signature

(2)

Any entity should be able to cryptographically verify the results of the petition (how

many signatories there were)

(3)

It should not be possible for a participant to sign the petition twice, or should be

possible to identify that two signatures are from the same account

(4)

A signatory must demonstrate cryptographic evidence that they are a legal resident

of the city

(5) It must be possible for a signatory to withdraw their support

(6)

It should be possible to gather demographic information (e.g. Age group) about the

signatories in a privacy preserving manner and only with their consent and awareness

(7)

The petition mechanism should be decentralised to avoid interference or subversion

by any single entity

The foundation for implementing this scenario in DECODE is that of Attribute Based

Credentials (ABC). As we have described previously, this mechanism allows that a

participant can obtain a credential issued by the city authority and cryptographically

linked to the participants private key, but without the participant being required to share

their private key with the council. This means that whilst the citizen must engage with

the authority in an exchange in order to obtain the credential, the council has no contact

with the account of the participant and so cannot later link the real world identity to the

signature satisfying (1); It is also possible when issuing the credential to provide a unique

token that can be used to satisfy (3).

The integrity and tamper resistance is provided by utilising a distributed ledger to verify

the results. The application of zero knowledge proofs provides us with a mechanism to

ensure that we do not need to store the credentials themselves (private data) on the ledger.

The core petition mechanism is an example of a “distributed application” this is in DECODE

terms a more tightly deﬁned notion than for example in Ethereum. In DECODE it is a

“distributed application with levels of guarantee about privacy by design built in”.

The core of the implementation of the petition in DECODE is the Smart Rules which

describe the logic of the contract that implements the invariants above.

The execution of these smart rules are as described previously made of two cryptographically

bound parts, the contract and the veriﬁer. The contract will execute in the wallet and

will cryptographically access the credential, conﬁrm that this user has not voted twice and

that the credential is indeed provided by the relevant city authority (it is cryptographically

linked to a well-known and trusted public key of the city). And if all the invariants are met,

will construct a proof which can be stored on the ledger, linked to the contract instance

(the particular petition the participant is signing) to which it belongs. At this stage it

increments a counter in the contract to indicate the number of votes.

This proof is the “signature” of the participant. Given that the ledger has the list of proofs,

it is now possible for anyone to be able to cryptographically verify that those proofs were

in fact generated by someone in possession of the credentials indicating their residency,

and that they have executed the invariants in the contract which prevent them from voting

twice (2, 3).

We can also extend the contract such that at the same time as incrementing a counter for

the number of signatures, we also increment various counters for aggregate statistics, for

example age range. Because the contract is executed within the control of the participant

(inside their wallet), they choose whether or not to provide this data. Depending on the

circumstances, it may or may not be mandatory to also increment the age range counter.

In any case, this needs to be clearly communicated to the participant during the process of

signing (as discussed in the user experience section of wallets). Another important privacy

by design principle here is that only the information required is transmitted. For example

an alternate implementation would be to send (or worse record) the participant’s data of

birth to be used to calculate the age range.

By employing the combination of ABC, a privacy preserving ledger (does not contain any

private data) and zero knowledge proofs, DECODE is able to satisfy the key invariants

outlined and provide a robust and provable engine that will give authority to any petition

that is recorded, robust enough to meet the stringent demands of a city authority engaged

in participatory democracy. As noted, to be able to conduct a formal legal vote is beyond

this scope as it requires considerably more controls around physical voting devices for

example, however, its possible to see that with the application of hardware described

previously DECODE takes a step in that direction.

Signing petitions or voting is not limited to participatory democracy. It is in fact a very

common activity amongst any group and will have wide-ranging utility to community

movements and organisations. For example UNICEF have successfully developed a

community project called Ureport which does exactly this and enables communities to

have a voice.

Example - participatory citizen sensing (IoT entitlements)

Noise pollution is an issue for a number of citizens living in particularly noisy areas, such

as, large public squares where activities take place. In these areas there is higher than

average participation in citizens setting up IoT devices that measure noise. In this example,

an involved citizen is interested in the correlation between health data (sleep patterns)

and the levels of noise pollution in the area.

It is important to note that this example, integrates entitlements across public and sensitive

personal data. In this context, private, personal and sensitive personal data can be deﬁned

as follows

•

Private Data: In information science, this refers to data that is considered private,

but may not may not be related to a physical person.

•

Personal Data: Any information related to a natural person or ‘Data Subject’, that

can be used to directly or indirectly identify the person. (EU, n.d.)

•

Sensitive personal: Personal data consisting of information on the racial or ethnic

origin of the data subject, political opinions, religious beliefs etc. (EU, n.d.)

Several cities include IoT devices that measure pollution levels (including noise) and

publish this data in an open an accessible format. Sentilo is an example of an open source

sensor and actuator platform designed to ﬁt in the City architecture, in several cities such

data is freely and openly accessible.

Individual citizens regularly measure and gather data from wearable devices such as

activity, sleep, blood pressure, and heart rate etc. Terrabytes of IoT data from personal

wearable devices currently live in closed data silos which are not amenable to contributing

to a Digital Commons dataset. Combining both private and public data in this context,

can lead to new insights about citizens habits and correlations. DECODE provides a

privacy aware solution to establishing this union of data sets, giving people the ability to

control the visibility of their personal data.

In this example, DECODE will be used as a smart rule based data entitlements engine for

IoT data streams. Within DECODE, a complete and normalised ontology for the IoT data

will be provided by the IoT connector. This maps all data coming from external sensor

devices to an ontology known to DECODE. With privacy in mind, a user’s preferences on

data sharing policies are captured and translated to a smart rule language.

The smart rules enable setting data entitlements below (as a prototype)

• owner-only - the data is not discoverable or accessible and is essentially private.

•

can-discover - the data is discoverable and will be made available for search. The

data is not accessible.

• can-access - the data is accessible and by default discoverable.

To qualify the terms used above: - discoverable - the existence of the data can be found.

- accessible - the value of the data can be viewed. For the data to be accessible it is of

course discoverable.

Based on the user’s preferences and the ontology of the IoT data being processed by

DECODE, entitlements rules to access this data are added to the attributes on the data.

DECODE stores three types of data in this scenario

• Meta-data about the devices connected to DECODE

• Entitlements store

• Transactional data on the ownership of the data

•

Device registry (a registry of devices that are known to DECODE and interact with

the system)

Within DECODE, this continues to be a topic of research and evolution. IoT data is

currently both fragmented and siloed, with the application of user interfaces that easily and

transparently allow users to add/remove/change entitlements on their IoT data, DECODE

will enable IoT data to be used to share IoT data in privacy preserving way.

Example - peer to peer identity and reputation veriﬁcation

There has been rapid growth in the sharing economy in the last decade. The presence of

several large online platforms such as Airbnb and has enabled more people to engage in

sharing resources available to them. A core driving factor in this fast growing economy is

trust, and is one of the biggest concerns of using sharing economy platforms.

Sharing economy companies are beginning to understand the importance of that trust. In

a peer-to-peer marketplace, verifying user identity increases trust, and from there users

begins to build their online reputations. Identity veriﬁcation is currently implemented via

third parties undertaking the process of conducting identity and background checks on

the users of the platform. Concerns have been raised that the Veriﬁed ID model disrupts

privacy. Criticism is also spread to the reliance on social networks, which opens up issues of

surveillance, identity theft and fake identity use. This presents a use case for a peer to peer

identity and reputation veriﬁcation. In this example, DECODE is used as a decentralised

platform that enables users to anonymously and securely verify the identity of other users

in their community.

The core implementation of P2P veriﬁcation in DECODE relies on a group of people

acting as a decentralised Issuer within the context of ABC.

•

An unveriﬁed user submits a ‘claim’ for an identity veriﬁcation into the system, for

example, this could be a claim that ‘User X is a resident of block 10, Nicholson street,

Edinburgh’.

• A smart contract is created for this claim, and this is submitted into DECODE.

•

Existing veriﬁed users (or nominated administrators) are notiﬁed of this claim, and

they can anonymously verify the claim, based on their location or association with

the claimant via other applications.

•

When a consensus is reached on the results of the claim contract, the transaction is

deemed complete and the user making the claim is then promoted to a veriﬁed user.

•

The claimant is issued with attribute based credential certiﬁcate to denote that they

are a veriﬁed user.

There is potential for using various DECODE enabled applications for the veriﬁcation

of separate identity attributes and reputation credentials. This moves away from using

a centralised issuing party for credential checking, this provides users the privacy and

control of their data.

This is an area of research both within DECODE and among the blockchain community.

Findings in ‘Designing To Facilitate Genuine Accommodation Sharing: Identity and

Reputation Veriﬁcation’ (Leonaviciute, 2016) particularly in the area of accommodation

sharing have shown that relying only on software based solutions is not enough. There

was a strong demand for community based design decisions, such as approaching networks

of friends or neighborhoods for identity and reputation veriﬁcation.

Example - digital commons and open data

The latest years have seen a rise of movements demanding transparency of data in

general, and specially in the domain of public administrations. Citizens and companies

are increasingly asking for datasets to be released in the form of Open Data, so they can

be shared and reused. These datasets, however, usually provide a general broad picture

but should be combined with other crowd-sourced pools of data and also with private data

in order to fully leverage their potential.

DECODE in this sense can help, by providing a platform where an application to view

public data and generate custom visualizations of it, in relation to each user’s private

information, can be developed. Also, it can help in providing a platform allowing a

controlled crowd-sourcing of data, thus enabling the idea of Digital Commons to go beyond

the simple concept of Open Data. The earlier examples of IoT entitlements or of a petition

system that allows to disclose general information about the voters are two concrete

examples of this.

A detailed example could be a dashboard that mixes public data sources as well as

crowd-sources one. There, each user can generate visualizations that put their proﬁles

in contrast with the general “public trends”, thus obtaining unique information of their

private information in a controlled way (which would be loaded on the client side). The

conﬁguration of each dashboard could be shared with peers so each person gets their own

vision, and even the private data in it could also selectively be shared with the proper

entitlements. Such an application would on the one hand eﬀectively use a mix of public,

private and crowd-sourced data for the common good, and on the other hand exemplify

and induce the need to users to “donate” their data to generate Digital Commons that

allow to tackle societal problems such as pollution and other citizen concerns.

Conclusion

This paper has presented the architecture for the DECODE project, and innovative

proposal for a decentralised application framework that focuses speciﬁcally on data privacy

and entitlements. It combines state of the art cryptographic techniques and evolves the

concepts found in distributed ledgers to contribute to the growing need for people to have

more control of who has access to their data and more transparency over who is using it

and for what purpose.

We have demonstrated the core components of the architecture and the principles and

foundational concepts on which it is built, completing the picture with illustrative examples

of how DECODE can be applied to real world scenarios.

The DECODE project is speciﬁcally target to applying the latest innovations in technology

to the good of citizens and furthering a socially beneﬁcial agenda as opposed to the

centralisation and exploitation of individuals through their data that is rife in the modern

world.

The ongoing evolution of the architecture will be documented via a set of public whitepapers

that will be published on the DECODE website.

DECODE Glossary

Account

An account is the software construct within decode that provides control of attributes and

represents either the Participant, Operator or Attribute veriﬁer in any decode transaction.

The account will ultimately relate to some cryptographic construct such as private / public

key pair. Attributes will be related to and controlled by an account. An account will be

able to submit transactions to the ledger.

Attribute

All data which is in DECODE are attributes. All attributes have the potential to

demonstrate Provenance.

Attribute provenance

Meta-data related to an attribute that relates it to an ontology. All attributes must

specify a link to an ontology. We may also consider optionally adding other meta-data to

attributes that for example describes the source of the attribute data.

Attribute Provenance Veriﬁcation

A cryptographic demonstration of the validity of the provenance of an attribute. A key

property of provenance is that it should be possible to demonstrate provenance without

revealing any connection back to the decode account and hence all the other attributes

related to it, thus preserving privacy of the participant. The assumed mechanism for this

is via some implementation of Zero Knowledge Proofs. All provenance veriﬁcation must

be cryptographically relatable back to an account within DECODE.

Attribute vault

Process running in the DECODE OS. Allows to control access to the attribute data.

Attribute veriﬁer

An entity which has the credentials / authority to verify the provenance of an attribute.

The expression of this veriﬁcation will be through cryptographic form which will then

be associated with the attribute owned by a participant. e.g. Participant Alice has the

attribute “resident of city X” which is related to some cryptographic evidence that this

claim is true, traceable back to some authoritative source of city X. An attribute veriﬁer

will require an account in order to be able to create this veriﬁcation. The entity who is

the attribute veriﬁer may act also act as an operator at the same time. Further, attribute

veriﬁcation and the subsequent use of that veriﬁcation may happen within the same

application. The authenticity of the veriﬁer may itself be veriﬁed by its own attributes.

Attribute Veriﬁcation

Synonym: Attribute Provenance Veriﬁcation

Blockchain

A type of distributed ledger that records transactions in a sequence of “blocks”

Operator

Organisation or individual who is responsible for the build, deployment and operation of an

application. Operators may also own and control attributes via an account within decode.

Operators may also create new attributes that are then associated with participants. The

minimum requirements of eligibility for an operator to deploy an application to the decode

platform require further discussion as the platform evolves. Taking into account a general

desire for greater transparency to the participant of the organisations with whom they are

interacting and sharing data.

DECODE Architecture

The internal architecture of DECODE, node anatomy, communications between nodes,

components that are used to build DECODE.

DECODE Ecosystem

The environment in which DECODE operates, involving other systems, pilots, organisations,

open source communities. We can consider various speciﬁc ecosystems for example the

“Sharing economy” ecosystem which may have diﬀerent characteristics.

DECODE Platform

Software with a high degree of privacy by design that provides the core functionality of

DECODE. For example, DECODE OS, Distributed Ledger, device metadata. (Priya

Samuel, 2017) (Jill Irving, 2017)

DECODE Application

A DECODE application is a domain speciﬁc software application which will leverage the

DECODE platform. Some part of this application may be a website and it is anticipated

that some element of the application will involve deﬁnition and deployment of Smart Rules,

Proﬁle deﬁnitions and Ontology meta data.

DECODE SDK

The SDK is a development kit for modules developed and distributed by other consortium

partners. It can be used to build, test and proﬁle individual software applications on top

of the DECODE OS, both locally and remotely on the continous integration infrastructure.

(I. J. Denis Roio Vincenzo Nicosia, 2017)

DECODE Node

Controlled execution environment where the DECODE Hub runs. Decentralized transac-

tions will be continuously being carried by the Node. (Ernesto E. Lopez, 2017)

DECODE Hub

The DECODE Hub is the hardware component of the DECODE architecture. The Hub

is any device on which the DECODE OS is installed. It provides connectivity to IoT

devices, connects to other DECODE nodes and supports the DECODE OS. As any other

component of the DECODE architecture, the Hub needs to follow the values of openness,

security, scalability, deployability and ﬂexibility. (Ernesto E. Lopez, 2017)

DECODE OS

The DECODE OS is the base operating system running all software designed, developed

and deployed for the DECODE project (I. J. Denis Roio, 2017). The DECODE OS is a

blend of Devuan OS, with DECODE speciﬁc packages included within it.

DECODE Core

The DECODE Core is a process that acts as a co-ordinator for diﬀerent components of

DECODE (Application Smart Rule engines, IOT Connector, Attribute Vault, Ledger

Connector).

Distributed Ledger

A consensus of replicated, shared, and synchronized digital data geographically spread

across multiple sites, countries, or institutions. There is no central administrator or

centralised data storage.

Entitlement

It describe which Participant’s attribute can view or have access to another attribute.

IOT Connector

Previous Term: Device Hub. Maps IoT data coming from external sensor devices to an

ontology known to DECODE.

Ledger Connector

Allows the processes part of DECODE Core to interface with the Distributed Ledger.

Ledger Node

This term is derived from the Bitcoin concept of a node. Bitcoin is a widely known

cryptocurrency based on blockchain that organizes nodes in a peer-to-peer (P2P) network;

any node can join and become part of the network. If a node receives new information, it

broadcasts it to rest of the network. While all nodes listen to and broadcast information,

only special nodes can append information to the blockchain. (Mustafa Al-Bassam, 2017)

Metadata service

The metadata service is responsible for maintaining an index of discoverable data and

their locations, displaying any data that is accessible, allow a user to make an entitlement

request to access data that is not yet accessible. (deVilliers, 2017)

Node Host

This refers to an (online) service provider hosting nodes on behalf of participants.

Ontology

In computer science and information science, an ontology is a formal naming and deﬁnition

of the types, properties, and interrelationships of the entities that really or fundamentally

exist for a particular domain of discourse. It is thus a practical application of philosophical

ontology, with a taxonomy. Speciﬁcally in information science terminology, an ontology is

a referenceable “schema” which describes the attribute. As raised, we need to be careful

this does not become too restrictive. There is a wider discussion around this from the

device hub work. While all attributes require a deﬁnition, registering changes to ontologies

is an open process. Some governance / structure will be needed (to be discussed later).

We will also need to consider evolution of ontologies over time.

Participant

An individual who digitally participates in the DECODE ecosystem. Participation occurs

by interacting with an application. participants own and control attributes via their

account.

Proﬁle

Relates to the set of attributes which are required application to run. There are as many

proﬁles as there are Applications. It is application speciﬁc as to whether the attributes

need to be veriﬁed. A Proﬁle may also declare attributes that it will generate and then be

associated with an account, for example browsing behaviour, favorites, reccommendations.

Smart Contract

A computer protocol intended to facilitate, verify, or enforce the negotiation or performance

of a contract.

Smart Rule engine

Process running in the DECODE OS. It is part of the Application and runs the Application

Smart Rules.

Smart Rule

They are Application speciﬁc functions that take attributes (or objects) and create

entitlements.

SSO (Single Sign On)

It is a property of access control of multiple related, yet independent, software systems.

With this property, a user logs in with a single ID and password to gain access to a

connected system or systems without using diﬀerent usernames or passwords.

Transaction

Transactions are the application of one or more valid procedures - according to type - to

active input objects, and possibly some referenced objects, to create a number of new

active output objects. (George Danezis, 2017)

Bibliography

Alpar, G. (2015) Attribute-based identity management: Bridging the cryptographic design

of abcs with the real world. Uitgever niet vastgesteld.

Barrett, C. W. et al. (2009) Satisﬁability modulo theories. Handbook of satisﬁability.

185825–885.

Bethencourt, J. et al. (2007) ‘Ciphertext-policy attribute-based encryption’, in Proceedings

of the 2007 ieee symposium on security and privacy. SP ’07. [Online]. 2007 Washington,

DC, USA: IEEE Computer Society. pp. 321–334. [online]. Available from: http:

//dx.doi.org/10.1109/SP.2007.11.

Buterin, V. (n.d.) Ethereum white paper [online]. Available from: https://github.com/

ethereum/wiki/wiki/White-Paper#history.

Costin, A. (2017) Lua code: Security overview and practical approaches to static analysis.

De Moura, L. & Bjørner, N. (2011) Satisﬁability modulo theories: Introduction and

applications. Communications of the ACM. 54 (9), 69–77.

Denis Roio, I. J. (2017) D4.4 ﬁrst release of decode os.

Denis Roio, I. J., Vincenzo Nicosia (2017) D4.1 decode os software development kit (sdk).

deVilliers, M. (2017) Data access and transaction management module [online]. Available

from: https://decodeproject.eu/publications/decodes-data-access-and-transaction-management-module.

Drummond Reed, D. H., Jason Law (2016) The technical foundations of sovrin [online].

Available from: https://sovrin.org/wp-content/uploads/2017/04/The-Technical-Foundations-of-Sovrin.

pdf.

Eleonora Bassi, J. C. D. M., Marco Ciurcina (2017) D1.8 legal frameworks for digital

commons decode os and legal guidelines.

Ernesto E. Lopez, K. E. (2017) D4.3 provisional hardware platform [online]. Available

from: https://decodeproject.eu/publications/decodes-provisional-hardware-platform.

EU (n.d.) GDPR glossary of terms [online]. Available from: http://www.eugdpr.org/

glossary-of-terms.html.

Fowler, M. (2010) Domain-speciﬁc languages. Pearson Education.

Fuster Morell, M. (2014) Governance of online creation communities for the building

of digital commons: Viewed through the framework of the institutional analysis and

development. 281–312.

George Danezis, A. S., Mustafa Al-Bassam (2017) Chainspace: A sharded smart contracts

platform.

Goyal, V. et al. (2006) ‘Attribute-based encryption for ﬁne-grained access control of

encrypted data’, in Proceedings of the 13th acm conference on computer and communica-

tions security. CCS ’06. [Online]. 2006 New York, NY, USA: ACM. pp. 89–98. [online].

Available from: http://doi.acm.org/10.1145/1180405.1180418.

IBM Research (n.d.) Identity mixer [online]. Available from: https://www.zurich.ibm.

com/identity_mixer/.

Jaap-Henk Hoepman, E. B., Shehar Bano (2017) D1.2 privacy design strategies for the

decode architecture.

Jan Camenisch, A. L. (2001) ‘An eﬃcient system for non-transferable anonymous cre-

dentials with optional anonymity revocation’, in Advances in cryptology - EUROCRYPT

2001, international conference on the theory and application of cryptographic techniques,

innsbruck, austria, may 6-10, 2001, proceeding. [Online]. 2001 pp. 93–118. [online].

Available from: https://doi.org/10.1007/3-540-44987-6_7.

Jill Irving, J. B., Jen Hughes (2017) D1.1 decode scenarios and requirements

deﬁnition report [online]. Available from: https://decodeproject.eu/publications/

pilot-scenarios-and-requirements.

Leonaviciute, I. (2016) Designing to facilitate genuine accommodation sharing: Identity

and reputation veriﬁcation.

Lessig, L. (1999) Code is law. The Industry Standard. 18.

Louwerse, M. M. (2004) Semantic variation in idiolect and sociolect. Computers and the

Humanities.

Michael Colesky, C. H., Jaap-Henk Hoepman (2016) ‘A critical analysis of privacy design

strategies’, in 2016 IEEE security and privacy workshops, SP workshops 2016, san jose,

ca, usa, may 22-26, 2016. [Online]. 2016 pp. 33–40. [online]. Available from: https:

//doi.org/10.1109/SPW.2016.23.

Momot, F. et al. (2016) ‘The seven turrets of babel: A taxonomy of langsec errors

and how to expunge them’, in IEEE cybersecurity development, secdev 2016, boston,

ma, usa, november 3-4, 2016. [Online]. 2016 pp. 45–52. [online]. Available from:

https://doi.org/10.1109/SecDev.2016.019.

Mustafa Al-Bassam, G. D., Shehar Bano (2017) D3.1 survey of technologies for abc,

entitlements and blockchains.

Priya Samuel, C. S. C., Jim Barritt (2017) D4.2 online test infrastructure.

Raymond, E. S. (2003) The art of unix programming. Pearson Education.

Roio, D. (2017) Algorithmic sovereignty.

Sober, E. (1978) Computability and cognition. Synthese.

Symons, T. (2017) DECODE project dissemination strategy and communication plan -

initial.

Tom Symons, T. B. (2017) Me, my data and i: The future of the personal

data economy [online]. Available from: https://decodeproject.eu/publications/

me-my-data-and-ithe-future-personal-data-economy.