D4.4 CITADEL final Ecosystem Architecture · 2019. 4. 1. · D4.4 – Final CITADEL Ecosystem...

D4.4 – Final CITADEL Ecosystem Architecture Version 1.0 – Final. Date: 31.03.2019

Project Title: CITADEL Contract No. GA 726755

www.citadel-h2020.eu of 107

Empowering Citizens to Transform European Public Administrations

Deliverable 4.4

Final CITADEL Ecosystem Architecture

Editor(s): Juncal Alonso (TECNALIA) Marisa Escalante (TECNALIA) Gayane Sedrakyan (imec)

Responsible Partner: IMEC

Status-Version: Final – v1.0

Date: 31/03/2019

Distribution level (CO, PU): PU

http://www.citadel-h2020.eu/




Project Number: GA 726755

Project Title: CITADEL

Title of Deliverable: Final CITADEL Ecosystem Architecture

Due Date of Delivery to the EC: 31.03.2019

Workpackage responsible for the Deliverable:

WP4 – ICT Enablers to transform

Editor(s): TECNALIA, IMEC

Contributor(s):

Gayane Sedrakyan (imec) Gerald Haesendonck (imec) Juncal Alonso (TECNALIA) Marisa Escalante (TECNALIA) Leire Orue-Echevarria (TECNALIA) Gorka Benguria (TECNALIA) Iñaki Etxaniz (TECNALIA) Alberto Molinuevo (TECNALIA) Domenico Rotondi (Fincons) Diomede Illuzzi (Fincons) Antonio Campese (InnovaPuglia)

Reviewer(s): Domenico Rotondi (Fincons), Antonio Campese (InnovaPuglia)

Approved by: All Partners

Recommended/mandatory readers:

WP5

Abstract: This deliverable provides the final architecture of the CITADEL Ecosystem, taking as basis scenarios and requirements for services and tools, as well as the initial and intermediate architecture described in WD4.1, D4.3 and WD4.2.

Keyword List: Architecture; functional requirements; ecosystem; design

Licensing information: This work is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) http://creativecommons.org/licenses/by-sa/3.0/


http://creativecommons.org/licenses/by-sa/3.0/




Disclaimer This document reflects only the author’s views and neither Agency nor the Commission are responsible for any use that may be made of the information contained therein

Document Description

Document Revision History

Version Date Modifications Introduced

Modification Reason Modified by

v0.1 17/07/2018 TOC draft version imec

v0.2 18/07/2018 Agreed TOC TECNALIA Fincons

V0.3 8/07/2018 Contributions from all partners All

V0.4 14/07/2018 Integrated version TECNALIA

V0.41 15/07/2018 Ready for review All

V0.42 21/09/2018 Version with comments from the internal review process

Fincons

V0.43 22/09/2018 Addressed comments from the internal review

TECNALIA


V0.5 30/09/2018 Integrated version imec


V0.6 18/03/2019 Integrated version imec

V0.8 26/03/2019 Version with comments from the internal review process

InnovaPuglia

V0.9 27/03/2019 Addressed comments from the internal review

imec

V1.0 31/03/2019 Ready for submission TECNALIA





Table of Contents

Table of Contents .......................................................................................................................... 4

List of Figures ................................................................................................................................ 6

List of Tables .................................................................................................................................. 7

Terms and abbreviations ............................................................................................................... 8

Executive Summary ....................................................................................................................... 9

1 Introduction ........................................................................................................................ 10

1.1 About this deliverable ................................................................................................. 10

1.2 Document structure .................................................................................................... 10

2 CITADEL Ecosystem generic architecture ............................................................................ 11

2.1 CITADEL Ecosystem generic architecture .................................................................... 11

2.2 Design patterns and best practices ............................................................................. 15

2.3 Intended users and their roles .................................................................................... 16

2.3.1 CITADEL actors .................................................................................................... 16

2.3.2 Consolidated use case needs .............................................................................. 17

3 CITADEL Ecosystem architecture detailed design ............................................................... 21

3.1 Intelligent discovery of public services ....................................................................... 21

3.1.1 Main functionality ............................................................................................... 21

3.1.2 Structural overview ............................................................................................. 23

3.1.3 Dynamic overview ............................................................................................... 24

3.1.4 Interface and interaction models ........................................................................ 25

3.1.5 Design implications based on the tool choice ..................................................... 26

3.2 Digital Maturity Assessment ....................................................................................... 26



3.2.2.1 Data base model .............................................................................................. 32




3.3 Co-creation methodology supporting tool .................................................................. 38






3.4 KPI report generation .................................................................................................. 45





3.4.1 KPI visualization and report generation .............................................................. 46

3.4.1.1 Main functionality ........................................................................................... 46

3.4.1.2 Structural overview ......................................................................................... 48

3.4.1.3 Dynamic overview ........................................................................................... 49

3.4.1.4 Interface and interaction models .................................................................... 57

3.4.1.5 Design implications based on the tool choice ................................................. 57

3.4.2 Harvesting +curation+ Fusion of the source data that will be visualized ........... 58






3.5 User assessment .......................................................................................................... 68






3.6 Security Management ................................................................................................. 75

3.6.1 Access Management + Encryption ...................................................................... 75






3.6.2 Anonymization .................................................................................................... 90






4 Conclusions ......................................................................................................................... 95

5 References ........................................................................................................................... 96

Annex 1: Flows of the Harvesting and curation component ....................................................... 99

Annex 2: AuthZ/AuthN and Encryption client libraries ............................................................. 100





List of Figures

FIGURE 1. CITADEL ECOSYSTEMS GENERIC ARCHITECTURE COMPONENT DIAGRAM. ................................... 13 FIGURE 2. THE SIX DUCS ESTABLISHED IN THE BRINDISI AREA .................................................................. 19 FIGURE 3. INTERNAL ARCHITECTURE OF THE INTELLIGENT DISCOVERY COMPONENT. .................................... 24 FIGURE 4. INTELLIGENT DISCOVERY OF PUBLIC SERVICES SEQUENCE DIAGRAM (FOR A CITIZEN USER). ............. 25 FIGURE 5. EXTERNAL INTERFACES OF THE COMPONENT INTELLIGENT DISCOVERY OF DIGITAL SERVICES. ........... 25 FIGURE 6. ID UI, INCLUDING THE DIFFERENT LEVELS (GREEN, ORANGE AND RED) ........................................ 26 FIGURE 7. INTERNAL ARCHITECTURE OF THE DIGITAL MATURITY ASSESSMENT COMPONENT. ........................ 32 FIGURE 8. DIGIMAT DATA BASE MODEL ............................................................................................. 33 FIGURE 9. DIGITAL MATURITY ASSESSMENT SEQUENCE DIAGRAM. ........................................................... 34 FIGURE 10. EXTERNAL INTERFACES OF THE COMPONENT DIGITAL MATURITY ASSESSMENT .......................... 35 FIGURE 11. UI FOR THE DM: MAIN MENU ........................................................................................... 35 FIGURE 12. UI FOR THE DM: VIEW OF THE “ORGANIZATION” DIMENSION ................................................ 36 FIGURE 13. UI FOR THE DM: QUESTIONS IN THE “INTERACTION WITH THE CITIZEN” AREA ........................... 36 FIGURE 14. UI FOR THE DM: QUESTIONS IN THE “INTERACTION WITH THE CITIZEN” AREA ........................... 37 FIGURE 15. CO-CREATION SUPPORT TOOL ARCHITECTURE ...................................................................... 39 FIGURE 16. TOP LEVEL BUSINESS PROCESS AS UNION OF THE 4 PHASES IDENTIFIED IN THE CITADEL CO-CREATION

PROCESS IMPLEMENTATION ....................................................................................................... 40 FIGURE 17. IDEATION AND RESEARCH BUSINESS PROCESS DIAGRAM ......................................................... 41 FIGURE 18. CONCEPT AND DESIGN BUSINESS PROCESS DIAGRAM ............................................................. 42 FIGURE 19. DEVELOPMENT AND IMPLEMENTATION BUSINESS PROCESS DIAGRAM ....................................... 43 FIGURE 20. PRODUCTION AND MAINTENANCE BUSINESS PROCESS DIAGRAM .............................................. 44 FIGURE 21. KPI GENERATION COMPONENT DIAGRAM. ........................................................................... 46 FIGURE 22. INTERNAL ARCHITECTURE OF THE KPI VISUALIZATION AND REPORT GENERATION COMPONENT. .... 48 FIGURE 23. KPI VISUALIZATION AND REPORT GENERATION SEQUENCE DIAGRAM. ....................................... 51 FIGURE 24. FIRST SCREEN OF THE KPI EDITOR. IN THIS CASE A DISTRIBUTION CHART OVER TIME IS SELECTED. . 52 FIGURE 25. SECOND SCREEN OF THE KPI EDITOR IN CASE A DISTRIBUTION CHART OVER TIME WAS SELECTED. HERE

THE TIME INTERVAL, OBJECT, PROPERTY AND DATE VARIABLE ARE SELECTED. ...................................... 52 FIGURE 26. THIRD SCREEN OF THE KPI EDITOR, DISPLAYING HOW BIRTH CERTIFICATES ARE ISSUED OVER TIME. 53 FIGURE 27. SECOND SCREEN OF THE KPI EDITOR IN CASE OF A DISTRIBUTION IN TOTAL. HERE BIRTH AND

MARRIAGE CERTIFICATES ARE SELECTED. ....................................................................................... 53 FIGURE 28. THIRD SCREEN OF THE KPI EDITOR IN CASE OF A TOTAL DISTRIBUTION: HERE THE USER WANTS

FEEDBACK FOR BIRTH CERTIFICATES ISSUED OVER THE INTERNET THAT DO HAVE SOME FEEDBACK. .......... 54 FIGURE 29. THE DISTRIBUTION OF FEEDBACK FOR BIRTH AND MARRIAGE CERTIFICATES ISSUED OVER THE INTERNET.

............................................................................................................................................. 54 FIGURE 30. FIRST SCREEN OF THE KPI EDITOR WHERE A USER SELECTS A COMPARE CHART WITH PROGRESSION

OVER TIME .............................................................................................................................. 55 FIGURE 31. SECOND SCREEN OF THE KPI EDITOR IN CASE OF A COMPARE CHART WITH PROGRESSION OVER TIME.

HERE THE 4 SERVICES ARE SELECTED WITH DATA AGGREGATED PER YEAR. .......................................... 55 FIGURE 32. THIRD AND FOLLOWING SCREEN OF THE KPI EDITOR IN CASE OF A COMPARE CHART WITH

PROGRESSION OVER TIME. HERE BIRTH CERTIFICATED REQUESTED OVER THE INTERNET WILL BE PLOTTED. 56 FIGURE 33. THE ADAPTION RATE OF USING THE INTERNET (COMPARED TO THE OTHER METHODS) FOR THE FOUR

SERVICES IN THE GENERATED DATA. ............................................................................................. 56 FIGURE 34. A PRELIMINARY DASHBOARD DEMONSTRATING SOME KPI’S ON GENERATED DATA. .................... 57 FIGURE 35. EXTERNAL INTERFACES OF THE COMPONENT KPI VISUALIZATION AND REPORT GENERATION. ........ 57 FIGURE 36. HARVESTING/CURATION/FUSION COMPONENT ARCHITECTURE. .............................................. 59 FIGURE 37. READING DATA FROM A SINGLE RESOURCE........................................................................... 61 FIGURE 38. READING DATA FROM A COMBINED RESOURCE. .................................................................... 61 FIGURE 39. EXTERNAL INTERFACES OF THE COMPONENT HARVESTING AND CURATION. ............................... 62





FIGURE 40. USER AUTHENTICATION. ................................................................................................... 62 FIGURE 41. OVERVIEW OF THE CHOSEN DATASETS. ............................................................................... 63 FIGURE 42. ADDING/EDITING A DATA SOURCE. ..................................................................................... 63 FIGURE 43. ADDED RESOURCE AVAILABLE CONVERSION FORMATS IN THE OVERVIEW TABLE. ......................... 64 FIGURE 44. REQUESTING THE ADDED SOURCE IN DIFFERENT FORMAT. ...................................................... 64 FIGURE 45. ADDING A SPARQL QUERY. ............................................................................................. 65 FIGURE 46. RESULTED SPARQL QUERY DATA IN THE OVERVIEW OF AVAILABLE RESOURCES TABLE. ................ 65 FIGURE 47. DATA SOURCE OVERVIEW PANEL. ...................................................................................... 66 FIGURE 48. EXTENDING DATA FORMATS. ............................................................................................ 67 FIGURE 49. INTERNAL ARCHITECTURE OF THE USER ASSESSMENT COMPONENT. ......................................... 71 FIGURE 50. ANALYSIS OF THE ASSESSMENT OF THE SERVICE SEQUENCE DIAGRAM. ...................................... 72 FIGURE 51. ASSESSMENT OF A SERVICE SEQUENCE DIAGRAM. ................................................................. 72 FIGURE 52. CREATE AND PUBLISH A QUESTIONNAIRE SEQUENCE DIAGRAM. ............................................... 73 FIGURE 53. EXTERNAL INTERFACES OF THE COMPONENT USER ASSESSMENT. ............................................ 73 FIGURE 54. UA ANALYSIS UI . ........................................................................................................... 74 FIGURE 55. UA RATING UI. .............................................................................................................. 74 FIGURE 56. OVERALL DIRECTORY SERVICE STRUCTURE. .......................................................................... 78 FIGURE 57. ENCRYPTION + ACCESS ARCHITECTURE. ............................................................................... 80 FIGURE 58. REGISTRATION FUNCTION. ................................................................................................ 82 FIGURE 59. LOGIN FUNCTION. ........................................................................................................... 83 FIGURE 60. GENERATE TOKEN FUNCTION. ........................................................................................... 83 FIGURE 61. UPLOAD FILE FUNCTION. .................................................................................................. 85 FIGURE 62. DOWNLOAD FILE FUNCTION. ............................................................................................ 86 FIGURE 63. REGISTRATION PAGE. ....................................................................................................... 87 FIGURE 64. CREATE POLICY TOOL. ...................................................................................................... 88 FIGURE 65. POLICY VISUALIZATION TOOL. ............................................................................................ 88 FIGURE 66. ENCRYPTED FILES UPLOAD PAGE. ........................................................................................ 89 FIGURE 67. ENCRYPTED FILES DOWNLOAD PAGE. .................................................................................. 89 FIGURE 68. INTERNAL ARCHITECTURE OF THE ANONYMIZATION COMPONENT. ........................................... 91 FIGURE 69. ANONYMIZATION PROCESS SEQUENCE DIAGRAM WHEN THE USER OF THE COMPONENT IS THE PA. 92 FIGURE 70. ANONYMIZATION PROCESS SEQUENCE DIAGRAM WHEN THE USER OF THE AN COMPONENT IS

ANOTHER COMPONENT OF THE CITADEL ECOSYSTEM. ................................................................... 93 FIGURE 71. EXTERNAL INTERFACES OF THE COMPONENT ANONYMIZATION................................................ 93 FIGURE 72. AN UI MOCK-UP. ............................................................................................................ 94 FIGURE 73. HARVESTING DATASETS THROUGH UPLOAD. ......................................................................... 99 FIGURE 74. COMBINING DATASETS. .................................................................................................... 99 FIGURE 75. DEFINING MAPPING SEMANTICS......................................................................................... 99

List of Tables

TABLE 1. PROCESSES VS. COMPONENTS. .............................................................................................. 13 TABLE 2. FUNCTIONALITIES VS. COMPONENTS. ..................................................................................... 14 TABLE 3. USE CASES INTERESTS WITH REGARDS TO CITADEL ECOSYSTEM COMPONENTS. ............................ 20 TABLE 4. DIGIMAT TECHNOLOGICAL STACK. ....................................................................................... 37 TABLE 5. CO-CREATION TOOL TECHNOLOGICAL STACK. ........................................................................... 45 TABLE 6. ENCRYPTION + ACCESS TECHNOLOGICAL STACK. ....................................................................... 89





Terms and abbreviations

