A Citizen-Centric and Multi-Curator Document Automation Platform: the Qbox and Further Interoperability Aspects

A Citizen-Centric and Multi-Curator Document Automation Platform: The qBox and Further Interoperability Aspects

Daniel Jose´ Matias Caramujo

Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering

Supervisors: Prof. Doutor Alberto Manuel Rodrigues da Silva Prof. Doutor Joao˜ Paulo Pedro Mendes de Sousa Saraiva

Examination Committee

Chairperson: Prof. Doutor Francisco Joao˜ Duarte Cordeiro Correia dos Santos Supervisor: Prof. Doutor Alberto Manuel Rodrigues da Silva Member of the Committee: Prof. Doutor Andre´ Ferreira Ferrao˜ Couto e Vasconcelos

October 2019

Acknowledgments

I would like to thank my parents and family for their support and encouragement over all these years, without whom this this project would not be possible. I would also like to acknowledge my dissertation supervisors Prof. Doutor Alberto Silva and Prof. Doutor Joao˜ Saraiva for their insight, support and sharing of knowledge that has made this Thesis possible. Last but not least, to all my friends and colleagues that helped me grow as a person and were always there for me. To each and every one of you, thank you.

Abstract

Interoperability is an important aspect of complex information systems that have to interact and integrate with a multitude of other systems and services. New interoperability norms and frameworks are being promoted, and in this thesis we discuss some of them in the scope of eGovernment and document automation systems. This thesis explores integration aspects of qDocs, a citizen-centric document automation platform. qDocs aims to make bureaucratic documents (e.g., ID cards, forms, certificates) easily curated by multiple organizations and easily available to citizens. A key challenge of the proposal that is the foundation of this thesis is the correct integration of these organizations’ systems with the qDocs because they have to collect/provide data from/to the documents. The solution presented in this thesis is named as qBox, which is a software component to be deployed at each organization’s environment that supports both interoperability and security requirements. It was designed with a strong focus on document datasets and their specifications, to be developed as an independent module called qBox and integrated with the qDocs platform. The integration evaluation based itself on three tests to analyse its capabilities, namely the qBox module connection to the qDocs platform, the document request and approval process and the ability to change dataset configurations. The evaluation yield positive results that allow to conclude that the qBox works as a proof of concept and the qDocs is ready for basic curator integration via the qBox.

Keywords

E-Government; Interoperability; Public Administration; Document Automation.

iii

Resumo

