commit bc6ca9975e9b9014a24855be90b5c912f043daac Author: Jaromil Date: Mon Nov 12 10:18:08 2018 +0100 import after completion diff --git a/DECODE_D3.5_Initial definition of Smart Rules and Taxonomy.pdf b/DECODE_D3.5_Initial definition of Smart Rules and Taxonomy.pdf new file mode 100644 index 0000000..b5b4e23 Binary files /dev/null and b/DECODE_D3.5_Initial definition of Smart Rules and Taxonomy.pdf differ diff --git a/config.zsh b/config.zsh new file mode 100644 index 0000000..9de3502 --- /dev/null +++ b/config.zsh @@ -0,0 +1,34 @@ +# Writedown +# generic configuration defaults for rendered files + +WRITEDOWN_TITLE="Initial definition of Smart Rules and Taxonomy" +WRITEDOWN_AUTHOR="Denis Roio, Marco Sachy, Federico Bonelli" +WRITEDOWN_AFFILIATION="Dyne.org" +WRITEDOWN_DATE="Friday 6 April 2018" +WRITEDOWN_TAGS="[decode, smart rules, taxonomy, WP3]" + +# number for each section +WRITEDOWN_NRSEC=yes +# table of contents +WRITEDOWN_TOC=yes +# bibliographic citation style (see writedown/citstyle) +WRITEDOWN_CITSTYLE=harvard-kings-college-london +# font size +WRITEDOWN_FONTSIZE=12pt +# bibtex file for bibliographic sources +# WRITEDOWN_BIB=views/references.bib +# latex template (header and footer) +WRITEDOWN_LATEX_TEMPLATE=views/template.tex + +# different formats as supported by pandoc. +# to activate uncomment and fill, then use dash (-) as first argument +# i.e: ./writedown/render - +# WRITEDOWN_OUTPUT_FORMAT=epub +# WRITEDOWN_OUTPUT_EXTENSION=epub + +# default pandoc base command +# WRITEDOWN_PANDOC="pandoc --smart --standalone -f markdown + +# Experimental features are commented below + +# WRITEDOWN_ZOTERO="no" diff --git a/views/abstract.txt b/views/abstract.txt new file mode 100644 index 0000000..d0c3a51 --- /dev/null +++ b/views/abstract.txt @@ -0,0 +1 @@ +To facilitate transparency, multiple implementations, wide adoption and standardisation, DECODE develops a smart rule language and execution engine. All read and write operations affecting entitlements and accessing data can be expressed in this language, which we will design to become a robust open standard for authorisation around personal data. Such a language will aim to be data centric and functional, to naturally avoid complex constructions and define sets of transformations that can be then easily represented with visual metaphors. diff --git a/views/deliverable.md b/views/deliverable.md new file mode 100644 index 0000000..5b53701 --- /dev/null +++ b/views/deliverable.md @@ -0,0 +1,357 @@ +# Introduction + +This deliverable principally consists of a working implementation +(ALPHA stage) made available in source-code format and binary format +compiled for several target architectures, demonstrating the extreme +portability of this language interpreter. + +This document accompanies the deliverable with a brief overview of +characteristics and implementation choices deriving from DECODE's +deliverable D3.3 "DECODE language design patterns" which is a living +document currently indicated as the Whitepaper for the Zenroom +implementation. + +Following the publication of this deliverable, both documents will be +merged into the Zenroom whitepaper, a living document nurtured by all +findings published along this research path. + +The following sections of this document are briefly illustrating the +design choices made so far in developing a minimal language to express +key privacy and integrity logic policies for data items, binding +cryptographic primitives and human language into a domain-specific +language (DSL). + +## High level and low level + +This research is best understood by envisioning the dualistic path +taken in the effort of making two extremely loose and far apart ends +meet: the technical language of cryptography and the human language of +rule expression. There is certainly no shortage of literature on the +topic and it is well beyond the scope of this document to debate its +values. + +What this document delivers is a practical attempt which is still a +work in progress at the time of writing, to make the loose ends meet +by virtue of a foundational DSL implementation that on one side +facilitates the expression of cryptographic schemes and on the other +side, still in progress, matches the emerging semantic with the +studies made on DECODE pilots and their needs to clearly express +credentials and entitlements. + +The following implementation has therefore to be seen as the common +ground on which we are grafting our understanding of the pilot needs +on the cryptographic schemes implemented in DECODE. + + +# Implementation + +The implementation is named "Zenroom" and is available at the +following web address https://zenroom.dyne.org and the release of this +deliverable coincides with the release of version 0.5 of this +software, following the progression that was started by deliverable +D3.3 and that lead to this deliverable across the iterations reported +in its ChangeLog: + +``` +## 0.5.0 +### April 2018 + +Fully adopted Milagro-crypto-C as underlying crypto library, +abandoning luazen at least for now. Refactored the API and language +approach to adopt a more object-oriented posture towards first-class +citizen data objects (octets) and keyrings. Full ECDH implementation +with support for multiple curve types. + +Direct-syntax interpreter upgraded to Lua 5.3; dropped dependency from +lua_sandbox effectively cleaning up large portions of code. + +Improved support for javascript; implemented a cryptographically +secure random generator linked to different RNG functions provided by +native platforms. Added build targets for Android and iOS, improved JS +support both for NodeJS and WASM targets. + +Adopted an embedded memory-manager (umm) optionally enabled at +runtime, achieving significant speed improvements, reduction of +resources used and full control on memory allocation; adopted a +function pointer mechanism to easily include different memory managers +in the future. + +Updated documentation accordingly with more examples and +tests. Half-baked RSA implementation may be abandoned in the future +unless use-cases arise. + + +## 0.4 (ALPHA) +### March 2018 + +Major improvements to standard Lua direct-syntax compatibility, port +to emscripten, osx and win targets. Documentation using LDoc and +website. Support for cjson and other embedded extensions. First +binary release, enters ALPHA stage. + + +## 0.3 (Prototype) +### February 2018 + +Build fixes for various architecture targets. Milagro integration, +test suites, continuous integration setup. + +## 0.2 +### December 2017 + +Whitepaper and improved Lua support. +Adopted luazen in place of luanacha. + +## 0.1 (POC) +### November 2017 + +Proof of concept based on lua_sandbox +``` + +The technical documentation of Zenroom is partially already covered in +its online API documentation and should be seen complementary to this +document, made available on https://zenroom.dyne.org/api + +## Features + +Zenroom can be primarily defined as a "virtual machine". It is +self-contained and can be compiled as a completely static binary, +without any dependency and ties to the host operating system. + +Zenroom does not require any access to the network nor to the +filesystem, it simply processes data as input to return data as output +and in doing so it adopts its own experimental memory management +without even relying on the memory allocation calls provided by the +OS. Its development will continue in the direction of making this +component as minimal and independent as possible in covering its role, +which is that of interpreting language describing a set of rules that +operate cryptographic transformations on rather complex data +structures. + +The namespace of reference for cryptographic primitives in Zenroom, +likely to be adopted also in other DECODE component implementations, +is the one provided by the Apache Milagro library, which seems to be +well succesfull in establishing itself as an efficient +[@budroni2017efficient] and de-facto standard implementation library +with no further dependencies, undergoing adoption for privacy aware services [@rios2017query] and Internet of Things products [@scott2016sok]. + +Zenroom is extremely portable, being written following the C99 +standard [@ritchie1988c] whenever possible. As of today we managed to +port its binaries to all major desktop platforms (Windows, Apple and +GNU/Linux) plus major mobile platforms (Android and iOS) and to Java +platforms via JNI. Last not least Zenroom succesfully compiles and run +as "Javascript code" via LLVM/Emscripten, de-facto placing this +software as an active player for the upcoming wave of innovations +bound to the adoption of the "WebAssembly" enabling technology in +web browsers [@haas2017bringing]. + +As indicated already in D3.3 Zenroom adopts the Lua engine +[@ierusalimschy1996lua] in a slightly modified form of version 5.3 as +its direct-syntax parser. + +Zenroom facilitates a declarative approach by implementing efficient +schema validation, a crucial feature to secure the development of +taxonomies to a solid data-centric paradigm [@murata2005taxonomy]. It +also allows to write code in lazy functional programming style based +on recursion operators associated with data type definitionson data +[@meijer1991functional]. + +At last, it aims at establishing as first-class citizens +[@kosar2004stork] both simple cryptographic primitives and complex +concepts as keyrings belonging to people and entities. + + +# Taxonomy of pilot entitlements + + +This section presents an analysis that is foundation to future +development directions for Zenroom to express nouns and predicates +emerging from the analysis of entitlements across pilots. The +challenge ahead will be that of connecting this taxonomy with well understandable scripts that can cover most of the configurations described. + +We proceed presenting an exemplary set of Smart Rules and related +attributes for the application of DECODE's language development to +pilots. The rationale for the selection of privacy by design +strategies for this pilot descends from the need to apply the +principles of minimization, separation, abstraction, hide, +information, control, enforcement and demonstration as outlined in +deliverable D1.2 (Privacy Design Strategies for the DECODE +Architecture). + +By endorsing an inductive methodology to pilot design, the goal is to +define a general taxonomy of Smart Rules, attributes and entitlements +that comply with the approach to Attribute Based Credentials defined +in deliverable D1.4 (First Version of DECODE Architecture). + + +## iDigital Decidim + +In this first case, the problem to be solved is to provide safe +identification for users while being sensitive about sharing sensitive +user data to extract valuable information about city concerns that +might be later be used to propose data-driven policies in the +city. (Cf. D1.1 - Scenarios and Requirements Definition +Report). Accordingly, the solution or service to be provided is a set +of rules for data sharing/ data “donation” by participants/owners +under the rules issued by the issuer, i.e. the promoters of the +Decidim platform. This dynamic can be audited by a relying party, for +instance the Municipal Information technology Insititute at Barcelona +City Council. + +The rules, attributes and entitlements summarised below are meant to +show in an intelligible form how sensitive personal data can be used +for the public good, shaping the form of the “data commons”. The +service is open source and can be adopted by other municipalities or +companies who want to study the data for both data-driven public +policymaking and private business, within a GDPR compliant +environment. + +In such an environment the stakeholders are all users of Decidim, +research institutions interested in urban matters such as Eurecat and +UB, data journalists, data service related industries and developers +(Data Beers BCN, BCN Analytics Hub) and app developers and hackers who +want to use Metadecidim data and DECODE platform to develop new +services. Also citizens who wish to learn / use data analysis +techniques and share them (Cf. D1.1 - Scenarios and Requirements +Definition Report). + + +Key enabling factors: +- Transparency in data storage and user entitlements: enable users to control where their data is stored, choose what identifying information is shared and the granularity of access levels for that information +- Auditable petition signing process: As a provider for enabling citizens to make collaborative decisions, there should be a way to audit and verify transactions in the system in a reliable manner + +Hypothesis statement: + +> As a user I want to sing a petition in a secure, transparent and audible process, and control the granularity of access to personal information I share with my petition. + + +Result: +- minimal app for users to decide data sharing rights (HOW MANY, what are them) and who accessed their data (Possible TOKEN3). +- minimal visualisation of Decidim data and knowledge extraction to show to users that donated their data + +Below a preliminary set of Smart Rules (SR) for Decidim as derived +from the current Privacy Policy and Terms of Use as published by +Barcelona City Council on decidim.barcelona: + +- SR1: audit storage —> the user can audit the storage of her data within the file “Citizens Participation” located in the Decidim servers on the premises of Barcelona City Hall updated to run a DECODE node. +- SR2: data subject credentials for registration —> national ID number, date of birth, post code to be accessed by Decidim according to Attribute Based Credentials framework. Moreover the data subject must create a password and accept of GDPR compliant privacy policy and terms of use +- SR3: granularity of access levels for that information +- SR4: Audit transactions, i.e. petition vote +- SR5: verify transactions, i.e. petition vote +- SR6: submit a proposal +- SR7: modify proposal +- SR8: signal to data subjects any change in privacy policy +- SR9: allow data subjects to amend their personal data sharing policy +- SR10: allow data subject to cancel their subscription +- SR11: allow registration for natural persons only if attribute “age” : decode account; age of subscriber; > 16 years +- SR12: allow registration to legal entities such as groups, collectives, city organisations with the following credentials —> name of organisation, responsible person, telephone number of the organisation, email of the organisation, password, acceptance of GDPR compliant privacy policy and terms of use +- SR13: illegal use of the platform (copyright, trademark infringements; publishing personal data belonging to other data subjects; sending spam or viruses; setting up pyramid schemes, ponzi schemes; commercial ads; non conformity with public decency; create multiple users to steer voting) +- SR14: banning a participant +- SR15: waving Decidim from the responsibility to address disputes among participants. +- SR16: participants Intellectual Property Right: all users generate contents will be published under Creative Commons license (CC-BY-SA). +- SR17: Only the user name, a pseudonym, is public information accessible to third parties. + +## IoT Pilot involving CitizenSense + +This pilot focuses on data produced by citizens in the context of +crowdsourced scientific research through leveraging data subjects’ +data donations. The latter come from different sensors and devices, +especially smartphones that can put at risk both the implementation of +the research and the safety of data subjects producing and donating +data. In the case of this pilot the sensor is made by an Arduino chip +and a minimal web interface that communicates with the Smart Citizen +platform. + +In particular, Barcelona second pilot, CitizenSense is a pilot +designed to solve the problem of suitable and safe participation to +the initiatives promoted under the umbrella of “Oficina de Ciencia +ciutadana”. The goal is to offer a GDPR compliant smart city service +connecting the Open Data Barcelona portal to the Open Data +infrastructure through DECODE to build and manage "data commons" +datasets. + +These datasets are currently gathered on ODI (Open Data +Infrastructure), Sentilo, IRIS (Incidències, Reclamacions i +Suggeriments), ASIA (Aplicatiu de Sistemes Integrats d’Atenció), +CityOS (City Operating System) from Barcelona City Council +infrastructure; and two public sources, i.e. Smart Citizen and Inside +Airbnb (CF. D5.3 - Data analysis methods and first results from +pilots). + +The pilot would be a proof of concept for how a decentralised storage and access rights ledger, with dynamic permissions (in the sense that citizens can revoke access, could be used to support distributed sensing projects. This includes the data sharing part, but also the decentralised (or at least hashed) data storage solutions of highly non scalable IoT sensing data streams (Cf. D1.1 - Scenarios and Requirements Definition Report). + +Key enabling factors: + +- DECODE Hubs to store the data access permissions, that should be connected to the infrastructure where the actual IoT data is stored. +- DECODE Node running on DECODE OS that would mediate access of a specific CitizenScience project to the DECODE Hubs. + +Hypothesis statements: + +- As a user I want to be in control of my data” +- As an IoT platform provider I want to give users a transparent , traceable, secure, collaborative platform. (CF. D1.1 - Scenarios and Requirements Definition Report). + +Below a preliminary set of Smart Rules (SR) for CitizenSense: + +- SR0: audit storage —> the user can audit the storage of her data, also by mining the dataset s/he co-produced in complete anon- or pseudonymity. +- SR1: citizen revokes access to the data produced and donated by data subjects. +- SR2: find data from citizens +- SR3: access data from citizens +- SR4: manage data from citizens +- SR4: save data from citizens +- SR5: register data donor with the possibility to recall them for new research +- SR6: register research projects and put them in touch with data donors willing to take part to the research +- SR7: banning a participant +- SR8: verify integrity of data +- SR9: data access traceability +- SR10: Data transparency +- SR11: Data reusability +- SR12: expiration date - at some point, i.e. end of research data gathering, the validity token should expire although a users can opt out at any moment before token validity expiration. + + +## Holiday Rental Registry / FairBnb + +The pilot aims at combining the FairBnb community and Short Term Rental Register in Amsterdam. The goal is to show that DECODE can support the implementation of a city wide register. In order to achieve this goal, a web application that enables Amsterdam residents to register rental periods with the municipality will be developed. + +Below a preliminary set of Smart Rules (SR) for Holiday Rental Registry / FairBnb: + +- SR0: audit storage —> the user can audit the storage of her data, also by mining the dataset s/he co-produced in complete a non- or pseudonymity. +- SR1: revoke access to data produced and shared by data subjects. +- SR2: landlord submit data once +- SR3: landlord shares data submitted many times +- SR4: enabling FairBnb to interact with data collected by the city +- SR5: citizen authenticates as an Amsterdam citizen against Municipal Personal Records Database +- SR6: citizen registers address for rental on Short Term Rental Register in Amsterdam (Check address validity against Cadastre) +- SR7: landlord registers rental periods on Short Term Rental Register in Amsterdam +- SR8: give landlord information on the balance within the 60 days annual rental limit +- SR9: give municipality information on the balance within the 60 days annual rental limit +- SR10: FairBnb issues a certificate (token) to the municipality to record that two peers reached consensus for a rental transaction +- SR11: Banning a landlord from business if s/he goes beyond the 60 days limit +- SR12: register guest (attribute?) +- SR13: register local business to take part to distribute hospitality platform FairBnb +- SR14: register citizen who is not a landlord (desirable? attribute?) + + +## Gebiedonline + +Gebiedonline (Neighborhood Online) is an Amsterdam based online neighbourhood platform that is cooperatively run and owned. Every decision is made within the community. The platform aims to enable people, groups and organisations to view events taking place in the area, share news, exchange and borrow products and services, and to meet people in a GDPR compliant environment. + +Below a preliminary set of Smart Rules (SR) for Gebiedonline: + +- SR0: Audit storage —> the user can audit the storage of her data, also by mining the dataset s/he co-produced in complete a non- or pseudonymity. +- SR1: revoke access to data produced and shared by data subjects. +- SR2: collective decision making +- SR3: citizen registration +- SR4: group registration +- SR5: organization registration +- SR6: create event +- SR7: publish event +- SR7: view event +- SR8: share news +- SR9: contact peers +- SR10: offer product +- SR11: borrow product +- SR12: offer service +- SR13: borrow service +- SR14: banning subscriber +- SR15: manage data sharing rights + diff --git a/views/index.txt b/views/index.txt new file mode 100644 index 0000000..7b4e821 --- /dev/null +++ b/views/index.txt @@ -0,0 +1 @@ +deliverable.md diff --git a/views/references.bib b/views/references.bib new file mode 100644 index 0000000..f62d81f --- /dev/null +++ b/views/references.bib @@ -0,0 +1,76 @@ +@article{budroni2017efficient, + title={Efficient hash maps to G2 on BLS curves}, + author={Budroni, Alessandro and Pintore, Federico}, + year={2017} +} + +@inproceedings{rios2017query, + title={Query Privacy in Sensing-as-a-Service Platforms}, + author={Rios, Ruben and Nunez, David and Lopez, Javier}, + booktitle={IFIP International Conference on ICT Systems Security and Privacy Protection}, + pages={141--154}, + year={2017}, + organization={Springer} +} + +@article{scott2016sok, + title={SOK it to the IoT}, + author={Scott, Michael and McCusker, Kealan}, + year={2016} +} + +@article{ierusalimschy1996lua, + title={Lua-an extensible extension language}, + author={Ierusalimschy, Roberto and De Figueiredo, Luiz Henrique and Celes Filho, Waldemar}, + journal={Softw., Pract. Exper.}, + volume={26}, + number={6}, + pages={635--652}, + year={1996}, + publisher={Citeseer} +} + +@book{ritchie1988c, + title={The C programming language}, + author={Ritchie, Dennis M and Kernighan, Brian W and Lesk, Michael E}, + year={1988}, + publisher={Prentice Hall Englewood Cliffs} +} + +@inproceedings{haas2017bringing, + title={Bringing the web up to speed with WebAssembly}, + author={Haas, Andreas and Rossberg, Andreas and Schuff, Derek L and Titzer, Ben L and Holman, Michael and Gohman, Dan and Wagner, Luke and Zakai, Alon and Bastien, JF}, + booktitle={Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation}, + pages={185--200}, + year={2017}, + organization={ACM} +} + +@article{murata2005taxonomy, + title={Taxonomy of XML schema languages using formal language theory}, + author={Murata, Makoto and Lee, Dongwon and Mani, Murali and Kawaguchi, Kohsuke}, + journal={ACM Transactions on Internet Technology (TOIT)}, + volume={5}, + number={4}, + pages={660--704}, + year={2005}, + publisher={ACM} +} + +@inproceedings{meijer1991functional, + title={Functional programming with bananas, lenses, envelopes and barbed wire}, + author={Meijer, Erik and Fokkinga, Maarten and Paterson, Ross}, + booktitle={Conference on Functional Programming Languages and Computer Architecture}, + pages={124--144}, + year={1991}, + organization={Springer} +} + +@inproceedings{kosar2004stork, + title={Stork: Making data placement a first class citizen in the grid}, + author={Kosar, Tevfik and Livny, Miron}, + booktitle={Distributed Computing Systems, 2004. Proceedings. 24th International Conference on}, + pages={342--349}, + year={2004}, + organization={IEEE} +}