AN Anonymization

API Application Program Interface

AuthN Authentication

AuthZ Authorization

CC Co-creation

CMS Content Management System

CP-ABE Ciphertext-Policy Attribute-Based Encryption

CSC Customer Service Centre

DM Digital Maturity Assessment

EC European Commission

ECC Elliptic Curve Cryptography

ECDH Elliptic Curve Diffie–Hellman

ECDSA Elliptic Curve Digital Signature Algorithm

FIPS USA Federal Information Processing Standard

FR Functional requirement

GDPR General Data Protection Regulation

HTTP Hypertext Transfer Protocol

ICT Information and Communication Technologies

ID Intelligent Discovery

JMS Java Message Service

JSON JavaScript Object Notation

JWT JSON Web Token

KPI Key Performance Indicator

KPI Key Performance Indicator

LDAP Lightweight Directory Access Protocol

NIST USA National Institute of Standards and Technology

NLP Natural Language Processing

RDF Resource Description Framework

REST Representational State Transfer

SMTP Simple Mail Transfer Protocol

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SPARQL SPARQL Protocol and RDF Query Language

UA User Assessment

UI User Interface

URI Uniform Resource Identifier

URL Uniform Resource Locator

WD Working Document

WP Work Package

WSDL Web Service Definition Language





Executive Summary

The objective of this report is to provide the final version of the CITADEL ecosystem taking as basis the use cases descriptions and the requirements for the tools and services developed as part of the CITADEL Ecosystem, as well as the initial and intermediate versions of the CITADEL ecosystem architecture described in WD 4.1, D4.3 and WD4.2. CITADEL Ecosystem, developed in the context of WP4-ICT Enablers to transform, comprises the CITADEL services implemented (KR2, KR4, KR5, KR6 and KR7) and their integration in the CITADEL ecosystem (KR8). This platform, along with other results from the other work packages, will be validated in the case studies defined in WP5.

This document includes the main functional components of the CITADEL Ecosystem generic architecture. Based on the description of the processes [1], the functional and non-functional requirements and the description of the use cases, the updated versions of the detailed design for each of the components of the CITADEL Ecosystem is presented in this deliverable. This detailed design covers aspects such as main functionalities, dynamic and structural design and interfaces for each component.

The main results of this document consist of the generic architecture of the CITADEL Ecosystem and the detailed design of each component of this architecture.

The conclusions obtained from this document served as a starting point for the final CITADEL Ecosystem prototype.





1 Introduction

This deliverable contains the architectural design for the CITADEL Ecosystem architecture. We focus on three main elements of the ecosystem:

• Actors that may be either individuals or organizations. Depending on their activities in the ecosystem, they can have different roles.

• Components that may either implement services built on the top of the platform or act as platforms/frameworks to support services.

• The ability of the platform to incorporate different elements and the interaction and interoperability of the elements as characteristics of the platform.

The first part of the document provides an overview of the best practices and guidelines to drive throughout the prototype implementation of the architecture described in the document. This includes the description of the design method, architecture standards, design patterns for service/component-oriented architectures as well as “privacy by design” oriented approaches. Based on the requirements definition, consolidated summaries of the use case needs as well as actors and their roles in the context of the CITADEL ecosystem are included. The second part of the deliverable provides the detailed architectural and technical profiles of each component and describes, by specific tool choices, how these components support the CITADEL defined processes. In this part, main functionalities, structural and behavioural views, interface and interaction models for each component are presented using architectural models. This part also details on the technical specifications such as supported programming languages, input/output aspects, dependencies, support for deployment platforms, web services, etc. The technical profiles of the components and related tool will serve as guidelines throughout the integration analysis process and allow advancing in setting up the prototype environment. Based on the architectural specifications of each component, the general ecosystem architecture is derived to guide the CITADEL ecosystem prototype implementation phase.

1.1 About this deliverable

Task 4.3, entitled “CITADEL ecosystem architecture” involves CITADEL partners IMEC, TECNALIA and FINCONS S.P.A. in definition and further fine-tuning the CITADEL platform design. This task also includes the requirements analysis based on the refined use cases described in the deliverable D5.1 [2], the components and tools choice described in the working deliverable WD4.1 [3] and D4.3 [4], the generic processes and functionalities described both in WD4.1 [3] and D4.2 [5].

This document details how the Consortium partners reflected on the design and fine-tunes the different descriptions of the proposed ecosystem architecture. This delineation and fine-tuning were based on the chosen components that support the defined key processes, as well as the four use cases, which in turn will provide data to feed activities and tasks in other related WPs.

1.2 Document structure

This document is structured as follows. After a concise description of our approach taken (best practices, design patterns, modelling language described in section 2.2), section 3 describes, for each subsystem of the CITADEL ecosystem, the detailed architectural aspects based on the design implications of the chosen components and tools described in WD4.1 [3] and D4.3 [4]. After iterative refinement of details and implications per each individual component as well as tool selected for its implementation and key process supported, a generic architectural design was derived (section 2). This document ends with a short summary and conclusion.





2 CITADEL Ecosystem generic architecture

2.1 CITADEL Ecosystem generic architecture

The main objective of the CITADEL ecosystem is to provide the tools and services required to fulfil the functional and non-functional requirements defined in WD 4.1 [3] and extended in D4.1 [6] and D4.3 [4]. These tools and services will support the CITADEL approach (“understand to transform” and “co-create to transform”).

The initial set of functional and non-functional requirements of the CITADEL ecosystem was defined in WD 4.1 and extended in D4.1. For that purpose, the first step was to identify the set of processes that a user could perform while using a tool or a service in the CITADEL ecosystem. Then, the main functionalities needed to support the identified processes were derived (along with their requirements). The CITADEL ecosystem and related processes and functionalities are described in WD4.1 [3], D4.2 [5] and D4.3 [4].

After some discussions and information gathering from the use cases the components for the CITADEL ecosystem were defined:

▪ Intelligent discovery of public services: This component will personalize the public services search based on the available information of the citizens.

▪ Digital Maturity Assessment (DIGIMAT): This component will assess the digital maturity of a PAs based on a Digital Maturity Assessment ideal model, defined in WP2. This component will provide to the PA the result of the assessment and a set of recommendations to improve its digital maturity.

▪ Co-creation methodology supporting tool: This component will support the personalization of the CITADEL co-creation methodology and the guidance through it, based on the specificities of the PA (local, regional, and national) and its needs.

▪ KPI report generation: The KPI report generation component will provide the following functionalities:

▪ Harvesting, curation and fusion of different data sources from which create the relevant KPI trends and reports with respect to the usage of the public digital services.

▪ Creation and visualization of the relevant KPI trends and generation of the corresponding reports.

▪ User assessment (Ranking +NLP): This component will provide the PA the functionality of getting users’ assessment for a certain digital service. This component will also support the analysis of the opinions on the users of the digital services through, for example, the processing of positive/negative comments in social media.

▪ CITADEL Innovation Platform. This platform is a tool that supports the management of some themes proposed by Public Administrations through a co-creation process, providing a virtual space where the social actors (such as PAs, citizens and NGO organizations) can collaborate proposing ideas, commenting and discussing other ideas, expressing their appreciation for ideas.. In the next phase the ideas are related to solution proposals processed by business players (such as SMEs and Academia) and discussed among all stakeholders system.





▪ Security Management: this component will provide the access management mechanisms for the ecosystem (and the components and tools) as well as anonymization, encryption and other security functionalities to preserve sensitive data in the ecosystem.

On the basis of the considerations listed above, the components included in the CITADEL ecosystem, from an architectural point of view, can be classified into two different categories:

• Components to be integrated in the PAs systems (orange in Figure 1): being the main user of these components the citizen instead of the PA servants, their UIs needs to be integrated into the PA on-line system that will use their back ends. These components are the Intelligent discovery of public services and the User assessment (composed of User assessment and user rating).

• Standalone components that will be used by the PAs and in the case of Co-creation methodology also by the citizens (blue in Figure 1). These components are: DIGIMAT, KPI report generation, Security Management, Co-creation methodology supporting tool and CIP

The CITADEL Ecosystem, besides the ICT enablers mentioned above, is composed to a set of components that implement/simulate an environment like the one that will be present in the administrations. These components are group as CITADEL Ecosystem framework and provide the following functionalities:

• Specification of the infrastructure required to compile (if required) and run the ICT enablers and the components of the ecosystem framework

• Integrated access domain and port

• Secured communication through SSL certificate

• Directory services for central authentication and authorization

• Monitoring capabilities of the running services

• Single sign on capabilities

Figure 1 shows all the components accessible through the CITADEL Ecosystem and the components that composes the CITADEL Ecosystem Framework.





Figure 1. CITADEL ecosystems generic architecture component diagram.

The following tables report the relationship between these CITADEL ecosystem components with the processes and the functionalities.

Table 1. Processes vs. components.

Pro

cess

es/C

om

po

nen

ts

Inte

llige

nt

dis

cove

ry

DIG

IMA

T

KP

I ge

ne

rati

on

Use

r

asse

ssm

en

t

Co

-cre

atio

n

me

tho

do

log

y su

pp

ort

ing

too

l & C

IP

Secu

rity

m

anag

em

en

t Process 1: Discovery of the public services

X X

Process 2: Collect information from Non-Users

X X

Process 3: Analyse the information (Big Data Analysis)

X X X X X

Process 4: Generate recommendations for transforming public services

X X X X

Process 5: Generate KPI Reports

X X





Pro

cess

es/C

om

po

nen

ts

Inte

llige

nt

dis

cove

ry

DIG

IMA

T

KP

I ge

ner

atio

n

Use

r

asse

ssm

en

t

Co

-cre

atio

n

me

tho

do

log

y su

pp

ort

ing

too

l & C

IP

Secu

rity

m

anag

eme

nt

Process 6: Provide Feedback from Users (Assessment)

X X

Process 7: Co-create Digital public services.

X X

Table 2. Functionalities vs. components.

Fun

ctio

nal

itie

s

/Co

mp

on

ents

Inte

llige

nt

dis

cove

ry

DIG

IMA

T

KP

I ge

ne

rati

on

Use

r as

sess

me

nt

Co

-cre

atio

n

me

tho

do

logy

su

pp

ort

ing

too

l &C

IP

Secu

rity

man

agem

en

t

Security Management

X

Recommendations report generation

X X X X

Digital maturity assessment

X

Digital Public service management

X X

Legislation management

X X X

Data Analysis X X X X X

KPI report generation

X

CITADEL management console

X X X X X X

Co-creation X

Data bases X X X X X X

UI X X X X X X





Fun

ctio

nal

itie

s

/Co

mp

on

ents

Inte

llige

nt

dis

cove

ry

DIG

IMA

T

KP

I ge

ner

atio

n

Use

r as

sess

me

nt

Co

-cre

atio

n

me

tho

do

logy

su

pp

ort

ing

too

l &C

IP

Secu

rity

man

agem

en

t

Business models X X X X X X

2.2 Design patterns and best practices

CITADEL design patterns and best practices must consider both the overall objectives of the project, as well as its operational procedures.

Indeed, the overall objective mandate for design patterns that maximise the reusability and integrability of CITADEL software components and minimize the effort to use and maintain them. At the same time, CITADEL has adopted the DevOps, or Continuous Integration (CI), approach as an operational procedure [5]. Therefore, the adoption of the Service Oriented Architecture (SOA) paradigm in designing and developing the CITADEL software components is the way, as detailed below, to, respectively, maximise and minimize the indicated elements.

Service Oriented Architecture (SOA) is an architectural approach based on orchestrating loosely coupled, coarse-grained, and autonomous components (services). Each service is characterised by having a well-defined interface (often formalised in a service specification, for example in WSDL), well defined endpoints through which its services can be accessed, and input and output messages. An end-point is theoretically a Universal Resource Identifier (URI) and often a URL. Messages, instead, can have different forms, spanning from HTTP methods (e.g., GET, POST), to SOAP messages, JMS ones, or even SMTP emails.

Designing SOA complaint systems is not an easy task, having to face not only issues related to the functionalities to be implemented, service’s API design, etc., but also issues like: service availability, accountability, scalability, etc. The use of patterns (best practices) and antipatterns (lessons learned) is recommended to help face these issues while designing SOA compliant systems. To this purpose, CITADEL will take into account SOA patterns as indicated in literature [7] [8].

In the CITADEL ecosystem, also stakeholders not directly related to the PA are important with a particular reference to the citizens.

For this reason, CITADEL has to be able to foster the provision of services on devices and software tools that are widely used by its stakeholders. This requirement implies that CITADEL has not only to comply with the SOA guidelines but has to provide its functionalities using HTTP protocol and web technologies. Therefore, CITADEL has to comply with RESTful SOA guidelines [9] [10] exposing its functionalities as REST resources identified via URIs/URLs and exchanging data using suitable media types (typically structuring the data using JSON syntax).

The DevOps approach suggests the adoption of a microservices based development approach. The microservices architecture is a SOA based approach where system’s features are provided by minimal independent services, each running in its own process and communicating via lightweight mechanisms. This development approach makes possible to better streamline the development and deployment activities, and improves, on the production side, the use of





resources and system scalability, in particular if combined with containerization technologies [11].

At last, but non-secondary, element to take in account is the security and privacy management. The CITADEL ecosystem has to not only manage information whose reliability and availability constitute critical aspects, but also the confidential or personal information by the CITADEL components design that must consider the security-by-design and privacy-by-design [12] guidelines. These guidelines are also strongly recommended by regulatory entities like the EU Article 29 Data Protection Working Party [13] and the US FTC [14], as well by the new EU GDPR (General Data Protection Regulation) [15].

Furthermore, in addition to these guiding principles it is relevant to adhere to the security-by-default and privacy-by-default [16] principles.

The by-design approach treats security and/or privacy features since the design phase of the system and does not consider these features as an add-on, or secondary, as compared to the other system’s features. The by-default approach implies to set default values, or default configurations, that assure the highest security or privacy level for the context at hand.

Moreover, trustworthiness is a core issue in value-added-services, Managed Data Services & Analytics and Digital Business Platforms (like the ones PAs are requested to deploy by the EU [17]). This implicates that the traditional approach to the trust and the security which makes a clear distinction between the internal ICT infrastructure (e.g., corporate intranet) and the external one (Internet), assuming that risks come from the outside, is obsolete.

The described approach is no longer appropriate, and it will be even less considered due to the progressive use of wireless communication systems, cloud services, mobile and personal devices [18]. In addition, the evolution of organization toward extended enterprise [19] organizational models, further makes obsolete, and complex from a management point of view, the traditional approach to ICT security. The blurring of company boundaries (Borderless Enterprise [20]) requires new models [21] [22] for the ICT security in which individual systems and services must be redesigned as if they were directly operating on Internet and the information must be ciphered end-to-end.

The above principles and guideline will therefore provide inputs for the design and development of the CITADEL architecture and services.

2.3 Intended users and their roles

This section presents consolidated use case needs (in the context of the CITADEL ICT enablers) as well as the users, their functions and roles per case based on D5.1 [2] and WD4.1 [3].

2.3.1 CITADEL actors

Based on the specifications of which actors can be engaged in the CITADEL platform activities (described in detail WD4.1) the following users and roles have been generalized:

• PA (Public Administration): This actor is the user belonging to the public administration, usually the civil servant.

• Citizen (or other stakeholder): This actor is the citizen, or other stakeholder (e.g. it may be any social actor different from the PA in Regione Puglia use case), who is using the services in the platform.

• Platform administrator: The actor who can install services, check the status of the included services, etc.

• Services developers: The actors representing the software developers or the services developers that want to include services in the CITADEL platform.





The actors related to the use cases are described in the D5.1 and in the next section, along with the use cases needs based on their descriptions.

2.3.2 Consolidated use case needs

This section outlines the use case specific needs in the context of CITADEL processes based on D5.1 [2].