A interoperabilidade e´ um aspecto importante dos sistemas de informaçao˜ complexos que precisam de interagir e ser integrados com uma infinidade de outros sistemas e serviços. Novas normas de interoperabilidade e estruturas estao˜ a ser promovidas, e nesta tese discutimos algumas delas no ambitoˆ dos sistemas de eGovernment e de automaçao˜ de documentos. Esta tese explora aspectos de integraçao˜ do qDocs, uma plataforma de automaçao˜ de documentos centrada no cidadao.˜ qDocs tem como obje- tivo disponibilizar uma facil´ gestao˜ de documentos burocraticos´ (por exemplo, cartoes˜ de identificaçao,˜ formularios,´ certificados) por varias´ organizaçoes˜ e facilmente dispon´ıvel para os cidadaos.˜ Um dos principais desafios da proposta que e´ a base desta tese e´ a correta integraçao˜ dos sistemas dessas organizaçoes˜ com o qDocs porque eles precisam recolher/fornecer dados de/para os documentos. A soluçao˜ apresentada, desenvolvida e avaliada nesta tese e´ denominada qBox, que e´ uma componente de software a ser integrado no ambiente de cada organizaçao,˜ que suporta tanto os requisitos de interoperabilidade como de segurança. A qBox foi projetada com um forte foco em conjuntos de dados de documentos e as suas especificaçoes,˜ para ser desenvolvido como um modulo´ independente chamado qBox e integrado com a plataforma qDocs. A avaliaçao˜ da integraçao˜ baseou-se em tresˆ testes para analisar as suas capacidades, nomeadamente a conexao˜ do modulo´ qBox a` plataforma qDocs, o pro- cesso de pedido e aprovaçao˜ de documentos e a capacidade de alterar as configuraçoes˜ do conjunto de dados. A avaliaçao˜ obteve resultados positivos que permitem concluir que o qBox funciona como uma prova de conceito e o qDocs esta´ pronto para uma integraçao˜ basica´ do curador atraves´ do qBox.

Palavras Chave

E-Government; Interoperabilidade; Administrac¸ao˜ Publica;´ Automac¸ao˜ de Documentos.

Contents

1 Introduction 1 1.1 Motivation...... 3 1.2 qDocs...... 4 1.3 Problem...... 4 1.4 Proposal...... 4 1.5 Research Methodology...... 5 1.6 Dissertation Structure...... 5

2 Related Work 7 2.1 E-Government...... 9 2.2 ISA2 ...... 10 2.3 Document Automation...... 11

3 Development Tools and Environment 15 3.1 Development Environment...... 17 3.2 Development Technologies...... 18 3.2.1 IdentityServer4...... 18 3.2.2 SPA...... 19 3.2.3 Web API...... 19 3.2.4 ASP.NET Core...... 19 3.2.5 Angular...... 20

4 qDocs Overview 21 4.1 General Architecture...... 23 4.2 Security...... 24 4.2.1 Privacy...... 24 4.2.2 Conﬁdentiality...... 25 4.2.3 Authentication and Authorization...... 26 4.3 Document Evaluation Process...... 26 4.3.1 Document Request...... 26

vii 4.3.2 Document Request Approval...... 27 4.3.3 Document Consultation...... 28

5 qBox Design and Development 31 5.1 qBox Architecture...... 33 5.2 qBox Domain Model...... 34 5.3 Development Process...... 35 5.4 qBox Solution Implementation...... 37 5.4.1 qBox Development...... 37 5.4.1.A qBox/Citizen...... 38 5.4.1.B qBox/Curator...... 39 5.4.1.C qBox/Curator Data Manager...... 40 5.4.1.D qBox/qBox...... 40 5.4.2 qDocs - qBox Integration...... 40

6 Evaluation 43 6.1 qBox Connection...... 45 6.1.1 Services Configuration (Curator Data Manager)...... 45 6.1.2 Templates Configuration (Curator Templates Editor)...... 47 6.2 Document Request and Approval...... 48 6.2.1 Document Request (Citizen)...... 48 6.2.2 Document Approval (Curator Templates Manager)...... 49 6.2.3 Document Consult (Citizen)...... 50 6.3 Changing Dataset Configurations...... 52 6.3.1 Creating new Document Specification...... 53 6.3.2 Adding Attributes to Existing Document Specification...... 53

7 Conclusion and Future Work 55 7.1 Conclusion...... 57 7.2 Future Work...... 58

A qBox API Documentation 63

viii List of Figures

4.1 qDocs general architecture model (archimate diagram) - adapted from [1]...... 24 4.2 Example of the multiple roles a citizen entity can have - adapted from [1]...... 25 4.3 qDocs BPMN model demonstrating the alignment of the processes...... 26 4.4 qDocs and qBox interactions on for the task “Request/Create New Document” (represented in BPMN)...... 27 4.5 Example of qDocs and qBox interaction on for a Curator Document Approval, represented in BPMN...... 28 4.6 Example of qDocs and qBox interaction on for a Citizen Document Access, represented in BPMN...... 29

5.1 qBox ArchiMate design of interaction...... 33 5.2 qBox base Domain Model...... 34 5.3 qBox Document State Diagram...... 35 5.4 Cumulative Flow Chart from Azure DevOps...... 36

6.1 Create Service Interface...... 46 6.2 View Methods Interface...... 46 6.3 Edit Method Interface...... 46 6.4 Form Objects Interface...... 46 6.5 Edit Form Object Interface...... 47 6.6 Form Object Default Value Interface...... 47 6.7 Edit Template Content Interface...... 47 6.8 Edit Template Metadata with Associated Output Template Interface...... 47 6.9 Create New Document Save and Submit Interface...... 48 6.10 Document Request After Submission Interface...... 49 6.11 Evaluation Details Interface...... 49 6.12 Pending Documents Interface...... 50

ix 6.13 Document Evaluation Interface...... 50 6.14 Rejected Document Evaluation Details...... 51 6.15 Approved Document Evaluation Details...... 51 6.16 Approved Declaration Document...... 52 6.17 Check for Updates Interface...... 52 6.18 Result after checking and finding no updates...... 52 6.19 Creation of new Document Specification...... 53 6.20 Result after checking and finding a new Method...... 53 6.21 Creation of existing Document Specification with new Attribute...... 54 6.22 Result after checking and finding an existing Method with new fields...... 54 6.23 The new Fields present in the Method...... 54

x List of Tables

5.1 qBox API Endpoints Summary Table (the extensive table can be found in AppendixA)... 38 5.2 Table Describing the Endpoints of the Citizen Interface...... 38 5.3 Table Describing the Endpoints of the Curator Document Manager Interface...... 39 5.4 Table Describing the Endpoints of the Curator Data Manager Interface...... 40 5.5 Table Describing the Endpoints of the qBox Interface...... 40

xi xii 1 Introduction

Contents

1.1 Motivation...... 3

1.2 qDocs...... 4

1.3 Problem...... 4

1.4 Proposal...... 4

1.5 Research Methodology...... 5

1.6 Dissertation Structure...... 5

1 2 The importance of understanding the need and challenges of E-government is key to grasping the concept of a new document automation platform called qDocs. qDocs is a web document automation platform intended to work on any device to provide a seamless interaction between citizen and administration services, making bureaucratic documents citizen centric [2]. Document automation is an approach that supports the management of document templates, data fields, and documents. Document automation uses such templates and data fields, and relies on data collected from the user or from external data sources to dynamically produce or assembly final documents [3]. On the other hand, E-Government is an emergent public administration approach, strongly influenced by digital technologies, where accessibility and easy information access is becoming common [4]. How- ever, to achieve such goals, interoperability across multiple platforms and services, shall be considered. For example, European Commission defined the ISA2 [5] framework aiming for a single digital market across all the EU. As a platform that may handle sensitive information (like citizen’s personal data), qDocs has security in its core, as it creates documents only upon request, on the citizen’s device, with data provided and curated by multiple organizations, known as curators. qDocs aims to serve two main entities, the citizen and the curator. The citizen accesses the platform to request, consult and share documents; and the curator to manage and define the information of those documents available and evaluates the requests. This thesis proposes to explore all these concepts, namely providing a detailed explanation of the qDocs with focus on discussing its interoperability aspects, as well as the identification of the problem on the interoperable integration of this platform and the implementation and evaluation of the proposed solution, the qBox.

1.1 Motivation

Modernizing the public sector is an important step in the fast-growing digitized world, where the government can be seen as bureaucratic and old fashioned and not providing the necessary services in a convenient and transparent way. The efforts to transition to a new era of government-citizen interaction are being made worldwide and Portugal is no exception, and as Computer Science Engineers, the ones that engineer the transition to this way of commodity in users life’s, it is our challenge to create a user centered approach, bringing to them the Public Services, and not the other way around. Converting these services into a citizen centered paradigm is very important to improve the experience of the citizens in interacting with government services, such as health care, social services and

3 education, many of them mandatory, like tax and customs or civil registration, and used many times during a lifetime. Request, access and share official documents is one important and common interaction between the citizen and the government, and with this project that interaction aims to be as efficient, secure and easy as possible. This is achieving an important part of a larger goal of bringing the Portuguese services to more modern and efficient processes by connecting people and public services.

1.2 qDocs

This new platform envisions the idea of allowing citizens to access and deal with issues regarding administrative services from their own technological environment, such as their home computers or smartphones. qDocs aims to be a document provider, using a cloudbased system and having security concerns at its core. This on demand, real time system with standard legal value is compatible with existing systems, being able to connect to existing platforms with database sharing solutions while allowing for the entity to maintain the system standards. It has an approach centered in the citizen with multi curators managing document templates and sharing information for the materialization of new documentation. The main goal is for citizens to request, access and share electronic documents while acting as a wallet of documents, with search and management capabilities. The qDocs platform supports the interaction of three different entities: the curator, the citizen and the qDocs operator; and also integrates an interface to a component integrated in the curator system to enable data communication from the curator to the platform, called qBox.

1.3 Problem

The problem we propose to solve is the integration of the qDocs platform with the curators with a solution general enough to be able to be integrated in any entity with a standard approach, using interoperability norms and frameworks, while having security concerns at its core. This shall be made through the analysis of the platforms and the interoperability panorama, as a method of research for the design and prototyping a solution, with the implementation in an application as a demonstration as a proof of concept, with security concerns at its core.

1.4 Proposal

The proposal presented in this document is the implementation of an interface between the Curator and the qDocs platform. “Most information systems (including ERPs) increasingly offer (...) easier ways of

4 integrating with other information systems” [6] and because of that integrating with the curators system is a viable option, ensuring through this interface the security and standardization of the data transferred between entities. This proposal is detailed in Chapter5 of this document as a solution, and it is called qBox, an intermediary application to manage the data between the curators and the qDocs platform, with a focus on security and data availability. The goals proposed to achieve are the development of this module and its integration with the existing qDocs platform, with focus on X main aspects, namely the conﬁguration of services with automatic generation of relevant data objects; the availability for document request with secure data delivery; the availability of request data for evaluation by curator entities; the automatic generation of documents based on existing data; and the ability to provide updates regarding dataset conﬁgurations.

1.5 Research Methodology

This dissertation follows a five step methodology of Action Research [7], namely: (1) Identification of problem area, where the topic of this dissertation is introduced by the identification of the problem proposed to be solved; (2) Collection and organization of data, where the state of the art as well as the current platform state is studied, with an approach to e-government and document automation and a detailed study of the qDocs platform; (3) Interpretation of data, where the information gathered is interpreted to devise a solution, described and planned with the architecture models of the qBox; (4) Action based on data, where a solution is implemented with the technologies described; (5) Reflection, where results from the solution are interpreted and conclusions are taken from it with the evaluation through three usability tests. This process started with steps 1, 2 and 3 during the development of the Master Project, from September of 2018 to February of 2019, and was concluded during the Master Thesis with steps 4 and 5, from February 2019 to September 2019.

1.6 Dissertation Structure

This dissertation is organized as follows:

• Chapter2: Related Work reviews the current state of the art with extensive research, providing a background for this dissertation;

• Chapter3: Development Tools and Environment provides an insight of the tools used in the development of the solution in this dissertation as well as a study of the technologies used;

5 • Chapter4: qDocs Overview details the existing platform on which this dissertation bases itself;

• Chapter5: qBox Design and Development presents the model and architecture of the qBox as the proposed solution and describes its implementation and integration;

• Chapter6: Evaluation analyses the solution implemented and evaluates it in three main tests;

• Chapter7: Conclusion and Future Work is where the main conclusion of this work is presented as well as perspectives for future work.

6 2 Related Work

Contents

2.1 E-Government...... 9

2.2 ISA2 ...... 10

2.3 Document Automation...... 11

7 8 To have a broader perspective of the interoperability topic in E-Government we shall review some related work. Interoperability is an important concept in this work that aims to integrate the qDocs platform with external entities. ISA2 is an European initiative to standardize the interoperability inside the European Union and aims to boost the modernization of Public Administrative systems and provides guidelines for interoperability inside the European panorama. This chapter also introduces Document Automation as a concept, as well as a study on some document automation platforms, focused on the integration aspect, the same aspect to be studied on the qDocs.

2.1 E-Government

E-Government (or Government 2.0, or simply e-Gov) is an emergent paradigm of society’s public services [4]. E-Government’s goal is to use information technology to improve and provide better services in the public sector, making them user-centered, with a more interactive approach, providing improved communication and reduce general costs [8]. This involves balancing human and machine approaches to solve both entities problems, scale the government services creating a bigger impact and identifying new solutions, recognizing the unique needs of the individuals to create user centered mass or personalized services, using the public sector as a platform to test ideas in an experimental government approach and not being afraid of breaking the standard bureaucracy and the norms in the public sectors [8]. Ultimately, the relationship between citizens and government is going to change with the implementation of these ideas [9], allowing for deeper collaboration between the two entities [10]. For this, strong leadership willing to make the change is a key factor, and is currently one of the main obstacles, as the current leadership is excessively bureaucratic in this matter. Also important is the involvement of the citizens, as end users, during the development and operation of these systems. The goal is to make the citizen’s life easier and to build practical and simple systems, captivating the user’s interest. However, the materialization of these ideas are not easy and, adding to the problem, there are the structures and organizations of governments, which varies drastically among countries and administrations, makes this a difﬁcult project worldwide. The fear of failure exist, however some governments are tackling this problem with new and innovative methods [11]. The E-Government implementation is already ongoing, with most countries having some sort of service available online, such as tax paying (the most common example) some countries, such as Estonia, are leading the change with many services available, such as online voting, digital drug prescriptions, electronic certiﬁcates and much more [12]. The reliability and comfort of these services to the citizen has a positive impact on the perception of failures, such as the time when in 2007 many of Estonia’s e-services got hacked, where after the news of the hacking, users considered the service as still being safe, and trusting the modernized government to act on the exposed failure to make the system even

9 safer [13]. Estonia had the opportunity of building a government in the modern era from scratch, whereas the majority of other countries have to build on top of already existing services, involving a major reshape of the internal processes in most of the cases. This reshaping, according to some studies [14], would occur after enabling interoperability and the basis of the technology standards and policies, in a second phase where administrative procedures would be aligned with the technical systems, where enterprise architecture approach would be a valuable tool. According to Guijarro, interoperability can be classified at two levels [14]: At the first level, interoperability provides the basis and policies of the technology and can be further divided in two sub-levels: (a) Technical, involving the technologies necessary to exchange data reliably between systems; and (b) Semantic, involving the policies that ensure the homogeneity of the information flow. At a second level, interoperability shall involve the general alignment of the administrative processes between organizations with the information systems at its core. In general, interoperability can be defined as the organization’s ability to share data and information in order to have mutual benefits, using administrative processes oriented to interaction [15].

2.2 ISA2

The EU Member States are currently converting their public administrations to a digital form [5]. Interop- erability plays a key role in this transformation as it allows for administrative entities to share information with the citizens and provide public services digitally, such as, as stated in [5]: (i) Legal issues, e.g. by ensuring that legislation does not impose unjustified barriers to the reuse of data in different policy areas; (ii) Organizational aspects, e.g. by requesting formal agreements on the conditions applicable to cross-organizational interactions; (iii) Data/semantic concerns, e.g. by ensuring the use of common de- scriptions of exchanged data; technical challenges, e.g. by setting up the necessary information systems environment to allow an uninterrupted flow of bytes. ISA2 is the second iteration of ISA (Interoperability Solutions for European Public Administrations), an European Commission initiative as a solution for the interoperability strategy across the European Union. ISA2 provides specific orientations to public administrations on how to manage interoperability activities, relations between organizations and processes supporting digital services while ensuring that the legislation does not compromise such efforts. The public sector represents around 20% of the European Union’s GDP and plays an important role as an employer, regulator and services provider in the Digital Single Market [16], and as such, this guidance is very important. This idea behind ISA2 follows the vision of: “Public administrations should provide key interoperable user-centric digital public services to businesses and citizens, at national and Union levels, supporting the free movement of goods, people, services and data throughout the Union” [5]. The main focus of our research with the qDocs platform, is

10 perfectly aligned with this vision supported by the Member States and public administrations. This ISA2 initiative has five main focus areas [5]: Ensure governance, coordination and sharing of interoperability initiatives: There is a need for governance and coordination to materialize interoperability within public administration. As such there are two roles to be followed by the Member States and the Commission. First, to govern, coordinate and share all interoperability initiatives at national and Union levels in view of ensuring that public administrations follow the principles and recommendations of the European interoperability framework. Second, to foster better cooperation across all levels of public administrations in the Union and break down the remaining organizational and digital silos. Develop organizational interoperability solutions: There must be an alignment of the administrative processes between organizations, providing a flow of information between the public administrations in the EU, benefiting the citizens. Engage stakeholders and raise awareness on interoperability: Promote initiatives showing that interoperability is a rentable investment and it satisfies the user needs. For this the results of implementing the recommendations from the European interoperability framework should be measured and broadcasted, as well as promoting this framework and its solutions. There should always be a consideration for the citizens and companies that are the consumers, involving them in an evaluation and analysis of the product for its own evolution. Develop, maintain and promote key interoperability enablers: A solution for the standardization of the data handling between organizations should be defined, developed and promoted to facilitate interoperability. Develop, maintain and promote instruments that support interoperability: There are already some tools to be used in the support for interoperability that should be promoted, as well as the development of new ones such as interoperability reference architecture, identification of legislation regarding interoperability and IT and the share and reutilization of IT solutions across European administrations. The need to update the interoperability framework that exists in Europe is big, so that divergence of approach by the member states working solo cannot become a reality, as incompatible solutions would increase digital fragmentation across EU.

2.3 Document Automation

Document automation is an approach, with increasing popularity in areas such as public administration [17], that supports the management of document templates, data fields, and documents, by using such templates and data fields, and relying on data collected from the user or from external data sources to dynamically produce or assemble final documents. They intend to replace the traditional documents

11 filled by the user with auto filled document templates [3]. Some benefits result from document automation, such as a more cost effective solution [18], a more efficient way to process data [19], a lower account of human errors [10], as well as the creation of new documents with recycled information [20]. According to a study in healthcare document transformations in the PICASSO Interoperability Plat- form [21], with the help of TAXI, a tool that generates XML instances from a given XML Schema, a technology was experimented following four steps, after populating the database with meaningful values: a user specifies an XSL stylesheet and a target XML Schema; TAXI picks each instance in sequence, transforms it according to the rules in the stylesheet, and stores the output XML instance in a file; TAXI validates the output instance against the target XML Schema; finally, a log is generated that describes which of the transformed instances were conforming and which were not, and details the validation errors for the non-conforming ones. This allowed to understand that to achieve interoperability with document automation is important to guarantee a base data format, the reliability of the data and the trustworthiness of the applications connected and using that data. This, alongside with a populated database are important aspects as semantic interoperability is in increasing demand by information systems [21]. To understand how these document automation tools are integrated with their client’s services, a few platforms were studied. HotDocs is a document automation platform that manages user data and provides document assembly services [22]. HotDocs can be integrated into business applications through the HotDocs Server API, both to render HotDocs interviews and to assemble documents. The HotDocs interviews usually are embedded into the client’s document creation application, or may be presented to the user as a pop-up, both via the API. The data from these interviews is stored in the business application process, and can be used via the API for document generation. This means that the data relative to the documents is sent from the client to the platform, through the Web Service API, where it is stored. After the document assembly is complete it can be either attached to the process in progress or it can be saved as a document in a repository for later reference [23]. As for SmartDocuments, also a document automation platform, document templates are centrally created and the data of the user is automatically transferred from the specialist application to the document template, through a data retrieval module that can be integrated with the client platform. When finalizing a document creation process, SmartDocuments only asks for the missing information and automatically creates all the required documents. These can then be sent by e-mail and centrally archived [24]. In the case of the document automation platform Templafy, it integrates with document creation plat-

12 forms such as Microsof Ofﬁce and G-Suite with the existing document management software, through an Add-On. It also integrates with customer relationship management systems to get customer information into business document templates. The organization’s assets and templates are stored in the cloud while also supporting centralized storage systems, and can be managed via an external web interface or via the integration of a content management system [25].

13 14 3 Development Tools and Environment

Contents

3.1 Development Environment...... 17

3.2 Development Technologies...... 18

15 16 This chapter details the environment, tools and technologies studied and used in the development process.

3.1 Development Environment

The base for the understanding of the technology used in the development is a course on Microsoft’s ASPNET Core for the back-end and Google’s Angular for the front-end, by Neil Cummings, instructor at Udemy [26], that implements an application to provide a learning experience with the languages, technologies and methodologies. It covers the following topics [26]:

• Setting up the developer environment;

• Creating the ASP.NET Core WebAPI and the Angular app using the DotNet CLI and the Angular CLI;

• Adding a Client side login and register function to our Angular application;

• Adding 3rd party components to add some pizzazz to the app;

• Adding routing to the Angular application and securing routes;

• Using Automapper in ASP.NET Core;

• Building a great looking UI using Bootstrap;

• Adding Photo Upload functionality as well as a cool looking gallery in Angular;

• Angular Template forms and Reactive forms and validation;

• Paging, Sorting and Filtering;

• Adding a Private Messaging system to the app;

• Publishing the application to both IIS and Linux;

The course main task is to build a fully functional and ready to deploy dating site as an example of a possible application of these technologies. As a student of this course, there is a slight learning curve, as in any language, platform or framework, or all of them, as it is in this case. The previous knowledge on Computer Science and programming skills is an important aspect to be considered, as it provides some comfort and know how on the manipulation of the languages. Professional experience, such as in mobile applications development is an added advantage in the development and integration of a back-end and front-end applications in the same

17 scope and environment, as it was not addressed in the academic course in the same context, but rather divided by thematic. Besides the languages of C# and TypeScript, as well as the previously known languages of HTML and CSS, and the ASP.NETCore1 and Angular2 frameworks, this course gives the opportunity of working and getting to know the development environment of Visual Studio Code3, by Microsoft, its capabilities of working in both front-end and back-end in the same environment, capabilities of debugging and also the capabilities of integrating plugins that help making the environment more suitable for this kind of project. Postman4 is one of the these tools used during the duration of the course, an application suitable for back-end testing, such as posting or getting speciﬁc requests to ensure the proper functioning of the code developed, without a working User Interface. Also used is DB Browser5 for SQLite6, that allows the monitorization and management of the databases developed and used in the application. All of this is taken as a preparation and familiarization of the development environment used to develop a functional solution for the qDocs project.

3.2 Development Technologies

Different technologies and tools had to be studied in order to be used in the development stage, regarding implementation, security and testing. Those tolls and technologies are detailed in this section.

3.2.1 IdentityServer4

IdentityServer4 is a framework that provides authentication capabilities for ASP.NET Core. It provides the applications with the following features, namely [27] (i) Authentication as a Service, (ii) Single Sign- on / Sign-out, (iii) Access Control for APIs, (iv) Federation Gateway, (v) Focus on Customization, (vi) Mature Open Source and (vii) Free and Commercial Support. Resource protection and authentication are important factors for all layers of software. This framework allows for the outsourcing of these security functions to their security token service. Authentication. This allows for the platform to identify the user and giving him access of the data he is allowed to. There are a few authentication protocols commonly used, such as SAML2p or WS- Federation, but this framework uses OpenID Connect for it is seen as the one with the most potential for

1https://dotnet.microsoft.com/ 2https://angular.io/ 3https://code.visualstudio.com/ 4https://www.getpostman.com/ 5https://sqlitebrowser.org/ 6https://www.sqlite.org/index.html

18 modern applications. API Access. This framework uses OAuth2 protocol for token management and distribution, cen- tralizing authorization and authentication, reducing complexity in client application and API through the delegation of user identity. OpenID Connect and OAuth 2.0. OpenID Connect is an extension built on OAuth 2.0, and as such they share a same base and combine authentication and API access, the two main issues in security. The implementation and optimization of these protocols resulted in the IdentityServer4, targeting the security of native and web applications. This framework works on top of ASP.NET Core applications containing login page and activities needing authentication, providing the middleware to add the protocols that ensure the security of the application.

3.2.2 SPA

The course uses the Single Page Application (SPA)7 approach for the front-end solution. This enables a smooth interface and an experience resembling desktop applications, as it updates dynamically to user requests by dynamically loading the resources needed to update the page, without the need to reload it. This approach is supported by the Angular framework, working with bidirectional UI data binding and the browser HTML compiler, as well as a router to interact with the server state.

3.2.3 Web API

This course adopts Web APIs that use request-response endpoints publicly exposed through HTTP and expressed in JSON. These endpoints are static URI’s referring to the resources that can be accessed, through GET, POST, DELETE HTTPS actions and passing information with JSON. These can be accessed by the client through a web browser or an HTTP client app.

3.2.4 ASP.NET Core

ASP.NET Core8 is the Microsoft cross-platform framework for internet-connected applications [28]. It is used as a tool to build web app’s back-end. Data Transfer Objects (DTOs)9 are used to interact with the database, created from these objects through migrations. To establish HTTP endpoints Controllers are used, deﬁning the URI’s associated with the resources that are provided.

7https://en.wikipedia.org/wiki/Single-page application 8https://dotnet.microsoft.com/ 9https://en.wikipedia.org/wiki/Data transfer object

19 3.2.5 Angular

Angular is the Google cross-platform framework for front-end development [29]. It is TypeScript based, a language by Microsoft that is converted to JavaScript for browser compatibility [30], and allows easy manipulation of HTML and CSS. Routing is used as a way to link requested URI’s to the correspondent components and passing on information through resolvers. To protect and inform the user of possible mistakes and malfunctions guards are used as a veriﬁcation method.

20 4 qDocs Overview

Contents

4.1 General Architecture...... 23

4.2 Security...... 24

4.3 Document Evaluation Process...... 26

21 22 This Chapter is a study on the qDocs platform, by explaining its concept and key features and detail- ing its architecture. qDocs is a “citizen-centric and multi-curator automation document platform” [31] that allows citizens to participate and be engaged with bureaucratic processes and issues regarding administration services, from their own computers or smartphones. qDocs aims to be an electronic document broker, using a cloud-based system and including security features by design and by default [1]. This on demand, real time system aims to be compatible with existing systems, by being able to connect to existing platforms with database sharing solutions while allowing for the entity to maintain the system standards. qDocs provides an approach centered on citizen, with multiple curators (entities that provide services to the citizens and have data and documents regarding the service) managing templates and sharing information for the materialization of dynamic documents. The main goal is for citizens to request, access and share electronic documents while acting as a wallet of documents, with searching and managing capabilities.

4.1 General Architecture qDocs is a citizen-centric platform in a multi-curator ecosystem [1]. It has the ability to create documents by assembling information maintained or curated by different curators. The goal is to allow citizens to request, access and share electronic documents. It also acts as a wallet of bureaucratic documents, such as the ID, Drivers Licence or Certifications. where the citizen can search and access them by document type, life event or curator specific classification schema. As suggested in 4.1, qDocs supports the integration of three key actors: the curator, the citizen and the qDocs operator. It also integrates a software component (that shall exist in each curator domain) to enable data communication from the curator to the platform, called qBox. The qDocs/Citizen application is used by each citizen, and provides the following features [2]: Ac- cess and management of his documents through the wallet/folder metaphor, where the citizen can have multiple roles as shown in Figure 4.2; Search and browse documents by classifiers defined by the respective Curators, namely by life events, document type, curator-specific classification schema; Share documents (using dynamic keys) with other users, being possible to limited in time these shares; Fill and submit input documents, feeding Curator forms; Integration with payment systems, allowing integrated document issuance fee collection; Hands-free authentication mechanism using qDocs Identity Token; Several levels of legally binding authentication, based on official systems ranging from ID smart cards to SMS based authentication methods (depending on integration with official mechanisms already in place); Authenticity validation system for critical identification documents (e.g., ID, driver license); Real time monitoring of activity, access to comprehensive dashboards and activity logs, including usage by

23 Figure 4.1: qDocs general architecture model (archimate diagram) - adapted from [1]. third parties. The qDocs/Curator application is used by different users (with different specific roles) defined at each curator level, and shall offer the following features [2]: Manage curator-specific users and roles assignment; Manage protocols and contracts with other Curators; Manage and configure internal and external data services (DataServices); Manage and configure merge fields and user interface objects (FormObjects, Snippets); Manage and configure document templates (DocumentTemplates); Monitor performed activity and transactions. The qDocs/qBox application is a bridge between qDocs and the curator’s operational system. Each curator needs a qBox to manage data transfers and handle qDocs requests.

4.2 Security qDocs has a high focus on security. The platform has four main security concerns, namely privacy, conﬁdentiality, authentication and authorization.

4.2.1 Privacy

The data of each curator is stored and kept in the curator’s qBox and it is only accessed by qDocs on request, dynamically merging such data with the involved (document) template elsewhere, generating a

24 Figure 4.2: Example of the multiple roles a citizen entity can have - adapted from [1].

document in real time, and only in the citizen’s device, without storing any critical data. Alongside with these requirements, the communications follow a customized Kerberos protocol and are https encrypted, and the system relies on standard authentication processes, with the use of login with username and password.

4.2.2 Confidentiality qDocs has two integration approaches when it comes to the integration with the curators: (1) Document Template Management and (2) Document Data Management. Concerning Document Template Man- agement, qDocs is responsible by keeping track the connections between the documents and the data, as well as the keys and links used to access them. Once a document is created the citizen who owns the document has persistent access to the information associated with it, and he can share it with people or curators through keys or links. On the other hand, concerning Document Data Management, document data comes from dynamic user filling and from one or multiple curated data sources. This allows for documents to be filled automatically in part or totally. The content of the document must be mapped by the curator, providing a source and a destination, so it can be collected with shared databases between systems. The data present in the curator’ systems is never accessed, edited or manipulated by the qDocs platform itself, being the responsibility of the curators to ensure the correct data in the documents, as well as collecting, maintaining and making it available (this is the reason this organizations are named as “curators”).

25 4.2.3 Authentication and Authorization

Regarding authentication, qDocs supports login based on technologies identical to the ones seen with the IdentityServer4 framework as seen in subsection 3.2.1, to ensure the proﬁle authentication, granting access to the logged in user of his data and preventing the access to other contents, as well as a safe token management to handle requests and information ﬂow.

4.3 Document Evaluation Process

To further explain and discuss the adoption of qDocs we introduce a simple example where a student requests and gets his habilitation certificate from an university. So, in this example the curator is the University X, the citizen is the student and there are two templates: (i) Habilitation Certificate Request, this is an input document, and (ii) Habilitation certificate, that is an output document. Regarding common user interactions, qDocs supports interaction patterns like the choreography suggested in the 4.3, with the sequence of the following processes: (1) Document Request (by the Citizen); (2) Document Request Approval (by the Curator Documents Manager); and consequently (3) Document Consultation (by the Citizen).

Figure 4.3: qDocs BPMN model demonstrating the alignment of the processes.

4.3.1 Document Request

The ﬁrst process (Request/Create New Document) is started by the citizen and is provided by the qDoc- s/Citizen application. This request is processed by the qDocs/Server in coordination with qBox, the part of the platform responsible for the integration with the curators information. As suggested in Figure 5

26 qBox generates an access key which is sent to the qDocs/Citizen alongside with the template generated by the qDocs/Server. With the use of this key, the qDocs/Citizen retrieves information directly from qBox to fill the template with the necessary information, to send it to the citizen, who provides its own information as a part of the document request. In the end, the information is saved in the qBox platform and the qDocs/Server is warned about the end of the process. In our example, the student accesses the qDocs platform and, after logging in with the required authentication method, fills a form with the fields of the Habilitation Certificate Request, such as the name of the course. The student then simply saves and submits this request and awaits for the result (see 4.4).

Figure 4.4: qDocs and qBox interactions on for the task “Request/Create New Document” (represented in BPMN).

4.3.2 Document Request Approval

Following the citizen’s request the curator needs to approve it. To do so, the curator interacts with the qDocs/Curator interface, following a similar pattern to the one seen in the citizen’s request process to get the template from qDocs/Server, key and information from qBox. Then, the curator submits his evaluation (e.g. approve or reject the request), that is passed on to the qDocs/Server, to notify the user of the evaluation result, and qBox to store this information (see 4.5). In our example, a university manager shall have access to all documents pending for approval, namely requests for Habilitation Certificate. In case of document approval it is created an habilitation certificate with the necessary information such as student name, grade and course. In addition the student is notified of the decision in either outcome.

27 Figure 4.5: Example of qDocs and qBox interaction on for a Curator Document Approval, represented in BPMN.

4.3.3 Document Consultation

Finally, the citizen can access the document requested, if approved by the curator’s manager. To do so, the process follows the same pattern as the previous ones, to get access to the template, access key and data, in order to dynamically assemble the document and deliver it to the citizen (see 4.6). In our example the student accesses the platform again and has full access to the document in his own documents area. Furthermore, after the document being made available, the student can now share it with other entities or even send it to be stored in third party platforms. These processes are the base guide to the development of the solution as they identify the main entities and interactions. They are the citizen and the curator, that access the same data from qBox in an independent way, and their actions result in the three processes described, namely the Request/Create New Document, that can be subdivided into two sub processes to simplify, that are the Request of the Document, which involves its edition, and the submission of the Document, that creates the new Input Document for the approval request. The second process is the Curator Approval, and ﬁnally the Document Access where the citizen can see the Output Document generated by the curator, in case of the document being approved, and the Input Document with the evaluation details, for both approved and rejected documents.

28 Figure 4.6: Example of qDocs and qBox interaction on for a Citizen Document Access, represented in BPMN.

29 30 5 qBox Design and Development

Contents

5.1 qBox Architecture...... 33

5.2 qBox Domain Model...... 34

5.3 Development Process...... 35

5.4 qBox Solution Implementation...... 37

31 32 In this chapter we gather the information discussed in the previous sections in order to design and propose a solution to the problem stated in the beginning of the document. This is done by evaluating two core parts of the platform, the qDocs and its interoperability and the proposed solution of the qBox, to integrate in the curator, and its interoperability with all the entities involved in the environment.

5.1 qBox Architecture qBox is the standard interface through which qDocs communicates and retrieves data from the curator to provide data to the citizen requests. qBox is to be integrated with the curator system, allowing for data transfer with it, and providing interfaces to communicate with the citizen and curator in each speciﬁc document [31]. As suggested in Figure 5.1 qBox is integrated in the curator environment, where it connects to the curator application to keep the databases in sync by exchanging information with the curator application via the qBox/ExternalApp interface. From here it also communicates with the qDocs server through the qDocs/qBox and qBox/qDocs interfaces, for security and state tracking, as detailed in the examples of Section 4.3. It also connects directly to both the citizen and the curator environments to answer requests without the need to go through the main qDocs serer, relieving its load and keeping information decentralized from the main server.

Figure 5.1: qBox ArchiMate design of interaction.

This approach aims to provide to each curator a standard way of integration with the qDocs plat-

33 form. As such, qBox is the middleman between the curator’ systems and qDocs itself, being a data intermediary that ensures the security and homogeneity of accessing the data.

5.2 qBox Domain Model

As suggested in 5.2, regarding the internal structure of qBox, any User is identified by an UserID and either owns Documents in the role of Citizen, or takes actions over said documents (Generate, Evaluate). Documents can be Input or Output documents: Input documents are used to get data and related requests from citizens (e.g. forms, questionnaires) and are evaluated by the curator, who provides public and private evaluation commentaries; on the other hand, Output documents are used to present data to the citizens (e.g. ID cards, Certificates, field forms) and are generated by the curator with the approval of the respective input document.

Figure 5.2: qBox base Domain Model.

Documents can be in one of seven states (see 5.3): Five for the input documents: Editing, when the citizen creates a new input document; Pending, when the citizen submits the document for evaluation; Approved, if the curator approves the document; Rejected if the curator rejects the document; Archived if the citizen archives the document; And two for the output documents: Active, when the document is generated; Disabled, when the citizen disables the document. The Datasets are directly associated to each Document, as well as to a number of Attributes, that keep the Document content data. The Dataset Specification is associated with Dataset Attribute Spec- ifications, which define a Dataset and its Attributes, respectively, and contemplate the use type of said

34 Document, either Input or Output.

Figure 5.3: qBox Document State Diagram.

5.3 Development Process

The development of the solution was based on the SCRUM agile methodology [32]. Three different dissertations had the same qDocs base subject, and as such the three members worked in a common environment, in a similar way to a team project, with the team being composed of the three members in the development end, managed by the thesis’s advisor as a Product Owner and Project Manager, as well as the thesis’s co-advisor, in a role similar to the role of a team leader. Daily scrum meetings were not used, these were weekly sprint meetings, to review and plan all the members weekly work. The sprint management was done using Microsoft’s Azure DevOps (see 5.4). The key deliverables are the qBox code, the qDocs code changes, the master dissertation and the extended abstract. The work was organized with User Stories, break-down into Tasks. In this case, it was divided into four User Stories, namely qBox: Deﬁne Data Schema & Create DataBase; qBox: Security; qBox:

35 Document Request; and qBox: API Integration.

1. qBox: Deﬁne Data Schema Create DataBase is the base of the work, where a data schema was designed, a skeleton was created as a foundation of qBox, with working controllers, and a database was created and populated. This process involved as well a lot of research regarding the operation of the legacy app, the Curator Simulator, used to simulate multiple curators for the qDocs platform.

2. qBox: Security focused on planning and implementing a token based authentication in the communication channels of the qBox API.

3. qBox: Document Request is where the core of the work is at, containing the development of the final controllers, the data control and verification, the creation of the documentation and most of the corrections and refinements of the code.

4. qBox: API Integration is the longest and most complicated of the User Stories. Here the goal is to integrate the qBox API (see ApendixA) with the qDocs platform, with four main tasks, namely Edit Document, Request Document, Approve Document and Consult Document. This phase involved a massive research on the qDocs platform, creating states and versions on qBox entities, solving issues with cross platform ids and a lot of reshaping in the qDocs platform. This phase is poorly documented and planned regarding the time of the tasks, due to the unpredictability of the duration of the extensive research and problem solving associated with each task. Also the task of writing a paper on the subject, to be submitted in a favourable moment, took place during this stage, that contributed to a signiﬁcant delay on the development.

Figure 5.4: Cumulative Flow Chart from Azure DevOps.

36 5.4 qBox Solution Implementation

The implementation of qBox as the solution of this project can be divided in two main parts, the first one consisting in the development of the qBox application and the second one being the integration of qBox with the qDocs platform. In this section both of these parts will be detailed on how they were approached, the implementation methods as well as the difficulties and step backs that took place, and how they were surpassed. This development has three main targets of usability, namely the Curator Data Manager (the one who manages the platform and is responsible for the services made available by the entity); the Curator Templates Manager (who is responsible for evaluating document requests thus generating official documents); and finally the citizen (that accesses the services made available through the platform, requests documents and consults them).

5.4.1 qBox Development

The qBox, as detailed throughout chapter5, is the solution to connect to the curators, ensuring security and standardization of the data. Implemented as a standalone app that is planned to run in the curator’s environment. The qBox is based on the Data Model detailed in Section 5.2 of this document, namely the Input Document, the Output Document, the Dataset, the Dataset Attribute, the Dataset Specification and the Dataset Attribute Specification, which make the six tables of the qBox database. These entities support the three basic communication channels, or endpoints, of the qBox API that were integrated directly with the qDocs platform: (1) the citizen; (2) the Curator Templates Manager; (3) the Curator Data Manager; as well as an additional channel, the qBox channel, that has the purpose of configuring the specifications of the datasets supported by the qBox directly accessing to the qBox, meaning that it is not integrated with the qDocs platform. These API Endpoints are summarized in table 5.1 and further detailed in AppendixA. In order to standardize communication and data transfer both within and to the outside of this application data transfer objects, or Dtos, were used. The Dtos used fulfill four different purposes. First the DocumentDto has the purpose of defining and providing information about the document specifications. Secondly the RequestDocumentDto is used to collect information from an interaction with the citizen to create a document. In third place, the EvaluateDocumentDto allows for information regarding the evaluation of the document by the Curator Templates Manager to be provided. Finally both the InputDocumentToReturnDto and the OutputDocumentToReturnDto arrange all the relevant data and information in the qBox to be sent to form an input document or an output document, respectively. Most of the processing of the application is made in the qBoxRepository, that acts as an application

37 Entities Citizen Curator Documents Manager Curator Data Manager qBox Consult Document Consult Document Request Pending Approval Get Dataset Information Create Document Speciﬁcation Consult Documents Consult Documents Request Pending Approval Consult Editing Document Aprove Document Request API Endpoints Edit New Document Request Reject Document Request Submit Document Request Archive Document Request Disable Document

Table 5.1: qBox API Endpoints Summary Table (the extensive table can be found in AppendixA). manager for the multiple interfaces.

5.4.1.A qBox/Citizen qBox/Citizen is the Controller regarding the interactions made by the citizen. It has seven endpoints available, being three regarding document consultation, one regarding document creation and three regarding changing the state of the document (see table 5.2).

Citizen Name Description Consult Document Returns the Output Document with the provided ID Consult Documents Returns all Output Documents of the Citizen making the request Consult Editing Document Returns the Input Document with the provided ID API Endpoints Edit New Document Request Sends an Input Document through a JSON ﬁle Submit Document Request Changes the state of the Input Document to Pending Archive Document Request Changes the state of the Input Document to Archived Disable Document Changes the state of the Output Document to Disabled

Table 5.2: Table Describing the Endpoints of the Citizen Interface.

The endpoints of document consultation are the Consult Document, that returns an output document, under the form of OutputDocumentToReturnDto. It expects an id to fetch the correspondent output document. The Consult Documents has the same basic process but returns an array with all the output documents of that citizen. The last consultation endpoints is the Consult Editing Document, that was added during the integration of the qBox with the qDocs, as this functionality came to be needed. It returns to the citizen an input document that is in editing state, so that the citizen can edit a document multiple times before submitting it for approval. The citizen has the ability of creating input documents, and this is made through the Edit New Docu- ment Request endpoint. Here the citizen is requested, through the interface of qDocs after the integration, to send information specified in a specific document format, through a RequestDocumentDto. The qBox then verifies all the information received, fist by checking if the dataset requested exists, by match- ing the name received in the Dto with the name of the dataset specification. Then it does the same with the attributes. In case the names do not match or the number of attributes is not the expected, the qBox sends back an exception with this information. Finally the qBox verifies the types of all the attributes received. It checks the type received in the JSON and compares it to the type expected for

38 that specific attribute. In case all is correct, and due to limitations in the Entity Framework not being able to store Object types, the content of all attributes is casted to a string format and saved with that type in the database, as StringedContent. When the document is requested for consultation the content is converted back to the type specified in the attribute specification. To submit the document, after the editing is complete, Submit Document Request is used. This expects the id of the document and changes the state of the input document as pending. This allows for the document to become unavailable for editing by the citizen but available for evaluation by the Curator Templates Manager. Finally the citizen can also archive input documents, with Archive Document Request, and disable an output document with Disable Document.

5.4.1.B qBox/Curator

This Controller is to be used by the Curator Templates Manager to perform two main actions, consulting pending documents and evaluating them (see table 5.3).

Curator Document Manager Name Description Consult Document Request Pending Approval Returns the Input Document with the provided ID Consult Documents Request Pending Approval Returns all Output Documents of the Curator making the request API Endpoints Approve Document Request Changes the state of the Input Document to Approved Reject Document Request Changes the state of the Input Document to Rejected

Table 5.3: Table Describing the Endpoints of the Curator Document Manager Interface.

To consult pending documents the Curator Templates Manager can use the Consult Document Re- quest Pending Approval endpoint that receives an id and returns the document with that id if it is an input document and is in the pending state. It returns it in the form of InputDocumentToReturnDto. The Curator Templates Manager can also use the Consult Documents Request Pending Approval endpoint that fetches all the input documents in the pending state associated to that curator entity, and returns them in an array. For the evaluation the Curator Templates Manager can approve or reject a document. For that, the endpoints Approve Document Request and Reject Document Request can be used. For these the curator must provide an EvaluateDocumentDto that has the information of the input document id, the Curator Templates Manager own id, and two evaluation comments, one to be seen by the citizen and another to be seen only by the curator entity. In addition, if the document is approved, by using the Approve Document Request endpoint, the Curator Templates Manager must provide, also in the EvaluateDocumentDto, a RequestDocumentDto with the information needed to generate the output document. The qBox receives this information and creates a new output document that is immediately available to be consulted by the citizen.

39 5.4.1.C qBox/Curator Data Manager

This Controller supports the endpoints for the interaction with the Curator Data Manager. It is here where the Document specifications can be consulted. Each qBox has its own specifications and through the Get Dataset Information endpoint an array with all the dataset specifications and dataset attribute specifications is given (see table 5.4).

Curator Data Manager Name Description API Endpoints Get Dataset Information Returns all Dataset Speciﬁcations of the Curator making the request

Table 5.4: Table Describing the Endpoints of the Curator Data Manager Interface.

5.4.1.D qBox/qBox

The qBox/qBox controller is the only one that is not intended to be directly integrated with the qDocs platform. This is a configuration controller where the owner of the qBox can configure the dataset specifications that are available on the qBox. This controller receives a JSON object specifying a dataset, in the form of a DocumentDto through the Create Document Specification endpoint. From this the qBox builds the dataset specifications and the dataset attribute specifications in order to match the requests received to the specifications established (see table 5.5).

qBox Name Description API Endpoints Create Document Specification Sends a Dataset Specification through a JSON file

Table 5.5: Table Describing the Endpoints of the qBox Interface.

5.4.2 qDocs - qBox Integration qDocs was already integrated with an external API called Curator Simulator, that simulated the qBox basic functions for demonstration purposes. As such, the first approach was identifying the connection points between the Curator Simulator and the qDocs and understand how to replace them with the new qBox solution. The first step of the integration focused on the role of the Curator Data Manager, by creating a connection to the qBox and generating the services. Each service in the qDocs is composed of a number of methods, which in turn contain a number of method fields. Each service is linked to a qBox, the methods represent the datasets and the method fields represent the dataset attributes. The action expected by the Curator Data Manager is the creation of a service, providing a link of a qBox. From there, the qDocs platform is adapted to automatically generate all the methods and method

40 fields available in that qBox, through the qBox/curatormanager interface, that returns a JSON array with all the dataset specifications, containing the respective dataset attribute specifications, supported. This allows for the creation of the methods and method fields, since they represent the same entities, and the information of name, type, and if it is input or output also comes specified from the qBox. In the qDocs platform, through the call of the API the array is received and processed, and each object parsed in order to extract the information and create each method, where the creation of each method field is called.

In addition to this, the form objects, that are the objects that make the method fields available to be used in the templates, are automatically generated as well, from the same information used to create each method field. They are created with the information regarding the name, the organization and the method field to which they are associated.

Also the qBox connection update is integrated in this stage. This update requests the dataset spec- iﬁcations from the qBox and checks for new occurrences. If there is a new dataset then a new method, with the corespondent ﬁelds and form objects, is created. The same happens if there is a dataset that already exists but with new attributes.

After the achievement of this ﬁrst connection, the second step consisted in following the citizen/Cu- rator Templates Manager interaction described in chapter 4.2.

For this the templates used by the citizen to request documents needed to be connected to the qBox under through the Edit New Document Request endpoint. This connection allows for the creation of a new editable document. The document can be accessed and edited multiple times before submission, however this was not planned by the ﬁrst qBox design, where the editing would imply submission of the document. As such an endpoint called Consult Editing Document was created in the qBox to provide access to this editable document by the citizen.

This whole integration of the citizen request had three endpoints from the qBox connecting to the qDocs. One endpoint connects with the document element, namely the Consult Editing Document, allowing the document to be consulted and edited by the citizen. Another endpoint connects with the save functionality, through Edit New Document Request, meaning that when the citizen saves an editing document it is saved in the qBox as an input document. Finally the submit functionality connects with the Submit Document Request endpoint to save changes and change the input document state to pending. This disables the ability of the citizen editing the document through restrictions in the user interface.

The next step on the integration focused on the Curator Templates Manager ability to evaluate the document. A new interface had to be created with a list of all the input documents in pending state regarding that speciﬁc curator, through the qBox endpoint of Consult Documents Request Pending Ap- proval. Also a new user interface where the document is displayed for the Curator Templates Manager was created, using the qBox endpoint of Consult Document Request Pending Approval, that provides the

41 information regarding a specific input document, which is processed and assembled with the respective template. The Curator Templates Manager needs to perform four main actions, namely: (1) approving a document; (2) rejecting a document; where the qBox is connected via the Approve Document Request and Reject Document Request endpoints respectively. (3) writing a public evaluation comment; (4) writing a private evaluation comment. Both evaluation comments will be stored by the qBox within the input document after the evaluation. When the Curator Templates Manager rejects the document that state is stored in the qBox, alongside with its evaluation. If it is approved, the same process happens but in this case a new output document is created with information from the input document. The creation of an output document posed a problem in the qDocs because the input document needs to have a different template than the output document. To create a solution to this problem the input document template and the output document template in the qDocs had do be connected. As such a new parameter was added to the document template to associate a template, which can be done through a field that lists the existing templates. If the template is regarding an output document, this field must be left empty, but if it is regarding an input document the field must be used to select the output document the request refers to. With this solution, when the Curator Templates Manager approves a document, the information from the input document is used with the associated output template to create an output document in the qDocs. Finally we reach the last step, focused on the citizen document consultation, where the citizen must be able to read both the input document and the output document, or the request and the document. For this the integration with the qbox endpoint of Consult Documents was used to build a list of all the documents of a specific citizen, and the connection Consult Document was used to read the output document and present it to the citizen. Additionally a new section was added to the citizen input document interface, to present the details of the evaluation, namely the date of the last action, the state of the document and the Curator Templates Manager evaluation comment.

42 6 Evaluation

Contents

6.1 qBox Connection...... 45

6.2 Document Request and Approval...... 48

6.3 Changing Dataset Conﬁgurations...... 52

43 44 This chapter demonstrates the use of the solution implemented. It follows the steps of each entity’s interaction with the platform, namely: (1) the Curator Data Manager, with the conﬁguration of the qBox; (2) the citizen for the document request as well as for the document consult; (3) the Curator Templates Manager with the document evaluation. This section also demonstrates the capabilities of the qBox as an API, outside of these main interactions. For the demonstrations a document called Grade Improvement Requirement, based on an ofﬁcial document with the same name from Instituto Superior Tecnico,´ as well as a respective Grade Improvement Authorization are used.

6.1 qBox Connection

This first scenario demonstrates the configuration of the first connection with the qBox. Here the Cu- rator Data Manager will setup all the configurations necessary to make document templates and data available for citizens to request and consult.

This happens after the qBox setup in the curator environment, where it must be integrated with the curator’s system and dataset speciﬁcations must be inputted to the qBox as explained further on in section 6.3, as well as existing data that may exist must also be loaded into the qBox database. There is no user interface for these installation scenarios so third party tools must be used.

6.1.1 Services Conﬁguration (Curator Data Manager)

As a first interaction the Curator Data Manager starts by creating a new service, linked to a specific qBox (see 6.1), to which a link must be provided. With the creation of this service qDocs gathers information from the qBox, namely from the dataset specifications, and creates the methods available for that service, displayed to the user as shown in Figure 6.2, as well as the fields of each method, also listed to the user through the interface in Figure 6.3, that shows all the details of each field.

Also the form objects are generated automatically at this stage, for each new field, and linked to the field’s method, as shown in Figure 6.4 where a list of the generated form objects is displayed to the user. All this automation from the information provided by the qBox dataset specifications allows for a fast and easy setup of new services. From here, the Curator Data Manager must configure some parameters of the form objects, such as the form object group, which groups form objects to a specific template building model. The Curator Data Manager must create and assigning each form object to a group, through the interface shown in Figure 6.5, as well as specify the data type expected by the form object in the same page, through the interface in Figure 6.6.

45 Figure 6.1: Create Service Interface. Figure 6.2: View Methods Interface.

Figure 6.3: Edit Method Interface. Figure 6.4: Form Objects Interface.

46 Figure 6.6: Form Object Default Value Figure 6.5: Edit Form Object Interface. Interface.

6.1.2 Templates Conﬁguration (Curator Templates Editor)

The next step is the template creation. Here the Curator Templates Editor uses the form objects to create the templates relative to the documents required (see 6.7). One very important aspect in this creation is the configuration of the connection between requests and certificates. If a document request is supposed to generate a certificate after being approved, the request template must specify the certificate template. This can be achieved in the metadata configuration of the template, where the associated template can be selected from a list of existing templates (see 6.8).

Figure 6.8: Edit Template Metadata with As- sociated Output Template Inter- Figure 6.7: Edit Template Content Interface. face.

After these steps the qBox is conﬁgured in the qDocs platform and the templates it supports are available for the citizens to use.

47 6.2 Document Request and Approval

This scenario demonstrates the interaction of the citizen and the Curator Templates Manager, through qDocs, with a focus on the qBox support. It is based on the processes discussed in Section 4.3 of this document, where the citizen initiates a process of document request, that is followed by a document approval by the Curator Templates Manager and ﬁnally the citizen consults the resulting document.

6.2.1 Document Request (Citizen)

Starting the document request and approval process is the citizen with a document request. To do so, the citizen starts by choosing one of the available forms and ﬁll the information requested (see 6.9).

Figure 6.9: Create New Document Save and Submit Interface.

After all the information is filled the citizen can send the document request for evaluation. This locks the input fields of the document, not allowing further edition (see 6.10) and provides a new field with information regarding the request with its state set to pending (see 6.11). The end of this step makes the document available for the Curator Templates Manager to initiate the next part of the process.

48 Figure 6.10: Document Request After Submission Interface.

Figure 6.11: Evaluation Details Interface.

6.2.2 Document Approval (Curator Templates Manager)

The curator has access to a list of all the document requests pending for approval (see 6.12). Here the Curator Templates Manager can select a document to go to the interface shown in Figure 6.13 where he has read only access to the request, being able to analyse all the input provided by the citizen. The Curator Templates Manager can write two comments, in the two text boxes near the bottom of the interface, regarding the document in analysis: one to be read by the citizen and another to be read only by the curator entity. Finally the Curator Templates Manager can provide the ﬁnal evaluation of approved or rejected.

49 Figure 6.12: Pending Documents Interface.

Figure 6.13: Document Evaluation Interface.

In case the document request is approved by the Curator Templates Manager, a new document is created, based on the information in the document request as well as the template linked to it.

6.2.3 Document Consult (Citizen)

To finalize this process, after that evaluation, the citizen can then access the document request, where information regarding the final outcome of the evaluation is provided. In case the document is rejected that information is shown under the evaluation details, finishing the process (see 6.14). In case the document request was approved, the same information can be accessed on the docu-

50 Figure 6.14: Rejected Document Evaluation Details.

ment request (see 6.15), and a new document will be available to be accessed, being the ﬁnal document generated after the approval 6.16.

Figure 6.15: Approved Document Evaluation Details.

This concludes the interaction between the citizen and the Curator Templates Manager and demonstrates the full support of the qBox of this process.

51 Figure 6.16: Approved Declaration Document.

6.3 Changing Dataset Conﬁgurations

In this scenario new dataset specifications are created in the qBox. To demonstrate the qBox versatility two scenarios were created. The first one with the creation of a completely new dataset specification, and a second one with the addition of fields to an existing one. As a setup, the methods created in the Section 6.1 will be already available. To check for updates the Curator Data Manager must go to the Edit Service interface, where a button with that name can be found (see 6.17). If the Curator Data Manager clicks the button and no new datasets are found, nothing new will be created, meaning that all is up to date as shown in Figure 6.18, where only the already existing methods are shown.

Figure 6.18: Result after checking and ﬁnding no up- Figure 6.17: Check for Updates Interface. dates.

52 6.3.1 Creating new Document Speciﬁcation

In this first example the curator entity where the qBox is installed wants to add a new document. In this case the document is a document regarding the student payment certificate. Through the link of the qBox host the entity can access to /qbox/createdocumentspecification, and with a POST request send the new document specification to be created, here shown with the tool Postman in Figure 6.19, that allows for JSON files to be posted to a specific API endpoint. These modifications in the qBox can be made independently of the qDocs platform, meaning that nothing will change until the Curator Data Manager updates the qDocs platform. The Curator Data Manager, through the same interface shown in Section 6.1 (see Figure 6.17), can now update the platform with the new document specification, that will be created and listed in the Methods interface, as shown in Figure 6.20, where the new methods can be seen.

Figure 6.20: Result after checking and ﬁnding a new Figure 6.19: Creation of new Document Speciﬁcation. Method.

6.3.2 Adding Attributes to Existing Document Speciﬁcation

In this second example the curator entity wants to add a new attribute to an existing document speciﬁca- tion. For that, using the same tool as in subsection 6.3.1, the curator entity can add the new document speciﬁcation, with the same name and attributes as before, as well as with the new attribute (see Figure 6.21). Following the same steps as the example before, in subsection 6.3.1, the Curator Data Manager updates the platform, and the new updated method is created and displayed to the user in the methods list as shown in Figure 6.22, with the added methods also available to be displayed as shown in Figure

53 6.23), while also keeping the previous version of the method for compatibility with existing older versions.

Figure 6.21: Creation of existing Document Specifica- Figure 6.22: Result after checking and finding an exist- tion with new Attribute. ing Method with new fields.

Figure 6.23: The new Fields present in the Method.

54 7 Conclusion and Future Work

Contents

7.1 Conclusion...... 57

7.2 Future Work...... 58

55 56 This chapter presents the conclusion taken from this dissertation as well and identiﬁes the topics that should be approached in future work.

7.1 Conclusion

Interoperability is a growing concern of governments and organizations due to their need to provide connecting services and platforms in an effective and scalable way. As discussed in this dissertation, there are some efforts, that have addressed such interoperability issues, as for example, in what most related with our research, we discussed the European ISA2 framework as an European standard and guide of interoperability. Document automation is being a popular solution to support the creation of electronic documents in a flexible and efficient way [19]. Document automation systems allow the definition and management of templates, which are used to dynamically assembly and create new documents by replacing some particular fields with concrete data, collected directly from end users or from external data sources. On the contrary of some existent document automation tools, which are mainly focused on document assembly for just one individual organization, the qDocs is a innovative proposal on this area: qDocs is based on a secure and scalable citizen-centric and multi-curator architecture that supports an open ecosystem of citizens and (public and private) organizations. In particular, that allows the easy definition of document templates and respective materialization in the scope of administrative/bureaucratic documents and processes. In what concerns interoperability with the curators’ systems, the qBox is a critical component that shall be deployed and configured in the computational environment of each curator, and shall keep all the data submitted by end-users or provided from the curator’s external systems like ERPs. The qBox works in controlled environments as initially intended, with high adaptability to the curators needs and immediate response to the citizens requests, storing all the necessary data in a patronized format and making it available to the users with granted access to it. It is integrated with the qDocs platform and is capable to support the document automation functionalities required by qDocs. It was tested in three core processes of the qDocs, changing dataset configurations, qBox connection and document request and approval, involving three actors, the Curator Data Manager, the Curator Templates Manager and the citizen. The positive results from this evaluation allow to conclude that the qBox works as a proof of concept and the qDocs is ready for basic curator integration via the qBox. When compared to other document automation platforms also studied in this document the qDocs platform uses an integration module, the qBox, to retrieve data from the curators, which is an approach also used by existing platforms, although it stores the curator data in the module itself, whereas other platforms use cloud storage systems or a centralized server to store data and templates. Currently, the qDocs platform intends to facilitate the interaction between Portuguese citizens and

57 some Government services, in a ﬁrst approach by providing access to multiple entities. In the future, qDocs shall support other business scenarios, not only in the public but also in the private sector, like utilities and ﬁnance, providing a customized document automation user-centric platform, where users can perform with multiple roles such as customer or employee.

7.2 Future Work

Future work can be done as a followup of the work described in this theses. The most important would be the integration of the qBox with the curator entities. This would be done on site, installing the qBox and connecting it with the databases of the curators. This installation process would put in practice the concept proven by this work. Also, to facilitate the integration, a simple web interface could be implemented on the qBox, to manage the database and datasets, as well as check for access statistics. On the qDocs side work can be made as well. Following the automatic creation of Methods, Fields and Form Objects, also Document Templates could be automatically created from the document specifications provided by the qBox. This would allow for all documentation that can be requested by the citizen to be available immediately after the qBox configuration. To provide a better user experience a notification system could also be implemented, where after the approval of a document by the Curator Templates Manager entity, the qDocs platform would send a notification to the citizen owner of the document, either an internal notification on the platform, that could be most relevant with the future implementation of a mobile application, or with an SMS notification. Continuing with the interoperability efforts new platforms could be connected to the qDocs platform, namely the services provided by AMA (the Portuguese Agency for Administrative Modernization) such as Autenticaçao.Gov˜ and Bolsa de Documentos. Authentication.Gov is an authentication platform by AMA (Agenciaˆ para a Modernizaçao˜ Adminis- trativa) that takes advantage of the Citizen Card to authenticate the citizen. It allows for the citizen to confirm its identity in a secure way to access public entity sites and portals [33]. The integration of Authentication.Gov with qDocs will be under the Single Sign-On (SSO) functionality, provided by the framework [34]. This interaction will happen for the cases where strong authentication is needed, such as the request or sharing of documents of high importance, and it will be done within the interaction between qDocs/Citizen and qDocs/Server. Once this authentication is successful, the involved curator can trust on the authenticated citizen. Citizen Document Drive is a document manager by AMA [35]. It is an online solution that acts as a central repository to ensure the safe availability of documents, providing document storage, sharing and management, aiming to be a facilitator between the relation between public administration and citizens.

58 Bibliography

[1] A. R. Silva, “qdocs plataforma de documentos quanticos,ˆ centrada no cidadao,”˜ Tech. Rep., 2018.

[2] mdss Meta Documents Systems Lda, “qdocs, citizen centric document technology system requirements speciﬁcation (e2) v1.0,” Tech. Rep., 2018.

[3] J. Menezes, A. R. Silva, and J. Saraiva, “Citizen-centric and multi-curator document automation platform: the curator perspective,” 28th International Conference on Information Systems Develop- ment, AIS, 2019.

[4] J. Baumgarten and M. Chui, “E-government 2.0,” McKinsey Quarterly, McKinsey Company, vol. 4, no. 2, pp. 26–31, 2009.

[5] E. Commission, “Communication from the commission to the european parliament, the council, the european economic and social committee and the committee of the regions,” March 2017. [Online]. Available: https://eur-lex.europa.eu/resource.html?uri=cellar: 2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0014.02/DOC 1&format=PDF

[6] M. M. da Silva, “Integrac¸ao¯ de sistemas de informac¸ao,”¯ Lisboa: FCA - Editora de Informatica,´ Lda., 2003.

[7] E. Ferrance, Action research. LAB, Northeast and Island Regional Education Laboratory at Brown University, 2000.

[8] A. J. Meijer, B.-J. Koops, W. Pieterson, S. Overman, and S. t. Tije, “Government 2.0: Key challenges to its realization,” Electronic Journal of E-Government, vol. 10, no. 1, pp. 59–69, 2012. [Online]. Available: https://repository.ubn.ru.nl//bitstream/handle/2066/111636/111636.pdf

[9] N. Loutas, F. Narducci, A. Ojo, M. Palmonari, C. Paris, and G. Semeraro, “Pegov 2014: 2nd international workshop on personalization in egovernment services and applications,” CEUR Workshop Proceedings, vol. 1181, p. 1–9, 2014.

59 [10] R. Lankester, “Implementing document automation: Beneﬁts and considerations for the knowledge professional,” Legal Information Management, vol. 18, no. 2, pp. 93–97, Cambridge University Press, 2018.

[11] OECD, “Embracing innovation in government global trends,” OECD, 2017. [Online]. Available: https://www.oecd.org/gov/innovative-government/embracing-innovation-in-government.pdf

[12] E. Estonia, “e-estonia,” Tech. Rep. [Online]. Available: https://e-estonia.com/

[13] P. NewsHour, “How estonia built a digital ﬁrst government,” April 2018. [Online]. Available: https://www.pbs.org/newshour/show/howestonia-built-a-digital-ﬁrst-society

[14] L. Guijarro, “Interoperability frameworks and enterprise architectures in e-government initiatives in europe and the united states,” Government Information Quarterly, vol. 24, pp. 89–101, 01 2007.

[15] E. Commission, “Annex to the communication from the commission to the european parliament, the council, the european economic and social committee and the committee of the regions,” March 2017. [Online]. Available: https://eur-lex.europa.eu/resource.html?uri=cellar: 2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0014.02/DOC 3&format=PDF

[16] E. Comission, “The new european interoperability framework.” [Online]. Available: https: //ec.europa.eu/isa2/eif en

[17] N. Colineau, C. Paris, and K. V. Linden, “Automatically generating citizen-focused brochures for public administration,” In Proceedings of the 12th Annual International Digital Government Re- search Conference, ACM, 2011.

[18] J. Frank, “A2j author, legal aid organizations, and courts: Bridging the civil justice gap using document assembly,” Western New England Law Review, p. 251–261, 2017.

[19] K. D. Betts and K. R. Jaep, “The dawn of fully automated contract drafting: Machine learning breathes new life into a decades-old promise,” Duke L. & Tech, p. 216, 2017.

[20] T. F. Gordon, “A theory construction approach to legal document assembly,” In Pre-Proceedings of the Third International Conference on Logic, Informatics and Law, 1989.

[21] M. Pascale, M. Roselli, U. Rugani, C. Bartolini, A. Bertolino, F. Lonetti, E. Marchetti, and A. Polini, “Automated testing of healthcare document transformations in the picasso interoperability platform,” 2009 31st International Conference on Software Engineering - Companion Volume - ICSE- Companion, pp. 163 – 171, June 2009.

[22] A. Author. Chapter 1: A2j author overview. [Online]. Available: https://www.a2jauthor.org/content/ chapter-1-a2j-author-overview

60 [23] A. I. Ltd. Integrating hotdocs server. [Online]. Available: https://www.hotdocs.com/partners/ systems-integrators/technical-documentation

[24] SmartDocuments. Smartdocuments integration. [Online]. Available: https://smartdocuments.eu/ en/products/integration/

[25] Templafy. Templafy integrations. [Online]. Available: https://www.templafy.com/integrations/

[26] Udemy. (2018, October) Build an app with aspnet core and angular from scratch. [Online]. Available: https://www.udemy.com/build-an-appwith-aspnet-core-and-angular-from-scratch/learn/ v4/overview

[27] B. Allen and D. Baier, “The big picture,” 2016. [Online]. Available: https://identityserver4. readthedocs.io/en/release/intro/big picture.html

[28] Microsoft. (2018, November) Introduction to asp.net core. [Online]. Available: https: //docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore2.1

[29] Google. Angularjs. [Online]. Available: https://angularjs.org/

[30] Microsoft. Typescript. [Online]. Available: https://www.typescriptlang.org/

[31] mdss Meta Documents Systems Lda, “qdocs, citizen centric document technology white paper, v1.2,” Tech. Rep., 2018.

[32] CollabNet. What is scrum methodology? [Online]. Available: https://resources.collab.net/agile-101/ what-is-scrum

[33] AMA, “Autenticac¸ao,”˜ Tech. Rep., 2018. [Online]. Available: https://www.autenticacao.gov.pt/ cc-autenticacao

[34] AMA, “Autenticaçao.gov˜ fornecedor de autenticaçao˜ da administraçao˜ publica´ portuguesa,” Tech. Rep., December 2018. [Online]. Available: https://www.autenticacao.gov.pt/documents/ 10179/11463/Manual+de+Integra%C3%A7%C3%A3o+do+Fornecedor+de+Autentica%C3%A7% C3%A3o+v1.4.8/09c23770-05d1-450d-93d6-1b9c97dbe89e

[35] AMA, “Bolsa de documentos,” Tech. Rep., March 2017.

61 62 A qBox API Documentation

63 Entity URL Title Method URL URL Parameters Data Parameters Return

{ "creationDate": [DateTime], "state": [integer], "data": { "name": [string], "creationDate":[DateTime], "attributes": [ { "name": [string], "content": [specified type] }, {...} ] }, "userId": [integer], "avaliatedBy": [integer] Consult Document GET consultdocument/{id} id=[integer] None }

[ { "creationDate": [DateTime], "state": [integer], "data": { "name": [string], "creationDate":[DateTime], "attributes": [ { "name": [string], "content": [specified type] }, {...} ] }, "userId": [integer], "avaliatedBy": [integer] }, Consult Documents GET consultdocuments None None {...} ] Citizen { "documentId": [integer], "creationDate": [DateTime], "state": [integer], "data": { http://localhost:5050/api/citizen/ "name": [string], "creationDate": [DateTime], "attributes": [ { "name": [string], "content": [specified type] }, {...} ] }, "publicEvaluation": [string], "privateEvaluation": [string], "userId": [integer] Consult Editing Document GET consulteditingdocument id=[integer] None } { "documentId": [integer], "creationDate": [DateTime], "state": [integer], "data": { "name": [string], { "creationDate": [DateTime], "data": { "attributes": [ "name": [string], { "attributes": [ "name": [string], { "content": [specified type] "name": [string], }, "content": [specified type] {...} }, ] {...} }, ] "publicEvaluation": [string], }, "privateEvaluation": [string], "UserId": [integer] "userId": [integer] Edit New Document Request POST requestdocumentedit None } } Submit Document Request POST requestdocumentsubmit/{id} id=[integer] None id=[integer] Archive Document Request POST archiveinputdocument/{id} id=[integer] None None Disable Document POST disableoutputdocument/{id} id=[integer] None None { "documentId": [integer], "creationDate": [DateTime], "state": [integer], "data": { "name": [string], "creationDate": [DateTime], "attributes": [ { "name": [string], "content": [specified type] }, {...} ] }, "publicEvaluation": [string], "privateEvaluation": [string], "userId": [integer] Consult Document Request PendingGET Aproval pendingdocument/{id} id=[integer] None } [{ "documentId": [integer], "creationDate": [DateTime], "state": [integer], "data": { "name": [string], "creationDate": [DateTime], "attributes": [ { "name": [string], "content": [specified type] }, {...} ] }, Curator "publicEvaluation": [string], "privateEvaluation": [string], "userId": [integer] },{...}

http://localhost:5050/api/curator/ ] Consult Documents Request PendingGET Aproval pendingdocuments None None { "EvaluatedBy": [integer], { "InputDocumentId": [integer], "documentId": [integer], "RequestDocumentDto": { "creationDate": [DateTime], "userId": [integer], "state": [integer], "data": { "data": { "name": [string], "name": [string], "attributes": [ "creationDate": [DateTime], { "attributes": [ "name": [string], { "content": [specified type] "name": [string], }, "content": [specified type] {...} }, ] {...} } ] }, }, "publicEvaluation": [string], "userId": [integer], "privateEvaluation": [string] "avaliatedBy": [integer] Aprove Document Request POST approvedocument None } } { "avaliatedBy": [integer], "InputDocumentId": [integer], "publicEvaluation": [string], "privateEvaluation": [string] Reject Document Request POST rejectdocument None } id=[integer] [ { "data": { "name": [string], "attributes": [ { "name": [string], "type": [specified type] }, {...} ] },

Curator Administrator "version": [integer], "useType": [integer] }, {...} http://localhost:5050/api/curatormanager/ Get Dataset Information GET datasets None None ] { "data":{ "name": [string], "attributes": [ { "name": [string], "type": [string] }, qBox {... } ] }, "version": [integer],

http://localhost:5050/api/qbox/ "usetype": [string] Create Document Specification POST createdocumentspecification None } None 66