Use Case 1: City of Antwerp Use case city of Antwerp - LECTOR (Life Events CiTizen platfORm) will extend Antwerp’s digital citizen platform by enforcing ‘loyalty’, enhancing ‘entry’ and by avoiding ‘exit’. As such it will focus on city of Antwerp’s e-desk and will make it more citizen-centric and accessible using an accurate, dynamic life-event approach with a focus on ‘birth’ as a life-event. The E-loket centralizes all the document requests, tools for appointments and administrative matters, i.e. the public administration's services in a 'strict' sense. Through the use case iterations, it becomes clear that in terms of functionalities from the CITADEL framework (described in WD 4.1), this use case strongly needs functionalities for Co-creation (CC) and KPI generation (KR) and might use components for Data analysis (DA), Recommendations report generation (RR), Digital Maturity components (DM) and Digital Public Service Management (PSM). These functionalities are related to the architectural design components as explained in Table3. Therefore, the City of Antwerp is initially interested in the following CITADEL ecosystem components: Co-creation methodology supporting tool and KPI report generation. They might also use Digital Maturity Assessment, Intelligent discovery of public services and User Assessment. Use case 2: Regione Puglia This use case, called G.E.T. IN TOU.C.H (Growing citizens Engagement by Technology application IN apulian TOUrism and Cultural Heritage), wants to focus on improving the tourism product co-creation process by making the available tools more user-friendly and ‘richer’ by providing:

• A single point of entry

• Feedback channels

• Integrating user-generated content

For this use case, the various iterations showed the CITADEL functionalities ‘Collecting info from non-users service’ and ‘Generating KPI service’ (KR) as the most useful. Therefore, they are interested in the following components of the current architectural design: User Assessment, Innovation Platform and KPI report generation.

On the basis of the remarks of the EU reviewers and the needs of the Public Administration of Regione Puglia, at the end of the first year of the project the focus of the use case has shifted towards a wider set of digital public services, also including various related aspects that have led use case to conform according to 3 pilot tests:

• The Citizen Involvement, with the co-creation of services and e-participation based on accessibility, security and quality of digital public services and the creation of an open data basket to be shared with local and national.

• The Civil Servant Awareness, submitting questionnaires to targeted groups of PA stakeholders to assess the willingness to involve citizens in the creation of services.

• The PA Capacity building to assess 4 dimensions of the Public Administration: legal, process, organization and people.





This has allowed the use case to adopt other tools and methodologies conceived within the CITADEL ecosystem as Innovation Platform for the Citizen Involvement, the survey on the willingness of the PA to collaborate with citizens as holistic approach and the DIGItal MATurity Assessment tool to measure the PA capacity building. A further issue deriving from the 3 pilot tests results above described will be considered in order to create a common base of knowledge to adopt the use case results in other contexts (Interoperability) through the CITADEL Analysis tool.

Use case 3: VARAM Use case VARAM (working title “Improved take-up of digital services at National Citizens portal of Latvia www.latvija.lv.”) – Initially, this use case approach aimed at improving the uptake of services and deliver them in a person-oriented way as well as at introducing a life-event based approach using co-creation tools. After some iterations and considering the advance of the different outcomes of the CITADEL action, VARAM has updated and extended the use case, so that the main goals of the VARAM use case are:

• Goal 1 – Improving public service delivery channels: The goal is to improve the public services by improving the public services delivery channels through two CITADEL components – Initial discovery of digital public services and User Assessment, VARAM may identify if such bundling of e-services around user characteristics (age, gender etc.) can provide more personalized service, and by receiving client’s feedback and analysing it in a simpler and faster manner can make the portal more appropriate to user needs.

• Goal 2 – Changing VARAM Public Service Department internal and policy planning processes and staff mindset regarding citizen involvement to provide services in citizen-centric manner: The main activity to reach this goal is to incorporate CITADEL components (both technological tools and non-technological, e.g. co-creation methodology) in VARAM Public Service department business processes (policy and strategic initiatives development, including digital government solutions). This will help achieving better public service delivery as well as improving internal processes.

• Goal 3 – Improving other institutions’ knowledge and toolsets of citizen centric government by disseminating CITADEL tools and methods to them .This goal entails providing PA civil servants involved in public service delivery with knowledge, tools and experience from CITADEL to increase their knowledge and change their mindset about citizen centric government, in particular, on how they can benefit and how co-creation can be realized in real life. At the end of the project, VARAM should be able to evaluate whether these efforts have resulted in better knowledge about open and citizen centric government, as well as readiness of PA servants to execute co-creation by themselves and shifted mindset of PA civil servants and public officials responsible for public service delivery in a way where involvement of stakeholders and bottom up approach is considered as something inalienable and executable. It should be noted that such evaluation can be done to some extent thanks to different measurable factors that can affect mindset and knowledge base where CITADEL input cannot be completely distinguished from other influences.

Use Case 4: DUCs of Brindisi Province

DUC stands for Distretto Urbano del Commercio (Urban Districts of Commerce). The DUC have been regulated by a specific Apulia Regional law (l.r. 5/2008) with the objective to enhance the commercial, touristic and cultural attractiveness of cities, or homogeneous urban areas, and favour the revival of consumption in urban centers and improve services to citizens.





A DUC involves economic operators, public administrations and other stakeholders acting in the DUC area. Each DUC, thus, must define and agree an executive plan identifying the specific actions, and timing, to achieve its objectives.

In the area of the Italian province Brindisi, 6 DUCs have been formalised.

They are using the CITADEL Innovation Platform to support the co-operation among the stakeholders to discuss and create their executive plans (this is being formalised by each Brindisi’s DUC management committee). The approach adopted for the executive plans definition envisages a set of steps managed via the CIP system. Most of these steps are based on questionnaires submitted, via the CIP, to the stakeholders.

Figure 2. The six DUCs established in the Brindisi area

Use Case 5: Municipality of Bari

This use case is based on the implementation of a prototype of a technical solution supporting the Smart Working initiative, currently under experimentation in the Bari Municipality following the Italian government directives to promote the Smart Work in the PAs. Bari Municipality has expressed its interest to experiment the innovative ICT solutions based on the use of DLT (Distributed Ledger Technology) and to apply them in the context of this initiative. Fincons has designed a solution based on DLT relying at the same time to the features provided by the Security Toolkit in order to ensure data protection implementing the following features:

• System design compliant to the privacy-by-design e privacy-by-default guidelines

• Data minimization (Serial Number, start/end time, location)

• Any (even potentially) user’s identification data managed via the DLT is always encrypted

More specifically:

• DLT transactions only contain the hash code of the encrypted data

• The encrypted data are stored outside the DLT

• Data subject to the erasure/rectification rights are encrypted twice:





o 1st encryption: data encrypted with AES and an ephemeral key (short lived key)

o 2nd encryption: AES ephemeral keys encrypted with CP-ABE techniques In the following table, a matrix with the relationships between the CITADEL ecosystem architecture components and the use cases interests is shown:

Table 3. Use cases interests with regards to CITADEL ecosystem components.

Inte

llige

nt

dis

cove

ry o

f p

ub

lic s

ervi

ces

Dig

ital

Mat

uri

ty

Ass

essm

en

t

Co

-cre

atio

n

me

tho

do

logy

sup

po

rtin

g to

ol

KP

I rep

ort

gen

erat

ion

Use

r A

sses

sme

nt

Secu

rity

M

anag

eme

nt

Use Case 1: City of Antwerp

X1 X X X X

Use case 2: Regione Puglia

X X X

Use case 3: VARAM

X X X X

Use case 4: DUCs of Brindisi Province

X

Use case 5: Municipality of Bari

X

1 In bold great interest, in normal case just interest.





3 CITADEL Ecosystem architecture detailed design

3.1 Intelligent discovery of public services

3.1.1 Main functionality

The Intelligent Discovery of Public Services (ID) component will manage the digital public service discovery in the PAs. The discovery of the digital public services will be done in an “intelligent” way so that the discovered services will be the most suitable ones for a concrete user based on the information available in each moment for the citizen.

However, as the citizen's information is sensitive, it will not be stored. Therefore, the discovery of the digital public services will be based on three criteria. Each criteria has been categorized with a colour level, based on the availability of the information and the need of the user’s consent:

1) Information provided by the browser through which the Intelligent Discovery service is accessed (green level). This information is always available, for example, the current time and the local language.

2) Information stored in the browser cookies (orange level). To obtain this information the citizen´s consent is required.

3) Profile form of the citizen (red level): the citizen can complete a form with personal information. This information will not be stored, and it will only be used to perform the search. Although the information it is not stored, the citizen´s consent is required.

When the citizen logs in, the services found using the green and orange level information will be displayed. The citizen will have the possibility to personalize the search further by completing the red level information.

In addition, to check that the services comply with the information provided in these levels, it is verified that they comply with the rules previously established by the administrator of the application. These rules are defined by the administrator of the application, who has the knowledge of the context of the services and the public administration.

The corresponding functional requirements for ID component are:

Requirement id ID.01

Req. short title ID component will discover the most suitable set of services for a certain user once the user is logged in the system.

Req. description The ID component will access the catalogue of available online services for user (based on the green and orange information levels), it will provide a sort list of recommended services. This will be “automatically” performed every time the user logs in.

State Done

Priority Must have

Relate KR KR5, KR8





Comments The list of services provided depends on the level of information (as explained above)


Req. short title ID component will discover the most suitable services for a set of requirements provided by a citizen.

Req. description The ID component will capture the requirements from the citizen and access the catalogue of available online services. It will provide a sorted list of recommended services which fulfil those requirements. This will be performed on demand (red level information).

State Done

Priority Must have

Relate KR KR5, KR8

Comments The requirements are collected based on information of the profiles. The data available in the profiles are : Gender, Language, Place of residence, Age, Marital status, Education level and Interests


Req. short title ID component will maintain a list of available services and their relevant information for performing the intelligent discovery.

Req. description The ID component will have a registry of the services along with their relevant information. These services related information must be up to date and aligned with the PAs digital public services registry.

State Done

Priority Must have

Relate KR KR5, KR8

Comments In addition to the services, PA is allowed to create rules. These rules are the ”link” between the characteristics of the profiles and the services.






Req. short title ID component will maintain a profile DB with the information that the citizen agrees to provide.

Req. description The ID component will maintain a profile DB with the information that the citizen agrees to provide, in order to facilitate the intelligent discovery.

State Rejected

Priority Must have

Relate KR KR5, KR8

Comments According to the use case owners , it was decided not to store the information of the citizens because they consider this as a constraint to use this component.

For this component there is a Use case requirement:

Requirement id ID.UC. 01

Req. short title The intelligent service discovery component should be linked with the catalogue of services of each PA.

Req. description This component should be linked with the catalogue of services available or the platform that collects all the service information. These catalogues or platforms could include both services that are available also digitally, and those who are available only in person. The discovery criteria should be very precise so that the outcome (list of suitable services) corresponds to the user profile and requirements.

Source VARAM and ANTWERP use case providers

State Done

Priority Must

Comments The tool allows PA to endorse the service available in the PA. When endorsing a service, PA should characterise the service. The characteristics of the service could be related with the characteristics of the profiles through the rules.

3.1.2 Structural overview

The ID component is composed of the following sub-components:





• Digital Public Services and rules Registry: The Digital Public Services Registry will store the available list of Digital Public Services for a certain PA. This registry should contain the required information so that ID can derive the most useful services for a certain user/purpose, these part is called as “rules”

• ID engine (Backend): The ID engine is the core sub-component of the ID component. ID engine will perform the actual discovery of the services from the Digital Public Services Registry, considering the rules and the information available for the citizen. In addition, the engine will provide a list of recommended services, based on their ratings and the number of times they have been searched.

• ID UI (Frontend): This sub-component is the graphical user interface of the ID. It has two different parts: the administration interface and the citizen interface. In the citizen interface (integrated in the PAs portal for the citizens), the intelligent discovery of the services will be launched automatically (based on the selected characteristics of the profile, if any, and on the green and orange information levels). In the administration interface, the operator of the PA will be able to manage the services in the registry (add new services, and edit or delete existing services), manage some test citizen profiles, and manage the rules that relate the digital services with certain characteristics of a citizen's profile. That is, these rules determine what services are found for a certain user profile.

In the following picture, these components and their interactions are represented:

Figure 3. Internal architecture of the intelligent discovery component.

3.1.3 Dynamic overview

Here, the process followed by a user (citizen) when using the Intelligent discovery of public services component is described:

1. The process is initiated by the user who logs him/herself into the system and access the tab personalized services.

2. The ID engine receives the request from the PA backend and retrieves information on the one hand from the user, and on the other hand from the available services. The obtained information will be based on the three levels of criteria described above, and on several rules. These rules can be defined by the operator of the PA, accessing to the administration area, and associating descriptive fields of the service with descriptive fields of the profile. In short, the creation of rules follows the next scheme:

IF profile is/has “Field 1 = A, Field 2 = B…” FIND services with “Field 1 = X, Field 2 = Y…”





3. The ID engine combines the information and provides the user with the list of most suitable and available services for him/her. This component also provides a set of recommended services.

4. The list of services is shown in the ID UI to the user.

The process is depicted in the following sequence diagram:

Figure 4. Intelligent discovery of public services sequence diagram (for a citizen user).

3.1.4 Interface and interaction models

The main user of the Intelligent discovery of public services component will be the citizen. This component will interact with the Security Manager for the authentication of the user and with the PAs system to combine the information available and the data about services and rules in the registry.

Figure 5. External interfaces of the component Intelligent discovery of digital services.

In the following picture, the ID UI (frontend) is presented:





Figure 6. ID UI, including the different levels (green, orange and red)

3.1.5 Design implications based on the tool choice

The Intelligent discovery of public services is a novel application implemented from scratch, so it will not be based in any existing tool.

For the implementation of the backend and the frontend, JHipster framework [23] has been seen as the best candidate for the moment. The communication (connectors) with the PA system will be done through REST APIs.

3.2 Digital Maturity Assessment


The Digital Maturity Assessment (DM) component will perform an assessment on the maturity of a Public Administration with respect to the provision of Digital Services. DM will first capture information mainly through online questionnaires; then, it will analyse this information; and finally, it will provide the result of the assessment in the form of a report including numerical and graphical data.

The main functionalities of this component are:





● The user will login to the DM tool with the same credentials that he uses in the PA system using the Single sign on capabilities provided by the components of the Ecosystem framework.

● A menu with the following options will be provided ○ Answer questions: introduced the questionnaire ○ Recommendations: generates the recommendations for the PA ○ Generate report: shows the report ○ Change user: shows the login window

● The DM tool will present to the PA representative a set of questions structured in the following thematic dimensions

○ Organization ○ Technology ○ People ○ Legal

● Each of these dimensions is divided into areas: ○ Organization: (a) Relationship with external agents and (b) Interaction with

citizens ○ Technology: (a) Data Processing and (b) ICT Technologies ○ People: (a) Interaction with citizens and (b) Training to the people involved ○ Legal: (a) Standards compliance and (b) GDPR compliance.

● Areas can, in turn, be divided into categories. Categories are only used for the area ‘GDPR compliance’ in the Legal dimension which consist of a large number of questions. These categories are:

○ (a) Contracts; (b) Governance and DPO; (c) Record and oversight of processing activities; (d) Communication about processing (data processed, purpose of processing, legal ground); (e) Consent in the PA; (f) Accommodating citizen’s rights as data subjects; (g) Data breach management; (h) DPIA and data protection by design and default; (i) International; and (j) Contracts.

● The questions can have dependencies. That is, the answer of a question can affect if a subsequent question is presented or not, simplifying the questionnaire and making it as brief as possible.

● The user can stop answering the questionnaire at any moment and resume it afterwards. The system will maintain the information previously introduced (provided it was saved by the user).

● The model defines a score model. Each question has assigned a relevance (High=3, Medium=2, Low=1) and each response has assigned a value. The score for each question is the product of these two values.

● The tool provided a total level for the PA as well as a score for each area, reflecting different views of its digital maturity.

● The results of the assessment are presented to the user using numerical and graphical representations for clarity.

● A set of recommendations will be provided to the user, on how to improve the current maturity in the different areas evaluated.

The corresponding functional requirements for DM component are:

Requirement id DM.01

Req. short title DM component shall compile information about the current situation of the PA with respect to digital maturity.





Req. description DM component will use online questionnaires to gather the required information for the situation of the different relevant areas of the PA for performing the assessment. DM will use structured questionnaires to get key information to evaluate the status of the PA. The questions posed to the PA will be organized in thematic areas covering important aspects of the digital maturity.

State Done

Priority Must have

Relate KR KR1, KR8


Req. short title DM component will analyze different characteristics of the PA in order to assess its digital maturity.

Req. description DM component will analyze the PA against the maturity digital model to identify its digital maturity.

State Done

Priority Must have

Relate KR KR1, KR8


Req. short title DM component will provide the result of the assessment in the different relevant perspectives.

Req. description DM component will provide the result of the assessment, showing the punctuation reached for each of the perspectives in a numeric and a graphical way.

State Done

Priority Must have

Relate KR KR1, KR8






Req. short title DM component will provide a report with the result of the assessment.

Req. description DM component will provide the result of the assessment, showing the punctuation reached for each of the perspectives in a numeric and a graphical way in a report that can be downloaded.

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title DM component will customize the digital maturity assessment based on the profile of the user and the PA profile.

Req. description DM component will provide customized questionnaires based on:

1. The PA profile (national, regional, local) 2. The user profile: based on the role of the user who access the

Digimat the questionnaire will be customized.

State Rejected

Priority Must have

Relate KR KR1, KR8

Comments The added value of having this questionnaire customised based on information of the PA is not relevant for the use case owners.


Req. short title DM component will provide recommendations on how to improve the current maturity in the different areas evaluated

Req. description DM component will provide a set of recommendations, taking into consideration the responses provided by the PA and the maturity level that the PA is characterized for that area and dimension.

State Done





Priority Must have

Relate KR KR1, KR8

For this component the User requirements are the following:

Requirement id DM.UC. 01

Req. short title Questions of the DMA must be clear and concise.

Req. description The assessment for digital maturity should not include vague and open to interpretation questions , or questions very hard to answer properly. It should be taken into account that PAs are often organised in a complex structure and not all digital services are managed in the same way.

Source ANTWERP, Regione Puglia and VARAM use case providers

State Done

Priority Must

Comments Several interactions of testing of the questions have been done with the use cases providers to identify the unclear questions.

Requirement id DM.UC.02

Req. short title Results must include comprehensive explanation of the evaluation.

Req. description End-users from different PAs with different levels of Digital Maturity might use this service, so comprehensive explanation of the result of its evaluations should be provided with emphasis on problematic areas as well as, the explanation of the methodology and the questions used in evaluation should be available to user.

Source VARAM

State Done

Priority Must

Comments A report with the recommendations and the answers provided to all the questions is presented to the PA.

This tool has not the objective to benchmark different PAs.






Req. short title Recommendations for legislation awareness could include comprehensive view on EU legislation.

Req. description Recommendation in the Legal dimension should contain clear steps to understand the EU Legislation and the matches with the national ones

Source VARAM

State Done

Priority Could

Comments Timelex has elaborated the legal dimension. It is desirable that the recommendations will be related with the CITADEL Vademecum


Req. short title The recommendations regarding legal aspects could consider the Italian and Latvian laws

Req. description Recommendations in the Legal dimension could consider laws from the countries of the use cases

Source VARAM and Regione Puglia use cases providers

State Rejected

Priority Could

Comments Only European laws are considered. This aspect is identified as future work.


The DM is a Web application that provides questionnaires. The DM component is composed of the following sub-components:

• DM Logic: This sub-component is where the logic of the DM Assessment is implemented. This component:

o Sets the questionnaire, organizing the questions by thematic areas and categories, which have been previously defined in the tool.

o Analyses the responses provided by the PAs, and calculates the obtained scores based on the established logic rules.





• DM Rules engine: This sub-component, implements the logic of the recommendation database and selects and issues a set of specific recommendations based on the analysis of the answers.

• DM UI: This sub-component is the graphical user interface of the DM, where the interaction with the users of the component happens. On the one hand, the UI will provide the input interface to the PAs, where they can read the questionnaire and introduce the corresponding responses. On the other hand, it will provide the output interface for the PAs, where they can check the results of the DM assessment.

• DM Database: This is the data access component of the DM tool. It provides an interface for accessing the MySQL database.

• DM Report generator: This component contains the structures of the input (questionnaires) and output (reports) models used from the component. It is also envisaged that the sub-component is served by an external report designer/generator.

These sub-components and their interactions are represented in the following picture:

Figure 7. Internal architecture of the Digital Maturity Assessment component.

3.2.2.1 Data base model

The following picture represents the final data base model of DIGIMAT, that includes the tables related to the recommendation functionality.





Figure 8. DIGIMAT data base model

This is a description of each table:

• Dimension: This table contains the 4 dimensions defined (Technology, Organization, People, Legal) plus an extra value for Context questions.

• Area: This table contains the data of the 8 areas in which dimensions split. Each dimension is composed by two areas (see section 3.2.1)

• Category: This table contains the data of the categories, a further sub-division of areas (used in the Legal dimension to structure its large number of questions).

• User: This table contains the data of the users signed up will in DIGIMAT.

• Question: This table contains the data of all the questions of every category.

• Qtype: This table contains the 3 different question types defined for DIGIMAT (text, combo, multiple).

• Optionval: This table contains the different options of each question of type combo or multiple selection.

• Answer: In this table are stored all the answers to the questionnaire for each user.

• Recommendation: This table contains all the recommendations that can be potentially issued to the PAs

• Rule: contains the rules that relate the answers given by a user with the recommendations issued to him/her.

• RuleType: This table contains the the rules types defined.


The Digital Maturity Assessment process is described in the following steps:

1. When requested by the PA, the DM Logic component constructs the online questionnaire to be shown. It is supposed that the user is already logged in the system through the authentication component.





1.1. It queries the DM Database component to extract the actual questions, and its organization by areas and sub-areas.

1.2. It sends the information to the DM UI, which presents the questionnaire to the PA. 2. After logged PA user has entered its responses and saved the questionnaire, the UI sends

the information -that characterizes the situation of the relevant areas of the PA- by the DM Logic component, that stores them in the database.

3. The DM Logic compares the PA information with the maturity digital model to identify its maturity level. 3.1. It uses the Rules Engine component to calculate the scores of the different areas and

the global score. 4. The DM Logic sends the information to the DM UI, which is in charge of the presentation of

the results to the user. 4.1. The DM UI component makes use of the Report Generator to generate a complete view

of the results, according to the predefined templates. 5. The DM UI shows the results to the user, in the computer screen by default and in a printed

report format if desired.


Figure 9. Digital Maturity Assessment sequence diagram.


The principal user of the DM Assessment component will be the PA user. The PA user is who triggers the request to assess the PA’s digital maturity level. For the authentication of such user, the component will interact with the Security Manager.





Figure 10. External interfaces of the component Digital Maturity Assessment

The UI of the current version of the DM has been already developed, based in the workflow explained in the previous sections. Being the DM a web-based tool, only a browser is needed to use it. We present here examples of the main windows.

After the login, the user is presented a window with the main options of the tool.

Figure 11. UI for the DM: main menu

When the user accesses to the questions, the four dimensions in which the questionnaire is organized are presented as menu-tabs. For clarity purposes, each tab has a different color. These colors are maintained as main references while the user navigates inside a specific dimension, through the different areas, questions, etc. In the next picture, the initial view of a dimension.





Figure 12. UI for the DM: view of the “Organization” dimension

Inside each area, a list of multiple-choice questions are presented. The user can also save the answers or cancel to go back to the previous window.

Figure 13. UI for the DM: questions in the “Interaction with the citizen” area

The recommendations page will show a list of recommendations based on the answer given by the user and on the level of maturity finally obtained. The recommendations will be grouped by areas.





Figure 14. UI for the DM: questions in the “Interaction with the citizen” area


The Digital Maturity Assessment will be a novel application implemented from scratch but some of the sub-components will be based on existing tools.

The user interface is developed in HTML5. So, the user needs a Web browser to access this client properly. The communication (connectors) with other components will be done through REST APIs.

The information relative to questions, responses and recommendations are maintained in a MySQL database, along with metadata like the scores, relations and the internal logic of the recommendation system.

For the generation of reports, the BIRT [24] platform is used. BIRT is an open source technology platform which allows creating data visualizations and reports that can be embedded into rich client or web applications.

The rest of the technological stack used by the DM Assessment is listed in the following table:

Table 4. DIGIMAT technological stack.

Item Value

Programming Language Java, Javascript, JSP, HTML

IDE/ Development Tools Eclipse





Item Value

Additional Libraries jQuerymobile

Additional APIs Google chart API

Application Server Apache Tomcat

Databases MySQL

3.3 Co-creation methodology supporting tool


This tool features the main elements of the co-creation methodology framework consolidated by the project, intended as set of workflows, practices and tools.

The tool provides a way, for the PA staff in charge of establishing a co-creation process that follows the CITADEL methodology, to be driven across all the different phases and steps envisaged as part of the methodology, keeping track of all the findings along the process.

The corresponding functional requirement for this component is:

Requirement id CC.01

Req. short title CC component will customize the generic CITADEL co-creation methodology into a specific one for a concrete PA and a concrete co-creation process.

Req. description CC component will gather relevant information about the PA and/or the co-creation context in order to be able to customize the generic CITADEL co-creation methodology proposing only the tasks/activities relevant for the concrete co-creation process.

State Proposed

Priority Must have

Relate KR KR3, KR4, KR8

The co-creation support engine has been implemented as a software implements the business process derived from the schematization in BPMN notation of the methodology defined.

This business process envisions tasks designed to be executed by different actors within a PA organisation, with different level of responsibilities, and envisages also the involvement in the business flow of actors external to the PA (citizens or some specific categories of citizens) that are expected to execute actions or provide inputs to let the process move on, without acting on the tool itself. Indeed, several steps in the business process derived from the methodology envision the execution of some activities that do not involve the use of the co-creation tool,





whose main purpose is to track inputs and outputs of those activities, such as meetings, focus groups, interviews and processes managed through external tools. In most cases the different step of the co-creation business process provides hints and references to the tools considered appropriated for the execution of these activities.

Among these tools linked to the co-creation process, for instance, we have the CITADEL Innovation Platform (described in 2.3.2), which is also part of the CITADEL ecosystem, which provides a virtual space where people can collaborate creating ideas, commenting and discussing other people ideas, expressing their appreciation for ideas, and allows the platform administrator to create challenges, thing that gives the possibility to guide people ideas towards the achievement of a specific objective.


The figure below reports the high-level architecture of the co-creation methodology supporting tool, which is built on the top of the Camunda BPMN Engine, used as a standalone process engine server.

Figure 15. Co-creation support tool architecture 2

The following components are involved:

Public API: Service-oriented API allowing Java applications to interact with the process engine. The different responsibilities of the process engine (i.e., Process Repository, Runtime Process Interaction, Task Management, …) are separated into individual services. The public API features a command-style access pattern: Threads entering the process engine are routed through a Command Interceptor which is used for setting up Thread Context such as Transactions.

BPMN 2.0 Core Engine: This is the core of the process engine. It features a lightweight execution engine for graph structures (PVM - Process Virtual Machine), a BPMN 2.0 parser which transforms BPMN 2.0 XML files into Java Objects and a set of modules providing the implementation for BPMN 2.0 constructs such as Gateways or Service Tasks.

2 Source: https://docs.camunda.org/manual/7.9/introduction/architecture/


https://docs.camunda.org/manual/7.9/introduction/architecture/




Job Executor: The Job Executor is responsible for processing asynchronous background jobs such as Timers or asynchronous continuations in a process.

The Persistence Layer: The process engine features a persistence layer responsible for persisting process instance state to a relational database (H2 is the database used, http://www.h2database.com/html/main.html), while MyBatis (http://www.mybatis.org) mapping engine is used for object relational mapping.


The dynamic behaviour of the tool can be summarized by the business process implemented, illustrated in Figure 16, where the different lanes, following the BPMN notation, represent the scope of action of each of the roles defined for the process:

The PA Manager: the users with the highest level of responsibility in the process, in particular for the instantiation of a new process, i.e. the initiation of the workflow involving the sequence of steps that will drive the activity of the whole team towards the establishment of the object identified as target of the co-creation process, and taking care of the execution of critical tasks, in general those associated to the most important decisions about how to proceed.

The PA Analyst: users that take care of the execution of most of the tasks associated to the process (steps).

The citizens: this category include any stakeholder external to the PA organization, who is involved in the execution of the co-creation process but is not required to perform any action or provide any input through the tool interfaces. External stakeholders, in fact, become part of the process each time one of the methodology step envision interaction with them, this interaction may be carried out on-line, by means of other tools, or physically, when they are, for instance, invited to participate to a focus-group or a workshop. In the general case, thus, they are involved in the information flow built around the co-creation tool just because they receive information, such as invitation to convene to meetings or to subscribe to a certain platform, or notification about specific situations related to their participation to the process.

The figures below report the BPM diagrams that illustrate the high-level process as a composition of the 4 phases envisaged (Ideation and research, Concept and design, Development and implementation, Production and Maintenance), as well as the different tasks involved in each phase.

Figure 16. Top level Business Process as union of the 4 phases identified in the CITADEL co-creation process implementation


http://www.h2database.com/html/main.html

http://www.mybatis.org/




Phase 1 – Ideation and Research

Figure 17. Ideation and research business process diagram

The first phase initiates the Co-creation process, starting with needs detection. Then these needs are discussed within a consultation, prioritized and used for the challenge definition. At the end of Phase 1, the ideas for the specific challenge are defined. Once the ideas are ready, they can be published in order to start the Phase 2.

Phase 2 – Concept and Design





The objective of this phase is to focus and further work on the needs identified in phase 1. To define the trajectory, to conceptualize potential solutions and decide what will be experimented and prototyped in phase 3.

Figure 18. Concept and design business process diagram

Phase 3 – Development and implementation





This phase is the actual development. The objective is, first, to prototype the concept or solution come up with in previous phases, test and iterate it; second, to validate the prototyped solution and, third, to implement its final version. The execution of trials and the collection of related issues helps to improve and refine ideas before they are being developed and implemented.

Figure 19. Development and implementation business process diagram




ww.citadel-h2020.eu of 107

Phase 4 – Production and Maintenance

The final phase focuses on the finalization of the project (i.e. the service or product), launching it and evaluating it. At the end of the process, the evaluation of all the information and the decision whether the process should start all over again, is taken. It is important to keep in mind that co-creation is an iterative process that ideally never truly ends.

Figure 20. Production and maintenance business process diagram

For details about the activities envisaged by the different steps of the process it is recommended to check the deliverable D3.7, Initial CITADEL Methodology for co-creating a public service.


At this stage of development, the interfaces between the tool and the CITADEL ecosystem are still to be defined.

In terms of user’s interaction, the most used interface is implemented by the UI of the Camunda Tasklist web application (accessible in the prototypal version of the tool at the URL https://ibd-aws.finconsgroup.com:8443/camunda/app/tasklist) through which authenticated users are enabled to claim the tasks assigned to them or to their roles, so that they can have access to the forms for the provision of the information required to make the process progress, as well as to save and unclaim the task when their work on it is completed and another user is expected to act on the same task or to complete it.

https://ibd-aws.finconsgroup.com:8443/camunda/app/tasklist/default/

https://ibd-aws.finconsgroup.com:8443/camunda/app/tasklist/default/




Form more detailed information about the Camunda Tasklist web application, it is recommended to check the official documentation available at https://docs.camunda.org/manual/7.5/webapps/tasklist/ .

Two others Camunda web applications, then, provide UIs designed for application administrators and process administrators:

• the Admin, (accessible in the prototypal version of the tool at the URL https://ibd-aws.finconsgroup.com:8443/camunda/app/admin ) an application that allows to configure users and groups via the engine’s Identity Service and authorizations via the engine’s Authorization Service (see https://docs.camunda.org/manual/7.5/webapps/admin/ for more detailed information)

• the Cockpit, (accessible in the prototypal version of the tool at the URL https://ibd-aws.finconsgroup.com:8443/camunda/app/cockpit ) useful for monitoring and operations, provides access to deployed BPMN processes and allows searching though running and ended instances and performing operations on these see https://docs.camunda.org/manual/7.5/webapps/cockpit/ for more detailed information)


The following table lists the components part of the technological stack over which the Innovation Platform is built.

Table 5. Co-creation tool technological stack.

Item Value

Programming Language Java

IDE/ Development Tools Eclipse

Additional Libraries Camunda Process engine

Application Server Tomcat

Databases H2

Operating System Windows Server 2012

3.4 KPI report generation

This section describes the KPI report generation component.

The KPI report generation is divided into the two main components analysed in the next sections:

• Harvesting and curation of data: This component is in charge of acquiring and conditioning the data from external sources (PAs registry, public data from open data portals, etc.) that will be processed by the KPI visualization and report generation component. The data is assumed to be pre-processed by the Security Management / Encryption component.

https://docs.camunda.org/manual/7.5/webapps/tasklist/

https://ibd-aws.finconsgroup.com:8443/camunda/app/admin

https://ibd-aws.finconsgroup.com:8443/camunda/app/admin

https://docs.camunda.org/manual/7.5/webapps/admin/

https://ibd-aws.finconsgroup.com:8443/camunda/app/cockpit

https://ibd-aws.finconsgroup.com:8443/camunda/app/cockpit

https://docs.camunda.org/manual/7.5/webapps/cockpit/




• KPI visualization and report generation: This component creates the relevant KPIs from data prepared by the Harvesting and curation of data and visualizes them for the users (PAs).

Figure 21. KPI generation component diagram.

3.4.1 KPI visualization and report generation

3.4.1.1 Main functionality

The KP (KPI visualization and Report generation) component generates a report with the selected KPIs for the PAs. These are the possible KPIs envisioned by now (this list will be modified based on the input received from WP2 and based on real-world sample data):

• KPIs to co-create: Number and trends

• General KPIs for improving the usage of the current digital services: o Number of users/non-users per service/per year o Data/information of citizens who don’t use the digital services (or one concrete

digital service): i.e. gender, age, demographics, education skills, etc. o Feedback (rating) per service/ per type of service/ per time period

• KPIs of a certain service o Number of users/non-users per service/per year o Data/information of citizens who don’t use the digital services (or one concrete

digital service): i.e. gender, age, demographics, education skills, etc. o Feedback (rating) per service/ per type of service/ per time period


Requirement id KP.01

Req. short title KR component will provide a UI for gathering the purpose of the KPI report requested

Req. description The KP component will collect the objective of a certain KPI generation proposition from the user. Initially the following potential KPIs generation objectives are envisioned:

• KPIs to co-create: Number and trends




• General KPIs for improving the usage of the current digital services

• KPIs of a certain service

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title KR component will analyse relevant information for generating specific KPIs.

Req. description The KR component will analyse the information from the treated data (harvesting, curation and fusion)

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title KR component will produce a report with the KPIs selected by the end user.

Req. description KR component will produce as a result a (graphical) report with the requested KPIs.

State Proposed

Priority Must have

Relate KR KR1, KR8


Req. short title KR component will provide means to visualize the generated KPIs and their trends




Req. description KR component will visualize the generated KPIs through a graphical user interface.

State Proposed

Priority Must have

Relate KR KR1, KR8

3.4.1.2 Structural overview

The KR component is composed of the following sub-components:

• KP UI: The KP UI will provide to the PAs the access to generate and visualize (console or report) the results.

• KP KPI generation: This sub-component is the core sub-component which generates the request to the data preparation component based on the users’ indications, analyses the received data and generates the KPIs for that enquiry. If anonymization of the data is needed, it should be before processed by the Security Management component (anonymization sub-component).

• KP report generation: This sub-component will generate the report from the data provided by the KPI generation sub-component.


Figure 22. Internal architecture of the KPI visualization and report generation component.




3.4.1.3 Dynamic overview

Here, the process followed by a user when using the current KPI visualization and report generation component is described.

Three scenarios are described to get a concrete feeling of the possibilities of the UI as it is today.

1. The user navigates to the UI (Titled “KPI Editor” for now) at https://citadel.ilabt.imec.be/.

2. The user gives the URL to a SPARQL [25] Endpoint. This is a query interface provided typically by a Linked Data Source (or RDF store, or Triple store). This is where the curated and fused data lives (more on that later in section 3.4.2). At this moment there is an instance running with generated data on http://blazegraph:8080/bigdata/namespace/citadel/sparql (this is a local service on the demo server, so it is not publicly accessible in this case).

3. The user selects a graph type. This can be a Distribution chart or a Compare chart. 4. Suppose the user selects a Distribution chart. A Distribution chart plots possible values

for a given property possibly over time or in total. Here is an example for the generated data. We want to plot how birth certificates are requested over time. This can be in the office, via internet, using a mobile phone or by writing a letter. So the object “birth certificate” has a property “method”, which can have values “Office”, “Internet”, “Mobile” or “Letter”.

o The user selects “Distribution chart” and “Over time” (See Figure 24). o Then a new screen appears with the next steps (see Figure 25). At this moment

the UI loads possible objects from the Linked Data Source which have date/time fields.

o The user selects a time interval, say 6 months. o The user selects an object, in this case a “birthcertificate”. o The user selects the property to plot, in this case the “method”. The UI also

displays the type of the property, in this case a plain text “string”. This can be helpful for filtering (see for instance Figure 28), but is not relevant for the described flow.

o The user selects the property representing a date variable. The UI determines the possible values automatically from the type of the data. In this case the “issuedate” is selected.

o If all is set, the “Generate” button can be clicked. The UI sends a request to calculate the KPI to the KPI generation component. The KPI generation component composes a SPARQL query and sends it to the Linked Data Source.

o A new screen shows the plotted Distribution chart (see Figure 26). 5. Here is another more advanced example of a Distribution graph. Suppose the user wants

to know the reasons (i.e. feedback) for a drop-out for all birth certificates and marriage certificates requested using the internet.

o The user selects “Distribution chart” and “In total”. o A new screen appears with the next step (See Figure 27). The user selects

“birthcertificate” and “marriagecertificate”. o The user selects the chart style “Stacked chart”. o A next screen appears, where the variable (property) to plot for the birth

certificate object can be chosen together with some filtering (See Figure 28). Again, all possibilities here are loaded by the UI from the Linked Data Source and dynamically deducted due to the fact that it is linked data. In this case, the user selects “feedback” and adds two filters: one to only plot values for

https://citadel.ilabt.imec.be/




certificates issued using the internet, and one to exclude empty feedback (in the data represented as “-“).

o The same steps need to be done for the marriage certificate. The user clicks “Next”.

o Now the graph is generated and displayed (See Figure 29) . 6. Now suppose the user selects a Compare chart. A Compare chart compares objects

based on selected properties. Suppose the user wants to compare the adoption rate of using the internet compared to other methods of using a service.

o The user selects a “Compare chart” and “Over time” (See Figure 30). o On the next screen, the user selects the 4 services (See Figure 31). Note that

these possible objects are loaded dynamically from the Linked Data Source. The user selects a time interval of 1 year.

o Now for each service the user adds a filter to only count certificates requested over the Internet and divide the number of results by all objects (See Figure 32).

o Once the last service is set, a chart is generated and displayed to the computer screen (See Figure 33).

7. A last possible step is to save the chart. Loading it again later is not possible in the current implementation.





Figure 23. KPI visualization and Report generation sequence diagram.

There are a lot of possibilities using this UI to generate KPI’s. By means of demonstration a page with some pre-defined KPI’s is accessible at https://citadel.ilabt.imec.be/pages/. Real report generation is not implemented at this moment, but an idea is to have a dashboard where the saved charts show up. A pre-configured dashboard is available at https://citadel.ilabt.imec.be/pages/dashboard.html .

https://citadel.ilabt.imec.be/pages/

https://citadel.ilabt.imec.be/pages/dashboard.html




Figure 24. First screen of the KPI Editor. In this case a Distribution chart over time is selected.

Figure 25. Second screen of the KPI Editor in case a Distribution chart over time was selected. Here the time interval, object, property and date variable are selected.




Figure 26. Third screen of the KPI Editor, displaying how birth certificates are issued over time.

Figure 27. Second screen of the KPI Editor in case of a Distribution in total. Here birth and marriage certificates are selected.




Figure 28. Third screen of the KPI Editor in case of a total distribution: here the user wants feedback for birth certificates issued over the internet that do have some feedback.

Figure 29. The distribution of feedback for birth and marriage certificates issued over the internet.




Figure 30. First screen of the KPI Editor where a user selects a Compare chart with progression over time

Figure 31. Second screen of the KPI Editor in case of a Compare chart with progression over time. Here the 4 services are selected with data aggregated per year.




Figure 32. Third and following screen of the KPI Editor in case of a Compare chart with progression over time. Here birth certificated requested over the internet will be plotted.

Figure 33. The adaption rate of using the internet (compared to the other methods) for the four services in the generated data.




Figure 34. A preliminary dashboard demonstrating some KPI’s on generated data.

3.4.1.4 Interface and interaction models

The main user of the KPI visualization and report generation will be the PA. This component interacts with the Harvesting and curation component for getting the required adapted data from external or internal data sources

Figure 35. External interfaces of the component KPI visualization and report generation.

3.4.1.5 Design implications based on the tool choice

The KPI visualization and report generation is a novel application implemented from scratch using existing libraries for visualisation (e.g. Google Charts3 ) and for Javascript interaction (e.g. JQuery4). The back-end is implemented as a Java Spring Boot5 application, which allows easy integration (various databases, reverse proxy, new front-end, …)

3 https://developers.google.com/chart/ 4 https://jquery.com/ 5 https://spring.io/projects/spring-boot

https://developers.google.com/chart/

https://jquery.com/

https://spring.io/projects/spring-boot




.

3.4.2 Harvesting +curation+ Fusion of the source data that will be visualized


The Harvesting and curation component (HC) will collect, store, fuse and provide data required for the KPI visualization and Report generation (KP) component.

The main functionalities of this component are:

● Harvesting/loading structured file based resources in different formats (like CSV, XLS, JSON, XML, SQL, RDF…) but also databases through SQL or indexes like Elasticsearch and publishing data in different formats (like CSV, JSON, XML, RDF…).

● Filtering resources based on their metadata, for example based on keyword or resource type.

● Linking and fusing data sources by converting them to linked data in the Resource Description Framework [26] (RDF).


Requirement id HC.01

Req. short title HC will access and store the different data sources required for performing the information analysis.

Req. description HC will have access to the different data sources (i.e. open data portals, data coming from the on-line questionnaires, anonymized data, etc.) and store them for further analysis.

State Proposed

Priority Must have


Requirement id HC.02

Req. short title HC will provide the relevant results to the KP Component.

Req. description DA will analyse the different data sources and provide relevant data to the KP component that has requested the data.

State Proposed

Priority Must have





The dependencies of the underlying tools are included in the subsection 3.4.2.5.


The architecture of the data component consists of three subcomponents: The DataTank [27], RML Mapper [28] and an RDF Store [26]. There are two main parts, which are able to work independently.

Part one focuses on loading, harvesting, managing, curating and (re)publishing structured data sources (mainly files) in different formats. Part two focuses on fusing the loaded/harvested sources together (at this stage needs extra adjustment).

Figure 36. Harvesting/curation/fusion component architecture.

Introducing semantics to structured data is important because it allows explicitly indicating the context of the different data sources being combined. In RDF, Uniform Resource Identifiers (URIs) are used to this purpose. Working with URIs allows to create reusable mappings from source data in any format and convert them to linked data that is identified by the context specific URIs. The same URIs can be used to build queries (using SPARQL [25]).

Figure 36 gives an overview of the components of the proposed architecture. Note that the RDF Store is only accessible by the KPI generator, but it can be made public in the future as well.

The figure below gives an overview of the components of the proposed architecture.

Data loading/harvesting and management

The main component here is The DataTank6. The DataTank allows to harvest, load and manage

(or curate) different structured data sources. Via a HTTP interface the harvested/loaded

resources are being published.

Fusion of the data sources

The main component here is the RML Mapper [28]. The RML Mapper maps data to RDF, from

one or more sources at a time. The mappings are defined in mapping documents. At this

6 The Datatank is a tool to (re)publish structured data in different formats through a HTTP interface.




moment, they need to be written manually, but a graphical tool (RML Editor7) can help to

compose these mappings, depicted as “Mapping Document Generator” in Figure 36. For the

generated data in the demo, we used some custom code to do this. Mapping makes it is possible

to fuse data at this stage in the process, which can be interesting in case of concepts spread over

different data sources (such as different tables in one database). For instance, given a data

source containing the name and birth data of persons, and another data source containing the

current address of people, it is required to process each person as one entity with a name, birth

date and address. If the address changes though, then the data has to be re-mapped, resulting

interesting for rather static data.

After the mapping completes, the resulting RDF data is stored in the RDF Store (i.e., the

combination of data)

Fusion for more dynamic data will be done later in the process by sending SPARQL queries to

the RDF Store. This happens for the KPI generator and UI if a user edits and / or visualises a KPI.


The process followed by these components supports two main steps (Detailed explanation in

Annex 1):

1. Adding a data source and publishing it through HTTP.

2. Mapping one or more data sources to linked data after they are published and loading

them into the RDF store. This immediately combines them (not fuses them!) if stored

in the same name space (at this moment, we only support one namespace). As

explained before, fusing is done by the KR component by composing the right SPARQL

queries.

• Creating new resources. There are different techniques to create new resources:

o Creating a new dataset from a single resource. This can be any format supported

by The DataTank. The user triggers the retrieval of the data source through the

Web UI. The DataTank will create a reference to the data source and expose the

data source via a HTTP interface.

o Creating a new dataset from a combined resource using SPARQL query (query

entered by user). The user triggers the execution of a SPARQL query after its

configuration. Like the single data source case, The DataTank will create a

reference to the data source and expose the data source via a HTTP interface.

• Retrieving resources. There is a distinction between retrieving a single data source and

a combined data source.

o Single: A request to retrieve a single data source is parsed through The

DataTank’s HTTP interface and results in processing the requested data source

in the requested format and returning it to the application where the request

originated from. This can be done by any actor interested in the data. The KR

component however only uses the “combined data source” approach.

7 http://rml.io/RMLeditor

http://rml.io/RMLeditor




Figure 37. Reading data from a single resource.

Figure 38. Reading data from a combined resource.

o Combined: When retrieving a combined data source, the KR component sends

a SPARQL Query to the RDF Store. The RDF Store contains the linked data of all

data sources that have been mapped. At this moment, the RDF Store is only

accessible to the KR component but can be opened to third parties in the future

if needed.


The Harvesting and curation component will be an internal component. It will interact with KPI visualization and report generation components to receive the request of the data and with external data sources to get the data.




Figure 39. External interfaces of the component Harvesting and curation.

In the following pictures, the UI of this component is presented.

1. In order to access the DataTank Web UI, the user needs to go to <the_datatank_installation_url>/api/admin (http://citadel.ilabt.imec.be:8443/api/admin in our demo setup) and login with the data administrator or any other user credentials with permissions to create and edit resources.

Figure 40. User authentication.

After logging in, it is shown an overview of all datasets and a button to add new datasets.

http://citadel.ilabt.imec.be:8443/api/admin




Figure 41. Overview of the chosen datasets.

2. Create/edit a new data source. The following figure shows how to add/edit a new data source, in the example case the source type is CSV.

Figure 42. Adding/editing a data source.

When a new resource is added, it becomes available in the overview of resources. For each added resource, the supported output type is displayed.




Figure 43. Added resource available conversion formats in the overview table.

Accessing to an individual resource, enables to request the resource in different formats like JSON and CSV in this example.

Figure 44. Requesting the added source in different format.

To note that modifying the extension of this resource allows retrieving the resource in the preferred format immediately. However, for the correctly work of the KR component at this moment, it is recommended to use the JSON format. To add a combined resource, it is necessary to formulate a SPARQL query. In the following example, we find all landlocked countries with a population greater than 15 million. The query goes to an RDF store, in this case a remote RDF Store, DBpedia, that may contain the linked data of several other data sources, in this case extracted from many different Wikipedia pages.




Figure 45. Adding a SPARQL query.

When the resource is added it appears in the list of available resources

Figure 46. Resulted SPARQL query data in the overview of available resources table.

The result is a table, available in different output formats, but in this case with the aggregated results.




Figure 47. Data source overview panel.

3. Allowing other applications to create and edit resources. It is possible to integrate other applications (in any programming language) on the top of The DataTank API. Once the resource definition template is set up to know which metadata properties are needed to create a valid resource definition, in order to publish data from a certain data structure, the discovery document should be consulted. The discovery document shows a list of methods that one can perform on the resources of a DataTank instance. One of those resources is called ‘definition’ and is used to create, read, update and delete resource definitions. For tutorial purposes, a small snapshot is taken and displayed below. More details on this are explained in The DataTank documentation [29].

4. Adding formats and resource types supported by The DataTank. It is possible to extend

The DataTank to support new data sources. The instructions on how to do this are provided in The DataTank documentation [30].

5. Mapping/linking data sources in different formats. RML enables reusing mapping

definitions/configurations to be used with different formats. The example below shows this for a JSON and XML file that contain similar data about describing the location of certain venues.

6. Automatic generation of mapping documents based on resource and property selection.

Currently the mapping documents need to be manually composed, and the mapping step manually performed. Fusion is done subsequently by the KP component by converting KPI definitions to SPARQL queries.




Figure 48. Extending data formats.


As this component consists of three subcomponents, each component has its own design implications. The DataTank Overall, it is recommended to interact with the data component through the HTTP interface, either via a software program or script or the included Web UI in The DataTank. The DataTank is implemented in PHP, any extensions or plugins will need to be written in PHP or at least offer a PHP wrapper or be accessible via pipes, for example a CLI. The DataTank offers a REST HTTP interface with output in different formats to allow other software programs and web agents to retrieve data from it. The REST HTTP interface of The DataTank can also be used to create and update data sources, therefore it accepts JSON documents as configurations. The deployment of The DataTank is done by following the setup instructions [31], and at the time of writing, there exists no all-purpose Docker container, but it is tweaked8 to be able to run in a Docker container for the internal deployment. RDF store There exist several RDF Stores of which a few are open source. One of them, Blazegraph9, works well with the KR component, so has been deployed (available in a Docker container) on a testing server of imec. At the time of writing, the RDF store Virtuoso10 has a known bug regarding

8 Available at https://github.com/ghsnd/core/tree/production-install 9 https://www.blazegraph.com/ 10 https://virtuoso.openlinksw.com/

https://github.com/ghsnd/core/tree/production-install

https://www.blazegraph.com/

https://virtuoso.openlinksw.com/




queries over date ranges, which is used for calculating some KPIs. A No other options have been tested yet. RML Mapper The RML Mapper is written in Java, but is accessible for other applications via the CLI. The mapping configuration documents follow the RML specification which is documented here [32]. Deployment implications It is possible to deploy all the three subcomponents on the same server; however it is recommended to separate the server hosting The DataTank from the server hosting the RDF Store / RML Mapper. The actual requirements in terms of resources (e.g. server capacity, disk space...) depend on the size of the project and the amount of data expected to be processed.

3.5 User assessment


The User Assessment (UA) component will support the functionality of assessing a public digital service by a user of that concrete service. Once a user has used a public digital service through the PA platform, this component will provide the means to assess the service (through a ranking) and a free text comment, answering an evaluation questionnaire.

The UA component will also serve the PAs to analyse the assessment of the different services by the users. For that purpose, UA will provide a specific PA UI where to check the punctuation received by each service and the analysis of the comments where the users have expressed their experience with digital public services .

The corresponding functional requirements for UA component are:

Requirement id UA.01

Req. short title UA component will provide means for users to evaluate a certain public digital service after using it.

Req. description The UA component will provide a ranking mechanism for the user and a free text collector, so that the user can assess his/her experience with the digital service answering a few questions. Upon requests towards the SM component, sensitive information included in the questionnaire will be anonymized / encrypted.

State Done

Priority Must have

Relate KR KR6, KR8




Comments PA can create their own questionnaire to be submitted to the citizens.

The anonymized information aspect of is not required because no information of the citizen is stored.


Req. short title UA component will store the assessments/evaluations provided by the users about the different digital public services.

Req. description The UA component will store the different evaluations provided by the users, with respect to the digital public services and the info collected from the social networks, so it can be later accessed by the PAs.

State Done

Priority Must have

Relate KR KR6, KR8

Comments The analysis of the social networks is not going to be implemented. This aspect is identified as future work.

Sentimental analysis of the comments is done, to identify if a comment is positive, neutral or negative.


Req. short title UA component will provide utilities to visualize the assessments performed by the users, with respect to specific public services.

Req. description The UA component will visualize the assessments of the services and other relevant information reported in social networks.

State Done

Priority Must have

Relate KR KR6, KR8

Comment No social networks information is analysed.





Req. short title UA component will analyse information provided by the users about their experience when using digital public services.

Req. description The UA component will analyse data coming from the social networks (positive/negative comments) with respect to to the usage of the digital public services to be shown to the PAs.

State Done

Priority Must have

Relate KR KR6, KR8

Comment Sentimental analysis of the comments made by the citizens is done, to identify if a comment is positive, neutral or negative.

No social networks information is analysed.

For this component the User requirements are the following:

Requirement id UA.UC. 01

Req. short title The evaluation must give to the user the opportunity to add a comment

Req. description If the user rates certain service, there also should be an option for him/her to explain this evaluation.

Source VARAM

State Done

Priority Must

Comment PA can select if they want to have the comment as mandatory, as optional or only mandatory if the rate is low.


The UA component is composed of the following sub-components:

• UA rating UI: The UA rating UI will interact with the different users of the UA component. This UI will provide the interface to the user of the service so that he or she can provide a ranking for a concrete service.

• UA analysis UI: this UI provides the interface for the PAs. This interface allows in one hand to check the results of the assessments, both the ranking and the sentiment analysis done to the comments and on the other hand, it allows PAs to create the




questionnaire that the citizens should answer when rating a service. PAs can create questionnaires as they want, but only one will be available to be published.

• UA analysis (backend): This sub-component will analyse the information coming from the citizens (rating and comments) with respect to specific digital public services.

• UA Database: This database will contain the defined questionnaires by the PAs and the assessments coming both from the user directly (ranking from the user of a service) and from the assessment analysis component .

In the Figure 49, these components and their interactions are represented:

Figure 49. Internal architecture of the User Assessment component.


Here, the process followed by a user when using the UA component is described. It is assumed that the user is already logged into the system.

Process to perform the analysis of the assessment of a service (when the user is a PA):

1. The user requests for available questionnaires that each questionnaire contains a set of services, with their ratings and comments. The information can be analysed by service and by question.

2. The UA analysis sub-component performs the analysis based on the info coming from UA database and provides it to the UI.

3. The user gets the analysis (in form of some metrics) about the rates and comments of the service and its questions.




Figure 50. Analysis of the assessment of the service sequence diagram.

Figure 51. Assessment of a service sequence diagram.

Process to provide a ranking for a service (when the user is a citizen):

1. The user selects the services for which the user assessment is available through the UI. The available services are those which are included in an active and published questionnaire.

2. The user rates the service through the UA rating UI, answering a few questions, and adds a comment about his/her experience.

3. The ranking of the service and the comment are stored in the UA Database.

Process to create/publish a questionnaire (when the user represents the PA)




1.- User requests to the UA analysis to create a new questionnaire

2.- Once the questionnaire is created and stored in the UA database, the user may publish it.

3.- User select the questionnaire to be published. The UA analysis UI checks that the questionnaire is active, this means that in the publication date, this questionnaire is valid.

4.- UA analysis publishes the questionnaire and change the status in the UA database.

Figure 52. Create and publish a questionnaire sequence diagram.


The user of the User Assessment can be both the PA user and the citizen. Based on the role of the user, the component will perform different actions (see sequence diagrams in previous section).

The UA component will interact with the Security Manager for loading the user profiles (which affect the rendering of the UI).

Figure 53. External interfaces of the component User Assessment.

In Figure 54, an example of the UA analysis UI is presented and in Figure 55, the example of the UA rating UI is shown.




Figure 54. UA Analysis UI .

Figure 55. UA Rating UI.


The User Assessment component will be a novel application implemented from scratch, so it will not be based in any existing tool.




For the implementation of the back-end and the front end, JHipster framework [23] has been chosen as the best candidate for the moment. The communication (connectors) with other components will be done thorough REST APIs.

3.6 Security Management

3.6.1 Access Management + Encryption


The Access Management + Encryption component comprises:

• a set of server components, providing web services that support the security features in terms of exchange of / access to data

• a set of libraries that a generic client (the libraries are available both in Java and Javascript technology in order to be usable both in web and desktop environments) can use to benefit from the security features provided and interact with the server components.

This component has been designed to implement the following non-functional requirements:

Requirement id SC.01

Req. short title Security / privacy by design support

Req. description The system shall be designed taking into account the security and confidential data management needs; security and privacy protection (i.e., proper management of confidential data) shall be essential elements of the system.

State Proposed

Priority Must have

Relate KR KR7


Req. short title Security / privacy by default support

Req. description The design and default configuration of the system shall ensure a minimum level (which means an acceptable level only to increase) of security and privacy (i.e., confidential data management) that:

(1) cannot be lowered (2) is configured by default

State Proposed




Priority Must have

Relate KR KR7


Req. short title CP-ABE encryption support

Req. description Data encryption / decryption performed in the context of CITADEL information exchange will follow the Ciphertext-Policy Attribute-Based Encryption scheme.

State Proposed

Priority Should have

Relate KR KR7


Req. short title Proof of ownership support

Req. description The user’s authentication shall be performed using a proof of ownership instead of traditional authentication mechanisms (e.g., challenge/response), in order to avoid storing on the service side security sensitive data like passwords. At login action, in fact, a certificate holding the user’s private and public keys is passed to the browser and the user is requested to provide her/his password that shall be used, locally within the browser, to decrypt the user’s private key, thing that provides proof of ownership of the certificate stored in the user’s profile.

State Proposed


Relate KR KR7


Req. short title ECDSA support




Req. description When a user registers, the system shall generate a 256-bit ECDSA (Elliptic Curve Digital Signature Algorithm) keys pair according to the US NIST FIPS-186 specification [33]. The private key shall be securely encrypted using the user’s password specified during the registration process and the encrypted private and public keys shall be structured into a kind of certificate and stored in the user’s profile.

State Proposed


Relate KR KR7


Req. short title LDAP support

Req. description Users’ profiles shall be managed using a LDAP Directory Service, where users’ attributes shall be structured in accordance with X.500 schema.

State Proposed


Relate KR KR7


Req. short title Authorization based on policies and roles

Req. description The user’s role, stored as an attribute within the user profile, shall be the base element to establish what the user is allowed to do. Furthermore, the authorizations on specific actions related to specific items, are defined on the basis of access policies defined as logical combination of user’s attributes and associated to the item.

State Proposed

Priority Must have

Relate KR KR7

The main features provided by this component are:




• management of encrypted storage and decrypted retrieval of files with sensitive or reserved information;

• management of CP-ABE access policies through which it is possible to define access policies governing the files encryption process, so that, only users having profiles with the set of attributes specified in the policy will be actually enabled to decrypt the file;

• management of access keys through which authorized users can obtain their personal decryption keys;

• users' registration, authentication and authorization. The security-by-design and privacy-by-design guidelines have guided the structuring of the system, as well as the design of the authentication and authorization features, and the selection of the related technologies. The privacy-by-design guidelines essentially help in addressing issues related to the management of confidential and sensitive information circulating in the context of CITADEL use cases. This ensures to the CITADEL users and operators that potentially confidential or sensitive information will never be accessed by people not explicitly authorized, independently from where and how the information is stored and managed (e.g., backup systems).

The user’s authentication is actually performed using a proof of ownership instead of traditional authentication mechanisms (e.g., challenge/response), in order to avoid having to store on the service side security sensitive data like passwords. The password, in fact, is used, locally within the client, to decrypt the user’s private key that is then used to generate a proof of ownership11 of the public key stored in the user’s LDAP profile.

The user’s password is, therefore, only managed locally and never transmitted to, or shared with, other systems. Of course, if users forget their passwords they will not be able to access the system and there is no possibility to “reset” user’s passwords. In this case the user has to ask for the renewal of its registration.

The users’ profiles are managed using an LDAP Directory Service, in order to reuse the X.500 schemas and the LDAP features. Figure 56 provides an overview of the planned overall directory organization.

Figure 56. Overall Directory Service Structure.

As envisaged by the X.500 standard, there will be entities representing Countries under which the organizations will be positioned. At this level, there is no distinction among the different kinds of organizations (e.g., public authorities like Regione Puglia, IT providers like FINCONS).

11 The proof of ownership actually consists in digitally signing a challenge provided by the Web Service with the user’s certificate




The role associated to each user of the system can be selected among those listed in the table below, which indicates the permissions assigned to each role, related to the possibility to view and / or to create a file and or an access policy (the permissions in general are limited to files and policies defined in the frame of a specific use case, but users with Ethical Board Member role may have access to items linked to different use cases).

Use Case A Use Case B … Role File Policy File Policy File Policy

Use Case A Interviewer

Create View No Access No Access No Access No

Access

Use Case A Analyst

View View / Create

No Access No Access No Access No

Access

Use Case A Privacy Officer

View / Create /

Drop

View / Create

No Access No Access View No

Access

Ethical Board Member

View based on

policy

View / Create

View based on

policy

View / Create

View based on

policy

View / Create

Administrator No Access No Access No Access No Access No Access No

Access


The component has been designed according to the Security-by-Design, Privacy-by-Design and Security-by-Default and Privacy-by-Default principles. Security/Privacy-by-Design means that the system has been designed considering the security and confidential data management needs, so the security and privacy (i.e., proper management of confidential data) is an essential element of the system. Security/Privacy-by-Default means that the security design and default configuration of the system already assure a minimum level (it means an acceptable level which can be increased only) of security and privacy (i.e., confidential data management) that: (1) cannot be lowered, (2) is configured by default. Indeed, one of the most relevant features of the system is the end-to-end protection of confidential data (e.g., aircraft videos) using new cryptographic techniques like CP-ABE (Ciphertext Policy Attribute Based Encryption). From the security point of view, in addition to the CP-ABE [34] encryption techniques, the AuthN/AuthZ system makes use of the new W3C Web Crypto API [35] , Elliptic Curve Cryptography (ECC), Elliptic Curve Diffie–Hellman (ECDH) [36] and JWT [37]. To increase system’s security every operation requires a specific Authorization Token dynamically generated based on the user’s profile and requested operation.

The system is made up of the following components (see Figure 57):

• the LDAP Service: this service, based on the X.500 standard and the LDAP

(Lightweight Directory Access Protocol) protocol, is used to manage customers’ and

authorized users’ profiles. With reference to the authentication issues, the LDAP Service

is not actually used to authenticate the user, but only to store user’s related information

(i.e., user’s certificates) necessary in the authentication process. This to assure, in line

with the security-by-design approach that sensitive information cannot be grabbed;

• the ABE Key Generation Service is a critical component required to support the encryption of information (i.e. files) using the CP-ABE encryption technique. In CP-ABE,

a user provided access policy governs the encryption process. The policy, therefore, can




be considered as actually encoded in, and an integral part of, the encrypted information.

Only decryption keys having the characteristics requested by the access policy will

succeed in decrypting the protected information. The ABE Key Generation Service at

start-up generates two keys: the public key used to encrypt files in conjunction with a

given policy, and a master key used, in combination with the user’s profile retrieved

from the LDAP service, to generate the user’s private key necessary to decrypt a file.

Figure 57. Encryption + Access architecture.

• the Access Token Service is devoted to managing authorization providing specific access tickets. Being the system distributed, there is the need to ensure that a specific

request submitted by the user (or potentially by other components) is among the ones

the user is authorized to perform (e.g., upload a file). Instead of having ACLs or other

access control mechanisms on each service components12 the system envisages a

specific service that, based on the user’s profile stored in the LDAP Service, grants an

access ticket;

• the Policy Storage Service is devoted to support the management (i.e., storage and retrieval) of the access policies that a given company and its customers can define

to be used to encrypt the uploaded video files as described in the next bullet. The

functionalities supplied by this service are essentially to provide a storage area for each

of the company’s customers registered within the system where they can store, or from

which they can retrieve, the access policies they plan to use for encrypting their

information (i.e. files). The access control to this service is managed via access tickets

provided by the Access Token Service. From an operational point of view, when

12 Such approach would imply to have to manage access rules on each system, which could create

inconsistencies and requires additional management effort




submitting a policy storage or policy retrieval request, it has to provide an access ticket

that provides evidence the request is authorized. The access ticket is validated by the

service before performing the requested operation;

• the Storage Service is devoted to support the management (i.e., storage and

retrieval) of files. The functionalities supplied by this service are essentially to provide a

storage area for each of the users registered within the system where they can store, or

from which they can retrieve, the files. Access to the stored files are managed via access

tickets as described for the previous service;

• the Client provides the web or desktop GUI13 supposed to integrate the libraries

through which end-users, after login, can access to the functionalities of the system; the

libraries on the top of which the client has to be developed (available both in Java and

Javascript version, see Annex 2 for API references) are:

o TokenServiceClientLib

o FileProtectorServiceLib

o AbeProxyInterface

o CertificateManager


This section describes the behavioural aspects of the sub-components in the main functional flows of interest for the component.

The first process considered is the user’s registration, which is split into two phases:

• an off-line phase in which the system administrator inserts the user (identified by name, surname and email address, and associated to a defined role) into the LDAP Service under the proper organization.

• an on-line phase where the user accesses to the registration UI (see Figure 63), entering username (i.e. the email address used in the off-line phase) and choosing a password to complete the registration.

The sequence diagrams representing the registration and login functions, reported below, are very similar. In fact, in both situations, the client queries the LDAP Service on the basis of the information provided by the user (username) looking for a user matching the provided information and, in case of success, picks up from the LDAP user’s profile.

At registration time, the client library generates the pair of public and private keys (the Diffie-Hellman14 algorithm is used) and a certificate in JWK format that includes them (the private key is encrypted); this certificate is stored in the LDAP database. To increase the overall security level, at login time this certificate is renewed through the use of a random salt in the encryption algorithm.

The difference between the two processes is the fact that, at login time, the client picks up from the LDAP user’s profile the certificate previously stored holding the user’s private and public keys. This certificate, with some additional information is passed to the client and the user is requested to provide his/her password. The password is used, locally within the client, to

13 Being the other components of the system essentially REST accessible services, the end-user’s

functionalities can be even provided by a locally installed application accessing the other services 14 https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange




decrypt the user’s private key that is then used to generate a proof of ownership of the public key stored in the user’s LDAP profile. The client checks the correctness of the proof of ownership and, if successful, generates the token that will be used to access to the system functionalities.

The implementation of this proof of ownership mechanism, based on the certificate, makes unnecessary the storage of user’s sensitive data (the password) in the LDAP database.

Figure 58. Registration Function.

All calls to AuthN/AuthZ services (e.g., policy storage service, file storage service) require

obtaining authorization tokens specific for the request. These authorization tokens are created,

taking as input the token generated as result of the login process, through the interaction with

the Access Token Service, which validates the user permissions to access the service requested

and returns the authorization token, in JWT format, for the specified service.




Figure 59. Login Function.

Figure 60. Generate Token Function.




The diagram above describes the process that leads to the generation of the encrypted file

through the different steps of the interaction between the client, equipped with the library with

the file protection features, and the ABE Key Generation Service component. The posting

towards the Storage Service component of the JSON structure that includes the encrypted file

along with the access token obtained with the process previously described the step necessary

to complete the upload process.

The subsequent diagram describes the download and decryption process.

D4.4 – CITADEL final Ecosystem Architecture Version 1.0 – Final. Date: 31.03.2019


www.citadel-h2020.eu

of 107

Figure 61. Upload File Function.



www.citadel-h2020.eu

of 107

Figure 62. Download File Function.





The security services provided by the component are accessible only for registered users.

The screenshots provided in this section refer to a sample web client, shipped with the component, that integrates the Javascript client libraries.

Figure 63 depicts a typical UI for handling the on-line phase of the registration process (see previous section for a technical description of the two phases), with the assumption that the registration off-line phase has already been done by the administrator.

Figure 63. Registration page.

Once registered, the user can login to the system, by using email address and the selected password.

All users having the right to create policies need to refer to an appropriate tool to perform such operation, as the ‘Create Policies’ web page below, which provides an intuitive tool to graphically defines policies: on the left panel there are the widgets representing the attributes that may be used as part of the policy definition (most of them work like combo-boxes) and logical conditions (‘AND’ and ‘OR’) used to combine them. Once the user has defined the policy (the ‘Text Policy’ box provides a textual representation of the policy graphically defined) she / he can save it through the ‘Confirm Policy’ button.





Figure 64. Create policy tool.

Similarly, all users having the right to view policies are enabled to access to a visualization tool, the ‘View Policies’ web page below, which provides the possibility to browse and check the policies already defined on the system and visible for them, as shown in Figure 65.

Figure 65. Policy visualization tool.

All users having the right to upload files to the encrypted files repository are enabled to access to the tool ‘Encrypted files upload’ web page, where they can select the file that they want to process with the encryption service (through the ‘Upload’ button) and to select the policy file to be used for the encryption, which will define, then, who will be authorized to decrypt the file. The ‘Start Encryption’ button triggers the encryption and upload task that, once successfully completed, displays the ‘Saved Correctly’ label on the page.





Figure 66. Encrypted files upload page.

All users having the right to view files stored into the encrypted files repository are enabled to access to the tool ‘Encrypted files download’ (see Figure 67), where they can select the file that they want to process with the decryption service. The ‘Start Decryption’ button triggers the decryption and download task. The user, of course, is allowed to view a given document only if the policy used for the document encryption matches with the user’s profile (stored on the LDAP

server). Shouldn’t this be the case, the message will be displayed to the user. To mind that all users having the right to view files loaded on the system, also have the right to request their personal decryption key to the ABE Key Generation Service. Before downloading a document, then, the client has to generate this key, on behalf of the user logged-in.

Figure 67. Encrypted files download page.


The following table lists the components part of the technological stack over which the Encryption + Access component is built.

Table 6. Encryption + Access technological stack.

Item Value

Programming Language Java, Javascript

Additional Libraries Web Crypto API, CryptoJS, RESTlet

Application Server Tomcat

System Requirements Java SE 7 or later installed





At the time of writing, there exists no all-inclusive docker container, but the creation of a suitable Docker container (or a set of Docker containers) to consistently deploy the subcomponents in a certain configuration is among the technical objective in the development roadmap of the platform. The license of the platform is GNU GPL2; the CITADEL developments and bug fixing of the original version are going to be released with the same license.

3.6.2 Anonymization


Anonymization (AN) component will provide the capability of anonymizing the data when needed by a PA or by another component in the CITADEL ecosystem.

Requirement id AN.01

Req. short title AN component will anonymize data under request.

Req. description AN component will anonymize (removing personally identifiable information (PII) from user data or masking identifying information (pseudonymization)) when it receives a request for anonymization from any other component in the CITADEL platform or directly from the PA. The AN component will receive the anonymization request and the data to be anonymized. The Anonymization component will provide the anonymized set of data.

State Done

Priority Must have

Relate KR KR7, KR8

Requirement id AN.02

Req. short title AN component will store the anonymized data.

Req. description AN component will store the anonymized/ pseudo-anonymized for further analysis.

State Done

Priority Must have

Relate KR KR7, KR8


The AN component is composed of the following sub-components:





• AN UI: The AN UI will interact with the different users of the AN component. The main user of the AN is the PA user that needs to anonymize or pseudo anonymize the data.

• AN engine: The AN engine will anonymize the data based in the input from the user.

• AN registry: This registry will contain anonymized data, so they can be used by the other components in the CITADEL ecosystem.


Figure 68. Internal architecture of the Anonymization component.


Here, the processes followed by a user when using the AN component is described. The main user of the anonymization component will be the PA or another component in the CITADEL ecosystem.

Process of performing the analysis of anonymization of a data set (when the user is a PA). It is assumed that the user is logged into the system through the Access Management component:

1. The user selects the dataset to be anonymized. This data is data from the PA that will be loaded into the anonymization component through the AN UI.

2. The user configures the anonymization process in the UI (degree of anonymization, specific data where to apply the anonymization, etc).

3. The AN engine performs the anonymization and stores the anonymized data in the AN registry.

4. The user can check the result of the anonymization through the AN UI.





Figure 69. Anonymization process sequence diagram when the user of the component is the PA.

Process of performing the analysis of anonymization of a data set (when the user is another component). It is assumed that the user is logged into the system through the Access Management component:

1. The external component asks for anonymization and provides the data to be anonymized and the configuration of the anonymization.

2. The AN engine performs the anonymization and stores the anonymized data in the registry.

3. The AN engine provides the anonymized data to the external component.





Figure 70. Anonymization process sequence diagram when the user of the AN component is another component of the CITADEL ecosystem.


The user of the Anonymization component can be both the PA and a component of the CITADEL ecosystem. The process for anonymization is the same in both cases but in one case it is triggered trough the AN UI and in the other case it is triggered by the Anonymization connector which receives the anonymization request.

The AN component will interact with the Security Management Component for authentication and with other components in the ecosystem that needs to anonymize data. These potential components are: KPI Report Generation, User Assessment and Intelligent Discovery of public services.

Figure 71. External interfaces of the component Anonymization.





In the following pictures, the mock-ups for the AN UI are presented. It is based on the ARX tool, so it will be based in the ARX UI:

Figure 72. AN UI mock-up.


The basis for the AN component will be the open source tool ARX [38]. ARX is a java-based application that anonymizes data following the globally-optimal anonymization algorithm, Flash. ARX provides a GUI and the backend with the correspondent API.

For more information about this tool check WD 4.1 [3].





4 Conclusions

The architecture presented in this document served a common basis for integration of the components and sub-components of the CITADEL Ecosystem. The goal of the document is to provide the detailed architectural plan based on the design implications from each component and (tool) specific technologies. The derived generic architecture supported the process of automating the services required to fulfil the functional and non-functional requirements defined in WD4.1, D4.2 and WD4.2.

With the design implications made in the previous sections we are also in the position to make some recommendations regarding the next steps. As the system is novel, further effort is still needed to tackle some technical challenges, especially in the configuration and deployment of different (sub-)components within an integrated solutions. For the integration of different subcomponents, it is important that the configuration process is supported in an appropriate and well-defined approach. Setting up the prototype environment thus focused on the detailed integration analysis and deployment scenarios in view of the technical profiles and design guidelines provided in this document. Iterative approach with (re)evaluation loops has been adopted to ensure the quality of the integrated solutions as well as to further refine the fine-grained functionalities of the ecosystem level. These updates are further documented in the description of the prototypes and technical implementation of use cases (D5.2, D5.3).

The design presented in this document has feed other WPs (such as the technical implementation of the use cases). In turn, the final ecosystem architecture has been also fine-tuned by considering the results of work-in-progress in other WPs (such as the ongoing work on the T5.2).





5 References

[1] CITADEL, «WD 4.1 Initial set of functional and technical requirements elicitation,» 2017.

[2] CITADEL, “D5.1 Definition of the use case scenarios,” 2017.

[3] CITADEL, “WD 4.1 Initial set of functional and technical requirements elicitation,” 2017.

[4] CITADEL, «D4.3 Initial CITADEL Ecosystem Architecture,» 2017. [En línea].

[5] CITADEL, “D4.2 CITADEL DevOps Infrastructure,” 2017.

[6] CITADEL consortium, «D4.1-Functional and technical requirements elicitation,» 2018.

[7] A. Rotem-Gal-Oz, SOA Patterns, Manning Publications Co, 2012.

[8] K. H. D. C. S. F. Buschmann, Pattern-Oriented Software Architecture: On Patterns and Pattern Languages, Wiley & Sons, 2007.

[9] S. R. L. Richardson, RESTful Web Services, 2007: O’Reilly Media, Inc..

[10] S. Vinoski, “RESTful Web Services Development Checklist,” IEEE Internet Computing,, vol. vol. 12, no. no. 6, pp. pp. 95-96, Nov.-Dec. 2008.

[11] V. Farcic, The DevOps 2.0 Toolkit - Automating the Continuous Deployment Pipeline with Containerized Microservice, Packt Publishing Ltd, August 2016.

[12] A. C. a. M. Chanliau, "Privacy and security by design: a convergence of paradigm," Ontario, Canada: Office of the Privacy Commissioner, 2013.

[13] E. Commission, "Article 29 Data Protection Working Party, “Opinion 8/2014 on the on Recent Developments on the Internet of Things," September 2014. [Online]. Available: http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014.

[14] F. S. Report, "FTC: Internet of things - Privacy & Security in a Connected World," January 2015.

[15] E. Commission, “GDPR,” [Online]. Available: http://ec.europa.eu/justice/data-protection/reform/files/regulation_oj_en.pdf.

[16] M. M. a. J. O. R. Ross, "Systems security engineering: Considerations for a multidisciplinary approach in the engineering of trustworthy secure systems," National Institute of Standards and Technology, 2016.

[17] E. Commission, ““EU eGovernment Action Plan 2016-2020 - Accelerating the digital transformation of government”, final,” COM(2016) 179 final.

[18] IDC, "Technology Spotlight: Securing Productivity in the Borderless Enterprise," January 2016.





[19] The Institute of Risk Management, "Extended Enterprise: Managing risk in complex 21st century organisations," 2014.

[20] A. McCormack, “Borderless Enterprise: End to organisational rigidity,” Financial Times, pp. http://www.ft.com/cms/s/0/6c06f502-dd27-11df-9236-00144feabdc0.html), October 2010.

[21] B. B. R. Ward, “BeyondCorp: A New Approach to Enterprise Security,” login: (Usenix);, vol. 39, no. 6, December 2014.

[22] J. McAdam, "Overcoming Borders and Improving the Network," November 2009. [Online]. Available: http://blogs.cisco.com/enterprise/overcoming_borders_and_improving_the_network.

[23] JHipster, "jhipster," [Online]. Available: http://www.jhipster.tech/. [Accessed August 2017].

[24] E. Foundation, “ECLIPSE BIRT,” [Online]. Available: http://www.eclipse.org/birt/. [Accessed 30 8 2017].

[25] W3C, “SPARQL Query Language for RDF,” 2013. [Online]. Available: https://www.w3.org/TR/rdf-sparql-query/. [Accessed September 2017].

[26] W3C, “RDF 1.1 Concepts and Abstract Syntax,” 2014. [Online]. Available: https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/. [Accessed September 2017].

[27] M. C. P. V. D. D. M. E. &. V. d. W. R. Vander Sande, "The DataTank: an open data adapter with semantic output.," 21st international conference on world wide web, proceedings, 2012.

[28] A. V. S. M. C. P. V. R. M. E. &. V. d. W. R. Dimou, "RML: A Generic Language for Integrated RDF Mappings of Heterogeneous Data," LDOW, 2014.

[29] DataTank, “DataTank documentation,” [Online]. Available: http://docs.thedatatank.com/6.6/create_definition. [Accessed September 2017].

[30] DataTank, “DataTank Documentation: Create your own source type,” [Online]. Available: http://docs.thedatatank.com/6.6/source_types#create_source_type. [Accessed September 2017].

[31] DataTank, “TDT documentation,” [Online]. Available: http://docs.thedatatank.com. [Accessed September 2017].

[32] Ghent University - iMinds - Multimedia Lab, “RDF Mapping Language (RML),” 2017, [Online]. Available: http://rml.io/spec.html. [Accessed September 2017].

[33] “Federal Information Processing Standard 186-4, Digital Signature Standard (DSS),2013,” 2013.





[34] J. Bethencourt, A. Sahai and B. Waters, “Ciphertext-Policy Attribute-Based Encryption,” [Online]. Available: https://www.cs.utexas.edu/~bwaters/publications/papers/cp-abe.pdf. [Accessed September 2017].

[35] W3C, “Web Cryptography API,” W3C, 2017. [Online]. [Accessed Septemeber 2017].

[36] NIST, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography," [Online]. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf. [Accessed September 2017].

[37] JWT, “JSON Web Tokens,” [Online]. Available: https://jwt.io/. [Accessed September 2017].

[38] ARX, "ARX powerful anonymization," [Online]. Available: http://arx.deidentifier.org/. [Accessed 30 08 2017].

[39] C. consortium, «CITADEL DoA,» 2016.

[40] Docker, “Virtuoso docker,” [Online]. Available: https://hub.docker.com/r/tenforce/virtuoso/. [Accessed September 2017].

[41] Drools, “DROOLS- Business Rules Management System,” 2016, [Online]. Available: https://www.drools.org/. [Accessed September 2017].





Annex 1: Flows of the Harvesting and curation component

The dynamics are very straightforward, as they each describe a segment from an ETL process that has only a single flow. Details on the individual steps of the flows are given in the next section. Step 1.

Figure 73. Harvesting datasets through upload.

Step 2.

Figure 74. Combining datasets.

In this flow we suggest extending the existing SPARQL query functionality by introducing a UI that hides the complexities of the construction of such as SPARQL query from the user. Introducing will require additional effort from our side. A detailed description of this feature is given in the section on Automatic generation of mapping configurations and SPARQL. Step 3.

Figure 75. Defining mapping semantics.


https://docs.google.com/document/d/1gBp8tTzHgxMZ1ikDSmQWUejGZefSx0I5zqOYJbZ4MrU/edit#bookmark=id.draolt51sdyn




Annex 2: AuthZ/AuthN and Encryption client libraries

How to use TokenServiceClientLib

TokenServiceClientLib is a Java library (shipped with the file tokenServiceClientLib-x.y.z.jar) that allows a client to use AuthN/AuthZ functionalities interacting with the server components available as part of the Access Management component.

First of all, a user must be registered15 using a call like: JsonObject JsonResponse= AuthenticationServiceClient.registration(username,

password, urlTokenService);

After the registration, if the JsonResponse returned has code 200 the user was successfully

registered. After being successfully registered the user must perform the login operation

NB. a possible value for urlTokenService is “https://myhost.mydomain.com

/Token_Service"

To login, it is necessary to invoke the method AuthenticationServiceClient.login, which

returns an UserTokenService object, that contains the user information needed to create

tokens for all subsequent calls to AuthN/AuthZ service. UserTokenService userToken= AuthenticationServiceClient.login(username,

password, urlTokenService);

All calls to AuthN/AuthZ services (e.g., policy storage service, file storage service) require

obtaining D4.4 CITADEL final Ecosystem Architecture authorization tokens specific for the

request (RequestToken). These authorization tokens are created with a 2 steps procedure:

• The 1st step creates a suitable instance of a token like in the following example: RequestToken rqToken = new RequestToken(userToken, expirationTime, new

Action(method, service, urlService));

where userToken is the element returned by the login operation, expirationTime is

the life time (expressed in milliseconds) for the requested token and the Action Object

requires to specify: the HTTP method (possible values: GET, PUT, POST, DELETE as a

String), a service String with the name of the target service (possible values:

KeyGeneratorService, FileSService, PolicySService) and the URL of the target

service urlService (e.g., “keygen”, Policy Storage Path Resource , File Storage Path

Resource).

• The 2nd step asks to the AuthN/AuthZ Token Service to validate the user rights and, in

such case, to provide an authorization token for the specified service. Through the

requestToken method the user checks if she/he is able to do the operation requested.

To call this method, the token instance created in step 1 (rqToken) is needed, along

with the URL of token service instance urlTokenService and

urlGenerateTokenService, the URL of the service whose invocation requires this

token. Possible values for urlGenerateTokenService are TokenEnumService.

DEFAULT_POLICY.getUrl(), or TokenEnumService. GENERATE_TOKEN.getUrl(), the

first one is used to generate a token to request the default Policy, the second one is

used to generate a token for the other service.

15 The method call will succeed only if the user being registered has already an instance (of type VidASUser) in the LDAP service





Token requestToken(RequestToken rqToken, String urlTokenService, String

urlGenerateTokenService).

• The 3rd step is the actual service invocation, and envisages a call like the following one: AuthorizationServiceClient.invokeService(requestToken, urlTokenService,

jsonInputData, urlService);

where requestToken is the token created in step 2, urlTokenService the URL of token

service instance, urlService is the URL of the service instance (for example

“https://myhost.mydomain.com/KeyGeneratorService"), jsonInputData is a Json

object used to send the input data in JSON format to the target service.

For logout the user must invoke the method AuthenticationServiceClient.logout that

returns a Json Object with the result of the operation : AuthenticationServiceClient.logout(user, urlTokenService);

Here follows the documentation of the classes and related methods, to use for the integration.

Class AuthorizationServiceClient Method invokeService

/** * Method use to invoke the service with the authorizationToken * * @param Token is the token obtained from the token service * @param String urlTokenService is the url of the TokenService instance * @param JsonObject inputData the input data for the service * @param String urlServiceToInvoke is the target service instance URL * @return JsonObject is a JSON structure that returns the HttpRequest result (i.e., 200 – OK, or the error message) */ JsonObject invokeService(Token token, String urlTokenService,

JsonObject inputData, String urlServiceToInvoke)

Method requestToken /** * Send a request toTokenService to get authorizationToken * * @param RequestToken * requestToken object that contains all information used to * request a token * @param String * urlTokenService is the url of the TokenService Instance * @return Token; to get the token is needed invoke the method token.getToken(); and is advised check the token validation with the method token.idValid(); * @throws Exception * */ Token requestToken(RequestToken requestToken, String

urlTokenService)

Class RequestToken /** *





* @param UserTokenService user info containing username challengeId and userSecret * (it is possible to generate a UserTokenService with AuthenticationServiceClient.login) * @param long experationTime the time duration of the token expressed in milliseconds * @param Action action to request the operation that contains Method Http, Service Instance Name, and service url */

RequestToken(UserTokenService user, long experationTime, Action action)

Class Action /** * * @param String Http method to invoke the service * @param String service name of the service instance * @param String url path of the specific resource to invoke */

Action (String method, String service, String url)

Class AuthenticationServiceClient Method login

/** * Method used to Login and generate a UserTokenService that is needed for the TokenGeneration * @param String username used to login * @param String password used to login * @param String urlTokenService * @return a UserTokenService, needed to tokenServiceOperation * @throws AuthenticationServiceException */

UserTokenService login(String username, String password, String

urlTokenService)

Method logout /**

* * @param UserTokenService user info contains username challengeId and userSecret * (is possible generate UserTokenService with AuthenticationServiceClient.login) * @param String urlTokenService is the url of the TokenService Instance * @return JsonObject is a Http Response * @throws Exception */

JsonObject logout(UserTokenService user, String urlTokenService)

Method registration /**

* Method used to fill up the LDAP user’s entry with the user Certificate * N.B.: the user’s LDAP entry must already exist and be of type AuthN/AuthZUser)





* @param String username used to login * @param String password used to login * @param String urlTokenService is the url of the TokenService Instance * @return JsonObject is a Http Response * @throws AuthenticationServiceException */

String registration(String username, String password, String

urlTokenService)

How to use FileProtectorServiceLib

FileProtectorServiceLib is a Java library (shipped with the file fileProtectorServiceLib-x.y.z.jar) that allows a client to encrypt and decrypt a file with CP-ABE/AES.

For using the encryption is necessary to invoke the method EnryptedFile encrypetedFile =

FileProtectorServiceClient.encryptFile(DecryptedFile decryptedFile,

CPABE_Policy policy, AbeProxyConfig abeProxyConfig);

Before invoking the encryption method is necessary to create three objects:

• DecryptedFile (byte[] decryptedFileData, String nameFile, String

typeFile, String uploadBy) this object contains a byte array of the file that you

want encrypt, the name of the file, the file type and the username of the user that has

to upload the file.

• CPABE_Policy (String specs, String url, ArrayList<Metadata> metadata) is

an object that contains the policy (in string format) or the URL of the policy with which

you want to encrypt the file, and all necessary metadata (it is possible get the policy in

string format through the invocation of the PolicyStorageService).

• AbeProxyConfig(String proxy_ip, String proxy_port, String proxy_id,

String proxy_instance_name) is an object that contains all the parameters needed

to use the ABE-proxy. ABE-proxy is used for the CP-ABE encryption of the shared

symmetric key. After the method execution, we obtain an EnryptedFile object that

contains: as attributes, the encrypted file in base64url encoded, the name of the

original file, the type of the original file, the username of the user who has encrypted

the file, the information about the KeyStorage service used, and the initialization

vector used to encrypt the file.

To decrypt a file is necessary to invoke the method DecryptedFile decryptedFile =

FileProtectorServiceClient.decryptFile(EnryptedFile encFile, String

personalKeyB64u, String publicKeyB64u);

Before invoking this method is necessary to have the EnryptedFile and the personal and

public keys (it is possible to request the personal and the public keys by the invocation of the

KeyGenerationService).

Class FileProtectorServiceClient Method encryptFile

/** * Method that encrypt the file with CPABE-AES algorithm





* @param decryptedFile object use to pass the file and the metadata file * @param policy object that contains the String policy used to encrypt the file * @param abeProxyConfig the config necessary to use abeProxy for encryption * @return EnryptedFile an object that contain the metadata of the file encrypted and the encrypted data in base64url */ EnryptedFile encryptFile(DecryptedFile decryptedFile,

CPABE_Policy policy, AbeProxyConfig abeProxyConfig)

Method decryptFile /** * Method that decrypt the file with CPABE-AES algorithm * @param encFile EnryptedFile an object that contain the metadata of the file encrypted and the encrypted data in base64url * @param personalKeyB64u the user personal key base64Url encoded (is possible get the this key from keyGenerationService/keygen) * @param publicKeyB64uv the user public key base64Url encoded (is possible get the this key from keyGenerationService/keygen) * @return DecryptedFile an object that contain the metadata of the file encrypted and decrypt file in byte array * @throws Exception */ DecryptedFile decryptFile(EnryptedFile encFile, String

personalKeyB64u, String publicKeyB64u)

Class EnryptedFile /** * @param key_info object relative to key information, include the Storage where the key is saved. * @param nameFile the original file name * @param typeFile the original file type * @param encryptor the encryptor username * @param encfile file encrypted converted in base64Url * @param iv initializzation vectore used to encrypt file converted in base64Url */ EnryptedFile(Key_Id key_info, String nameFile, String typeFile, String encryptor, String encfile,

String ivB64U)

Class DecryptedFile /** * @param decryptedFileData Byta Array of a File or a data that the user would encrypt * @param nameFile name of the file that the user would encrypt * @param typeFile the type of the file that the user would encrypt * @param uploadBy the name of the user that have uploaded the file */

DecryptedFile(byte[] decryptedFileData, String nameFile, String typeFile, String uploadBy)

AbeProxyInterface





AbeProxyInterface.js is a JavaScript library that allows a web client to encrypt and decrypt a file

with CP-ABE/AES.

/** * AbeProxyInterface javascript, * @author Diego Pedone (Fincons Group) * ---- javascript class used for emcryption and decryption in particularly for concatKdf ---- * @required <script type="text/javascript" src="crypto/components/core.js"></script> * @required <script type="text/javascript" src="crypto/components/sha256.js"></script> * @required <script type="text/javascript" src="jsrsasign/crypto-1.1.js"></script> * ---- javascript class used for conversion ---- * @required <script type="text/javascript" src="scripts/jsrsasign/base64x-1.1.js"></script> * @required <script type="text/javascript" src="scripts/jsrsasign/ext/base64.js"></script> * ---- worker use to communicate with abe proxy ---- * @required "scripts/abeClient/workerAjaxAbeClient.js", imported like worker * @version 1.0 (problem with big File). */ /** * @costructor * @params config must have this structure: * * { * worker: is the workerAjaxAbeClient path (used for connect to AbeProxy, * key_alg: the algorithm use to create the couple of key, * key_crv: the curve use from the key , * key_kty: identified the key type, key_enc: the algorithm which will be used to encrypt the data, * url_abeProxy: the abeProxy's url, * username: username , key_storage_type:The key_Storage type es. database, * key_storage_ip: the KeyStorageService's ip address or host , * key_storage_port:the KeyStorageService's port , * key_db_database:the database name used in keyStorageService, * key_db_table:the table name used in keyStorageService, * } * First of all is needed the initialization by the costructor passing the config like parameter. * @Encryption: instruction to use the library for the encryption * - 1 set the operation, this operation allow to have a different username for encryption and decryption, * needed for a correct configuration of shared symmetric key. * - 2 invoke getSharedSecret for the generation of a shared Symmetic Key * - 3 create a new key used for the sign the message with importHMACKey method * - 4 import the sharedSymmetricKey in webcrypto Format with importAESCBCWebcryptoKey method * - 5 use the method encSharedSymmetricKey to encrypt the policy, sign the encrypted policy * and send it to ABE-Proxy. the Abe-Proxy return the id of SharedSymmetricKey. * - 6 encrypt the data with sharedSymmericKey. * - 6.1 generate a random IV * - 6.2 encrypt the data and return the encrypted file. * * @Decryption: instruction to use the library for the decryption * - 1 set the operation, this operation allow to have a different username for encryption and decryption, * needed for a correct configuration of shared symmetric key. * - 2 invoke getSharedSecret for generate SSKP , a key used to Protect the Shared Symmetric Key used for the data encryption





* - 3 create a new key used for the sign the message with importHMACKey method * - 4 import the SSKP in webcrypto Format with importAESCBCWebcryptoKey method * - 5 use the method getSharedSymmetricKeyProtect to send to AbeProxy a request to get the ShaderSymmetricKey by Id, * the SSK(shared Symmetric Key) is protect by the SSKP ( shared Symmetric Key protector, a key used to encrypt the SSK). * - 5.1 verify the sign of the response * - 5.2 decrypt the sharedSymmericKey with SSKP. * - 5.3 import the sharedSymmetricKey in webcrypto Format with importAESCBCWebcryptoKey method * - 6 decrypt the data with sharedSymmericKey. * - 6.1 get the iv from protected file * - 6.2 decrypt the data and return the decrypted file. */

authNauthZclient

/** * Register a new user * @param username * @param password * @param urlTokenService URL of the token service to query * @returns response HTTP response to check the request status */ function register(username, password, urlTokenService){

/** * Login * @param username * @param password * @param urlTokenService URL of the token service to query * @returns userTokenService JSON object with the user’s session token */ function login(username, password, urlTokenService){

/** * Logout * @param userTokenService JSON object with the user’s session token * @param urlTokenService URL of the token service to query * @returns response HTTP response to check the request status */ function logout(UserTokenService userTokenService, String urlTokenService)

/** * Request an access Token to the Access Token Service that * verifies if the user is authorized * @param nameService name of the service to access which the

authorization token is necessary * @param userTokenService session token got from the login operation * @returns sJWT Json Web Token to access the service */ function requestToken(nameService, userTokenService){ /** * Execute the service requested * @param sJWT Json Web Token got from the Token Service * @param deferedRequest Url of the target service * @param input input data for the request to the target service * @returns response HTTP response to check the request status





*/ function executeService(sJWT, deferedRequest, input){


D4.4 CITADEL final Ecosystem Architecture · 2019. 4. 1. · D4.4 – Final CITADEL Ecosystem...

Documents

Transcript of D4.4 CITADEL final Ecosystem Architecture · 2019. 4. 1. · D4.4 – Final CITADEL Ecosystem...