CertNet final report

Capstone Project Final Report CertNet Blockchain-based certificate storage and verification system LauRa Team Group Members Lê Cao Nguyên - SE04555 Hoàng Đình Quang - SE03459 Lê Hà Ph

Capstone Project Final Report

CertNet Blockchain-based certificate storage and verification system

LauRa Team

Group Members

Lê Cao Nguyên - SE04555

Hoàng Đình Quang - SE03459

Lê Hà Phan - SE04195

Phùng Khắc Thành - SE04131

Trần Bằng Tùng - SE06187

Capstone Project Code CERTNET

Hanoi, December 23rd, 2018

Table of Contents

List of Tables 5

List of Figures 6

List of Acronyms 9

Acknowledgement 11

Chapter 1: Introduction 13

1.1 Purpose 13

1.2 Project Information 13

1.3 The People 13

1.3.1 Supervisor 13

1.3.2 Team Members 13

1.4 Background 13

1.4.1 Paper-based certificates can be forged easily 14

1.4.2 A time-consuming, expensive and labor-intensive process 15

1.4.3 Paper-based certificate is hard to preserve 16

1.5 Literature Review of Existing Systems 16

1.5.1 The Massive Open Online Courses (MOOCs) platforms 16

1.5.2 BlockCerts 17

1.6 The Proposal of System 18

1.6.1 System Functions 18

1.6.2 Business Flows 20

1.6.3 Out-of-scope Functions 21

1.6.4 Special Approaches 21

Chapter 2: Project Plan 23

2.1 Project Organization 23

2.1.1 Purpose 23

2.1.2 Software Process Model 23

2.1.3 Roles and Responsibilities 24

2.1.4 Tools and Techniques 25

2.2 Project Management Plan 26

2.2.1 Tasks 26

2.2.2 Meeting Minutes 26

2.2.3 Conventions 27

2.2.4 Risk Management Plan 27

2.2.5 Communication Plan 29

Chapter 3: Software Requirement Specification 31

3.1 Purpose 31

3.2 Functional Requirement 31

3.2.1 Use Case Diagram 31

3.2.2 Business Rules 32

3.2.3 Use Cases 33

3.3 Non-functional Requirement 86

3.3.1 Security 86

3.3.2 Maintainability & Extensibility 87

3.3.3 Availability and Scalability 87

3.3.4 Performance 87

3.3.5 Usability 88

Chapter 4: Software Design 89

4.1 Purpose 89

4.2 Overview of System Architecture 89

4.2.1 Diagram 89

4.2.2 Protocol Explanation 90

4.2.3 Component Explanation 91

4.3 High-level Architecture Design 97

4.3.1 Architecture Layers Design 97

4.3.2 Database Design 100

4.3.3 Common Design 104

4.4 Application of Blockchain Technology in CertNet 105

4.4.1 Overview of Blockchain 106

4.4.2 Ethereum & Smart Contract 107

4.4.3 Choice of Blockchain Platform 108

4.4.4 Application of Blockchain in CertNet 109

4.5 Detailed Design 117

4.5.1 Detailed Design of Front-End Application 117

4.5.2 Detailed Design of Back-end System 152

4.5.3 Detailed Design of Smart Contract 195

4.5.4 Detailed Design of Use Cases & Processes 199

Chapter 5: Software Testing Documentation 297

5.1 Introduction 297

5.1.1 Purpose 297

5.1.2 Scope of Testing 297

5.2 Test Plan 298

5.2.1 Testing Tools & Environment 298

5.2.2 Resources & Responsibilities 300

5.2.3 Test Strategy 301

5.2.4 Features To Be Tested 304

5.2.5 Features Not To Be Tested 306

5.3 Test Case 306

5.3.1 Automation Testing with API Testing and Unit Testing 306

5.3.2 System Testing 309

5.3.3 Acceptance Test 310

5.3.4 Defect Log 312

5.4 Test Report 313

5.4.1 Automation Test Case Report 313

5.4.2 Automation Test Report 314

5.4.3 System Test Case Report 315

5.4.4 System Test Report 317

Chapter 6: User Manual 319

6.1 Development and Deployment Guideline 319

6.1.1 Development Guideline 319

6.1.2 Deployment Guideline 323

6.2 Continuous Integration/Continuous Delivery (CI/CD) Guideline 328

6.2.1 Create Service Account for GitLab CI on Google Cloud 328

6.2.2 Setup CI on Gitlab 329

6.3 User Guideline 330

6.3.1 Install MetaMask 330

6.3.2 User – Login, Sign Up and Reset Password 331

6.3.3 Verifier – Verify Certificates 333

6.3.4 Guest – View Issuer Information 334

6.3.5 Recipient – Manage Personal Profile 335

6.3.6 Recipient – Manage Received Certificate s 336

6.3.7 Issuer – Manage Certificate Templates 339

6.3.8 Issuer – Issue Certificate Batch 340

6.3.9 Issuer – Manage Issued Certificates 342

6.3.10 Admin – Manage Issuers 344

6.3.11 Admin – Manage Requests 345

List of Tables

Table 1.1 – Supervisor’s information 13

Table 1.2 – Team member’s information 13

Table 1.3 – Advantages & disadvantages of MOOC platforms 17

Table 1.4 – Advantages & disadvantages of BlockCerts 18

Table 1.5 – Types of user in the CertNet system 18

Table 2.1 – Project organization structure 24

Table 2.2 – Project team member tree 24

Table 2.3 – Project role description 25

Table 2.4 – Tools & techniques used in project 25

Table 2.5 – Meeting minute template 27

Table 2.6 – Risk register table 29

Table 2.7 – Risk probability – impact matrix 29

Table 3.1 – Business rules 33

Table 3.2 – Actor description 34

Table 3.3 – Use case list 35

Table 3.4 – Security matrix 87

Table 4.1 – CertNet back-end project structure 98

Table 4.2 – CertNet front-end project structure 100

Table 4.3 – Database entity description table 101

Table 4.4 – Entity’s attribute description table 103

Table 5.1 – Testing phases 297

Table 5.2 – Testing environment 300

Table 5.3 – Testing resources and responsibilities 300

Table 5.4 – Testing stages 303

Table 5.5 – Test schedule 304

Table 5.6 – Test deliverables 304

Table 5.7 – List of features to be tested 306

Table 5.8 – Checklist table 312

Table 5.9 – Automation test case report 314

Table 5.10 – Automation test report 315

Table 5.11 – Automation test coverage report 315

Table 5.12 – System test case report 316

Table 5.13 – Test case list 317

Table 5.14 – System test report 318

List of Figures

Figure 1.1 - Certificate forgery cases reported in late 2018 14

Figure 1.2 – Google search result of certificate forgery services in Hanoi 14

Figure 1.3 – A typical process of submitting certificate to local employer 15

Figure 1.4 – A typical process of submitting certificate to foreign employer 16

Figure 1.5 – Example of certificate issued by Coursera 17

Figure 1.6 – BlockCerts homepage 17

Figure 1.7 – Currently supporting visual certificate templates on CertNet system 19

Figure 1.8 – Example of certificate image generated by CertNet system .20

Figure 1.9 – Process of issuing certificate on CertNet system 20

Figure 1.10 – Process of verifying certificate on CertNet system 21

Figure 1.11 – Process of revoking certificate on CertNet system 21

Figure 2.1 – Iterative & Incremental Software Process Model 23

Figure 2.2 – Project management plan 26

Figure 3.1 – Use case diagram of CertNet system 31

Figure 3.2 – Use case diagram of Guest actor 36

Figure 3.3 – Use case diagram of Verifier actor 40

Figure 3.4 – Use case diagram of User actor 42

Figure 3.5 – Use case diagram of Recipient actor 47

Figure 3.6 – Use case diagram of Issuer actor 55

Figure 3.7 – Use case diagram of Admin actor 72

Figure 4.1 – CertNet system architecture 89

Figure 4.2 – CertNet back-end layer design 97

Figure 4.3 – CertNet front-end layer design 99

Figure 4.4 – CertNet database diagram 101

Figure 4.5 – Message queue working mechanism 105

Figure 4.6 – Blockchain data structure 106

Figure 4.7 – An example of smart contract written in Solidity 107

Figure 4.8 – Bitcoin average block time chart 108

Figure 4.9 – Ethereum average block time chart 108

Figure 4.10 – Proof of Existence homepage 109

Figure 4.11 – Calculating the nodes in a Merkle Tree 110

Figure 4.12 – A Merkle path used to prove inclusion of a certificate 111

Figure 4.13 – Certificate issuance algorithm flowchart 112

Figure 4.14 – Example of certificate signature stored in database 113

Figure 4.15 – Certificate verification algorithm flowchart 114

Figure 4.16 – Smart Contract logic to revoke a certificate batch 115

Figure 4.17 – Smart Contract logic to revoke a single certificate 116

Figure 4.18 – Class diagram of front-end application 117

Figure 4.19 – Class diagram of back-end system 152

Figure 4.20 – Class diagram of models 163

Figure 5.1 – V-Model 301

Figure 5.2 – Project development dependencies in package.json file 307

Figure 5.3 – Test environment configuration file 307

Figure 5.4 – Test directory structure 307

Figure 5.5 – Unit test case sample 308

Figure 5.6 – Running test by console command 308

Figure 5.7 – NPM test script in package.json file 309

Figure 5.8 – Automation test report generated by Istanbul 309

Figure 5.9 – Example of test evidence 310

Figure 5.10 – Control tasks and bugs with Pivotal Tracker 312

Figure 5.11 – Example of bug details 313

Figure 6.1 – Install JetBrains WebStorm 319

Figure 6.2 – Interface of WebStorm 320

Figure 6.3 – Install Docker 320

Figure 6.4 – Running Docker in Terminal 321

Figure 6.5 – Interface of Ganache 321

Figure 6.6 – Create storage 322

Figure 6.7 – Create Kubernetes cluster on Google Cloud 324

Figure 6.8 – Deploy services to Kubernetes cluster 325

Figure 6.9 – Register account on CloudFlare 325

Figure 6.10 – Add website on CloudFlare 326

Figure 6.11 – Configure DNS records on CloudFlare 326

Figure 6.12 – MailGun sandbox domain 326

Figure 6.13 – MailGun credentials 327

Figure 6.14 – Register account on Infura 327

Figure 6.15 – Create project on Infura 328

Figure 6.16 – Infura API key 328

Figure 6.17 – Create service account key on Google Cloud Platform 329

Figure 6.18 – Setup CI on GitLab 329

Figure 6.19 – GitLab CI Pipeline 330

Figure 6.20 – Register account on MetaMask 330

Figure 6.21 – Confirm seed phrase 331

Figure 6.22 – Sign Up 331

Figure 6.23 – Login 332

Figure 6.24 – Reset password 333

Figure 6.25 – CertNet home page 333

Figure 6.26 – Verify certificate 334

Figure 6.27 – View all issuers 334

Figure 6.28 – Search issuers by name 335

Figure 6.29 – View public issuer profile 335

Figure 6.30 – View personal profile 335

Figure 6.31 – Import Ethereum address 336

Figure 6.32 – Request to become issuer 336

Figure 6.33 – View all received certificates 337

Figure 6.34 – View certificate content 337

Figure 6.35 – Create share URL 338

Figure 6.36 – View all share URLs 338

Figure 6.37 – Delete share URL 338

Figure 6.38 – View all templates 339

Figure 6.39 – Create new template 339

Figure 6.40 – Template field recommendation 340

Figure 6.41 – Template actions 340

Figure 6.42 – Issue certificate batch – initialize data 340

Figure 6.43 – Issue certificate batch – select visual template 341

Figure 6.44 – Visual template auto-mapping 341

Figure 6.45 – Issue certificate batch – confirm transaction 342

Figure 6.46 – View all issued certificate batches 342

Figure 6.47 – Filter certificate batches 343

Figure 6.48 – Revoke certificate batch 343

Figure 6.49 – View certificate batch details 343

Figure 6.50 – Revoke individual certificate 344

Figure 6.51 – View all issuers 344

Figure 6.52 – Filter issuers 344

Figure 6.53 – Change issuability status 345

Figure 6.54 – View individual issuer profile 345

Figure 6.55 – View all requests 346

Figure 6.56 – Filter request 346

Figure 6.57 – View request details 346

List of Acronyms

API Application Programming Interface

HTTPS Hypertext Transfer Protocol Secure

IDE Integrated Development Environment

SRS Software Requirement Specification

URL Uniform Resource Locator

Acknowledgement

We wish to express our deepest gratitude to our supervisor, Mr Nguyen Tat Trung, for his continuously sharing and motivating throughout the project Under the instructions of Mr Trung, the project team has always felt comfortable and confident Apart from all the technologies and methodologies, Mr Trung shared with us the philosophy of keeping the right attitude towards problems We believe that was the most important factor that led to the success

of this project

We would also like to thank the instructors at FPT University for all the classes We hope you will find this project as a reflection of the knowledge and experiences you have given us during this period of four years

Finally, we truly appreciate the random fellows on the Internet who has discussed with

us Without you, it would have likely been a real struggle to solve every tiny problem

• Project name: CertNet – Blockchain-based certificate storage & verification system

• Project code: CERTNET

• Project group name: LauRa Team

• Product type: Web Application

• Timeline: From 10 th September 2018 to 21 st December 2018

1.3 The People

1.3.1 Supervisor

Supervisor Nguyễn Tất Trung 0904399139 trungnt@fpt.edu.vn Lecturer

Table 1.1 – Supervisor’s information

1.3.2 Team Members

1 Lê Cao Nguyên SE04555 0818336655 nguyenlcse04555@fpt.edu.vn Leader

2 Hoàng Đình Quang SE03459 0961912745 quanghdse03459@fpt.edu.vn Member

3 Lê Hà Phan SE04195 0819020796 phanlhse04195@fpt.edu.vn Member

4 Phùng Khắc Thành SE04131 0774231996 thanhpkse04131@fpt.edu.vn Member

5 Trần Bằng Tùng SE06187 0975980119 tungtbse06187@fpt.edu.vn Member

Table 1.2 – Team member’s information

1.4 Background

Certificates are official documents used to prove that the facts it states are true1, for example, Birth Certificate, Bachelor Degree Certificate, etc For many professional careers, such as doctor, engineer, or teacher, certification is a decisive factor on whether an individual should be hired, or what his salary should be Therefore, certificate issuing, verifying and revocation process should be taken seriously

Traditionally, certificates are issued by the organization in form of paper, stamped or signed by the certifying entity, and that stamp or signature is what confirms its authenticity However, this approach of issuing and verifying has many disadvantages as described below:

1 Definition of Certificate: https://www.oxfordlearnersdictionaries.com/definition/english/certificate

1.4.1 Paper-based certificates can be forged easily

In recent years, several cases of certificate forgery has come to light:

Figure 1.1 - Certificate forgery cases reported in late 2018 2

In fact, searching “làm bằng giả hà nội” on Google returned approximately 140,000,000

results:

Figure 1.2 – Google search result of certificate forgery services in Hanoi

This search result revealed the popularity of certificate forgery services in Vietnam, which

cost only 2 – 3 million Vietnamese Dong and takes approximately 1 – 3 days to complete With

these services, anyone can possess a Bachelor Degree certificate, which takes an average person

2 - Cách chức 5 cán bộ do sử dụng bằng giả: http://giaoduc.net.vn/Xa-hoi/Cach-chuc-5-can-bo-do-su-dung-bang-gia-post189736.gd

- Đường dây làm bằng giả tại Bình Dương: Khởi tố, bắt giam 3 đối tượng liên quan: duong-khoi-to-bat-giam-3-doi-tuong-lien-quan/c/27046346.epi

https://baomoi.com/duong-day-lam-bang-gia-tai-binh-at least 16 years to earn a real one Not only thhttps://baomoi.com/duong-day-lam-bang-gia-tai-binh-at, these certifichttps://baomoi.com/duong-day-lam-bang-gia-tai-binh-ates are hard to be recognized as

fake without professional techniques and contacting with the issuer3

1.4.2 A time-consuming, expensive and labor-intensive process

Traditionally, for an individual to show the employer that he/she has a specific skill, that person needs to get a certificate of that skill, and then include a certified copy of that certificate with their CV when submitting to the employer The overall process is depicted in the following figure:

Figure 1.3 – A typical process of submitting certificate to local employer

One of the most expensive steps in this procedure is notarizing the copy at a Notary public office In Vietnam, this process usually takes 10,000 VND per copy4 While this number may

sound small, the total amount of notarization fee can add up to hundreds of billion VND per year 5

The next one is confirmation of certifcate validity with the organization who issued the

certificate For a typical university, this process usually takes about 2 – 3 working days via

email

In case of submitting certificates to a foreign institution, the situation is even worse Before being sent to another country, certificates may have to be translated and consular legalized at Embassy or Consular Department of the Ministry of Foreign Affairs This process

may take up to 1 weeks to complete6 Some university and employer still re-check the legalized

certificates, and due to geographical distance, this process can take up to 2 weeks

https://thuvienphapluat.vn/tintuc/vn/thoi-su-phap-luat/chinh-sach-moi/20495/bieu-phi-chung-thuc-5 Giấy gì cũng bắt ‘chứng thực’!: https://thanhnien.vn/thoi-su/giay-gi-cung-bat-chung-thuc-399523.html

6 Thủ tục hợp pháp hóa lãnh sự, chứng nhận lãnh sự: http://www.mofahcm.gov.vn/vi/congtac_ls/nr050712145517/

Figure 1.4 – A typical process of submitting certificate to foreign employer

1.4.3 Paper-based certificate is hard to preserve

As a matter of fact, the paper-based certificate is hard to preserve in good condition Over time, paper’s quality will be deteriorated Moreover, according to Vietnamese Notarization Law

2014, the copied version of notarized documents must be preserved at Notary public's offices

for at least 20 years 7 This will take a huge amount of money and effort of the public service system

1.5 Literature Review of Existing Systems

This section contains the overview of some existing popular applications that attempt to tackle limitations of traditional issuing and verification certificate mechanism, as well as their advantages and drawbacks

1.5.1 The Massive Open Online Courses (MOOCs) platforms

MOOCs are free online learning programs usually composed of videos and interactive platforms to teach and test students The introduction of MOOC has brought convenience in study, as well as allowing people to access high quality courses from leading educational institutions around the world By the end of 2018, the number of people learning online courses

had risen to above 100 million, and over 900 universities around the world had launched approximately 14,000 MOOCs8 Some of the top MOOC providers are sponsored by well-

known universities and companies in the IT industry, such as Coursera 9 (Stanford University),

edX 10 (Massachusetts Institute of Technology), Udacity 11 (Georgia Institute of Technology, Google, Facebook), etc

With an amount of fee, MOOCs offer their students with an official digital certificate that confirms that you successfully completed a course

Figure 1.5 – Example of certificate issued by Coursera

Regarding to the aspect of certificate issuance, storage and verification, we can summary the advantages and disadvantages of MOOC platforms as follow:

• Certificate is provided with an URL that

the owner of the certificate can share for

• If the MOOCs provider is hacked, the validity of the certificate can be manipulated easily

Table 1.3 – Advantages & disadvantages of MOOC platforms

1.5.2 BlockCerts

BlockCerts12 is an open standard for creating, issuing, viewing, and verifying based certificates The initial design and development were led by MIT’s Media Lab13 - research laboratory at the Massachusetts Institute of Technology

blockchain-Figure 1.6 – BlockCerts homepage

12 BlockCerts: https://www.blockcerts.org/

13 MIT Media Lab: https://learn.media.mit.edu/

The pros and cons of BlockCerts are listed as below:

• Certificate is revocable, easily verifiable

and shareable

• The first application that applies

blockchain technology to issue and verify

digital documents

• BlockCerts currently uses the Bitcoin blockchain network, which leads to slow transaction time The version tailored to Ethereum network is not fully supported

• Verifying process depends on 3rd-party blockchain explorers like EtherScan14and BlockCypher15 If those services stopped providing API for reading transactions, the verifying process would

be unavailable

• Revocation process is not decentralized

as it depends on a list of revoked certificates that is hosted on issuer’s website If this list is broken or hacked, the revocation process is faulty

Table 1.4 – Advantages & disadvantages of BlockCerts

1.6 The Proposal of System

From those studies, our group came up with an idea: to build a blockchain-based certificate storage and verification system that tackles all limitation of current issuing and verification certificate system

1.6.1 System Functions

There are 4 types of user in CertNet system:

Type of User Description

Issuer Organizations who issue certificates (e.g universities and high schools) Recipient Users who receive certificates (e.g students)

Verifier Users who want to confirm the validity of certificates (e.g employers) Administrator People who manage the CertNet system

Table 1.5 – Types of user in the CertNet system

CertNet system will provide the following functions to the above users:

• Using a Smart Contract deployed on Ethereum blockchain network to store certificate signature and revocation information With the immutability characteristic of blockchain, any modification to the issued certificate will result in the certificate being invalid

• Allow issuers to issue multiple certificates at a time

• Allow issuers to manage content template The content template defines the fields to be included in the certificate

• Allow issuers to optionally choose visual template for the certificate Supported visual templates include:

14 EtherScan: https://etherscan.io/

15 BlockCypher: https://www.blockcypher.com/

o Certificate of achievement

o Certificate of birth

o Bachelor degree

Figure 1.7 – Currently supporting visual certificate templates on CertNet system

• Provide an email system to notify recipients and issuers about certificate issuance and revocation

• Allow issuers to send certificate image, as well as certificate URL to the recipients via email

• Allow issuers to revoke one or multiple certificate at a time

• Allow recipient manage all of their received certificates at one place:

o View the list of certificates, including revoked certificates

o View each certificate’s content

o Generate share URL that links to one or multiple certificates The share URL can be included in CV for submission

• Allow recipients to manage the share URLs they created:

o View number of times each URL is visited

o Delete an URL

• Allow recipients and to view certificate content via share URL

• Allow users to view valid issuer’s information

• Allow administrators to have their own dashboards to manage issuers and requests

• Allow verifier to check the validity of one or multiple certificates via:

o Share URL

o Embedded QR code in the certificate

Figure 1.8 – Example of certificate image generated by CertNet system

1.6.2 Business Flows

1.6.2.1 Certificate Issuance Process

Figure 1.9 – Process of issuing certificate on CertNet system

The input of the issuing process is an Excel file containing all information of certificates

to be issued This is a popular format of data which is used by many institutions including FPT University beside traditional paper issuing process Therefore, issuers do not need to make any change to their current process for utilizing advanced features of CertNet

After issuing process is finished, the recipient will receive an email containing a URL leading to certificate’s detail and a visual certificate file Using the URL, the recipient can view the detail of their certificate as well as create a verifiable URL to share with verifiers Moreover, the visual certificate file also contains a QR code, which can be uploaded directly to CertNet to verify the validity of the certificate

1.6.2.2 Certificate Verification Process

Figure 1.10 – Process of verifying certificate on CertNet system

1.6.2.3 Certificate Revocation Process

Figure 1.11 – Process of revoking certificate on CertNet system

1.6.3 Out-of-scope Functions

Due to the limitation of time, we will not implement some of the intended functions, although we are aware that they are also important and useful for users of the system:

• Two-factor authentication mechanism to add one more security layer to issuer

• Fully functional layout for mobile browsers

• Allow issuers to design their own visual template for the certificates

• Activity tracker that tracks every event triggered by users for auditing purpose

• Support other types of visual certificates like Identity Card, Master Degree Certificate, High School Graduation Certificate, etc

• Fully functional dashboard page for administrators to view system statistics

• Allow administrators to manage contracts with the issuers

• Support other Ethereum-enabled wallet & transaction-signing applications beside MetaMask16

1.6.4 Special Approaches

Finally, we will use some new approaches to solve the stated problems Having aware of the emergence of new technologies, we aim at applying them to our project

• Using Ethereum17 as the blockchain platform for smart contract deployment

• Using Solidity18 and Truffle19 to write smart contract on Ethereum

• Using Docker20 to package applications and services with all the dependencies for executing in containerized environment

• Using Kubernetes21, specifically Google Kubernetes Engine, to manage computing and storage resources of containerized services

• Having separate background job services that communicate with the API service via message queue to handle heavy and time-consuming tasks

• Using GitLab22 for managing source code, as well as Continuous Integration and Continuous Delivery (DevOps)

20 Docker: https://www.docker.com/

21 Kubernetes: https://kubernetes.io/

22 https://about.gitlab.com/product/continuous-integration/

Chapter 2: Project Plan

2.1 Project Organization

2.1.1 Purpose

This chapter provides an overview of the project plan including project organization and project management plan

2.1.2 Software Process Model

Figure 2.1 – Iterative & Incremental Software Process Model

CertNet project uses the Iterative & Incremental Software Process Model

The Iterative & Incremental Software Process Model is mostly used when the scope of the project is big, the major requirements are defined clearly, and some more details will be added later in software development Also, this model has these useful advantages:

• Main functions can be developed early & quickly

• Testing and debugging during smaller iterations are easier

• More flexible – easy & less costly to change if have

• Easier to manage risk because risky pieces are identified and handled during its iteration

• Iterations may be run simultaneously A design team starts the next iteration while the current one is under test

• The project team learns from the first iteration and may use best practices and experiences to improve in the next iterations

2.1.3 Roles and Responsibilities

2.1.3.1 Organization Structure

Project Manager Planning, developing schedules, coordinating communication, generally

responsible for keeping the team’s focus on the main goal

Technical Leader Responsible for choosing and deciding what technologies should be

used, as well as for overseeing the work being done by other developers Quality Assurance

Manager

Ensuring the product meets the certain standards of quality from requirements

Test Leader Responsible for test execution, including test set-up and test run,

evaluation of test run and error recovery, defect logging and test results recording

Developer Involve in coding the product and reviewing code of other developers Designer Involve in designing the product’s user interface

Tester Involve in testing the product

Table 2.1 – Project organization structure

2.1.3.2 Project Team Members

Table 2.2 – Project team member tree

Hoang Dinh Quang Technical Leader

Nguyen Tat Trung Supervisor

Le Cao Nguyen Project Manager

Tran Bang Tung Test Leader/QA

Ha Huy Phan Client Developer Phung Khac Thanh

Server Developer

Team Member Role

Nguyen Tat Trung Supervisor

Le Cao Nguyen Project Manager, Developer

Hoang Dinh Quang Technical Leader, Developer, Tester

Le Ha Phan Developer, Tester, Designer

Phung Khac Thanh Developer, Tester, Designer, Business Analyst

Tran Bang Tung Tester Leader, Business Analyst

Table 2.3 – Project role description

2.1.4 Tools and Techniques

Programming languages & runtime NodeJS, JavaScript, Solidity

Software architecture MVC, Redux, Microservice

Operating system macOS 10.14 Mojave, Ubuntu 18.04

IDE/Editors WebStorm 2018.2.5, Visual Studio Code 1.30

Cloud computing provider Google Cloud Platform

Project management tools Pivotal Tracker, Microsoft Project 2016

Process model Iterative and Incremental Software Process Model Development process Continuous Integration & Continuous Delivery

CI, CD Tools Gitlab-CI, Docker 17.12, Kubernetes

Communication tools Facebook, Skype

Files management tools Google Drive

Smart contract development tools Truffle Framework v4.1, Ganache v2.0

Ethereum test network Rinkeby

Ethereum blockchain explorer Etherscan.io

Table 2.4 – Tools & techniques used in project

2.2 Project Management Plan

2.2.1 Tasks

Refer to CertNet_Project_Management.mpp file

Figure 2.2 – Project management plan

2.2.2 Meeting Minutes

All meeting minutes will be written following this template:

Meeting/Project Name: CertNet

Date of Meeting: 09/10/2018 Time: (Type) 2 hours (Face-to-face)

Meeting Called by: NguyenLC Location: R401 – Alpha building

1 Meeting Objective

-

2 Attendance

Le Cao Nguyen Project Manager nguyenlcse04555@fpt.edu.vn 0818336655 Hoang Dinh Quang Developer quanghdse03459@fpt.edu.vn 0961912745

Phung Khac Thanh Developer thanhpkse04131@fpt.edu.vn 0774231996

- Page header size: 20pt

2.2.4 Risk Management Plan

The project manager works with the project team and guarantees that risks are actively identified, analyzed, and controlled throughout the life of the project Risks will be identified

as early as possible in the project so as to minimize their impact The steps for achieving this are described in the following sections The project manager will serve as the Risk Manager for this project

23 ESLint: https://eslint.org/

24 AirBnB JavaScript Style Guide: https://github.com/airbnb/javascript

some requirements may be added

High Medium All member

discuss carefully in the beginning of each iteration

to define scope and

requirements

Ensure resource allocation

is modified correctly to adapt to new requirement

R2 6 Illness or

absence of team members

The number

of members decreases and not enough for work

Medium Low Member has to

notice to the team about absence period and the plan of how to keep up with the work process

Ensure that the absence

of a member won’t affect others and always have plans

to deal with this

problem

R3 1 Conflict

among team members

Team member disagree with others and refuse to work or work below their ability

Medium High Define clear

tasks and unify the opinion before starting tasks

All members discuss to resolve the conflict Voting

technology

Require to study new technology

to fulfill the requirement

Medium Medium Choosing

technology based on member’s qualification

All team members must nurture by self- study

When someone chooses a new technology, he/she has

to explain

to all team members about the decision

R5 3 Team

member distraction

Team member do not commit enough working time

Medium Medium Choose

member carefully

PM reminds team member about timeline

R6 4 Internet

connection

is down

Internet connection

is down and team members cannot

Low Medium All developers

have to set up the isolated development environment and have an

Use alternative ways to connect to the internet, such as:

submit work

or merge code

offline copy of the

High Medium Form team

early, choose technology stack wisely and training before starting the project

Member informs team about lack of skill, other team member support

R8 8 Library used

in project is

no longer supported

A library is

no longer maintained

reputable library with active maintenance

on GitHub

Choose alternative libraries or code from scratch

Table 2.6 – Risk register table

2.2.4.2 Probability – Impact matrix

2.2.5.1 Weekly Meeting Schedule

• We use the Iterative and Incremental Process Model, then we divide the system into front-end and back-end sub-systems, and each sub-system is divided into a series of small tasks

• Each task is logged to Pivotal Tracker then estimated depending on difficulty and the amount of work by the whole team, after that, the task will be assigned to team members

by the Team Leader and depending on difficulty the Technical Leader will assign deadlines for each task

• We will have a meeting every Friday to inform to all team about what each member finished last week, the status (fast, on time or slow), the issues met and how to solve them If any member raises an issue, the whole team will help to find out a solution together

• After that, the team will define detailed stories for next week tasks and estimate how long it takes to finish them

2.2.5.2 Unscheduled Meeting

If someone has an important problem that he wants to solve immediately, we will have a meeting for discussion, usually via online channels: Facebook, Skype, or Phone

2.2.5.3 Communication Channels

Our main communication channels are Facebook Messenger On the other hand, we used face-to-face meeting, Email, Skype and comment on Pivotal Tracker However, we sometimes make a phone call or instant message if someone has a problem

Chapter 3: Software Requirement Specification

3.1 Purpose

This chapter outlines functional and non-functional requirements of our system It also provides some format constraints in common requirements and project success criteria The content of this chapter is used as the basis for the work in the subsequent chapters

3.2 Functional Requirement

3.2.1 Use Case Diagram

Figure 3.1 – Use case diagram of CertNet system

3.2.2 Business Rules

ID Description

B01 Account's email address must be valid

B02 Account's password must be at least 8 characters in length and must contain at least

1 uppercase letter, 1 lower case letter, and 1 digit

B03 Account's password must not be stored as plain text Instead it must be hashed using

a secure hash algorithm

B04 When registering, or changing password, user must enter the new password twice

B05 A guest must provide their email address and password when registering an

account

B06 A guest cannot register with an email that has already been registered

B07 After registering, guest must activate their account with the activation link sent to

the account's email address

B08 User must provide their account's email address and password when logging into

the website

B09 User cannot login to their account unless the account is activated

B10 Access token must be encrypted when saving into browser’s storage

B11 User must provide their account's email address when resetting the account's

password

B12 User cannot update their account's email address once it has been registered

B13 When changing password, new password must not be the same as the current

B16 Only Issuer accounts can issue and revoke certificates on the system

B17 Only Administrator accounts can manage issuers and requests on the system B18 When an account is registered, the initial role of the account is Recipient

B19 An account's role can be upgraded from Recipient to Issuer, but cannot be reversely

downgraded

B20 To upgrade account's role from Recipient to Issuer, user must submit their issuer

profile to be validated and approved by an Administrator account

B21 When user submits their issuer profile for validation, a request to become issuer is

created, and request status is set to be Pending

B22 Status of a request to become issuer must be one of the three values: Pending,

Approved or Rejected

B23 Status of a request to become issuer can only change from Pending to either

Approved or Rejected by an Administrator account

B24 The personal profile and the issuer profile of an Issuer account are kept separated B25 Ethereum address must be a 160-bit hexadecimal string with '0x' prefix

B26 When adding Ethereum address to profile, user must prove their ownership of the

address

B27 Recipient accounts can only manage the certificates issued to the Ethereum

addresses in their personal profile

B28 Only Issuer accounts whose status is issuable and issuer profile contains Ethereum

address can issue certificates on the system

B29 Guest can only view the public profile of issuers whose status is issuable

B30 Issuer accounts can only view and revoke the certificates and certificate batches

that they have issued

B31 Once revoked, the revocation status of a certificate/certificate batch cannot be

reverted

B32 A certificate batch must contain at least 1 certificate

B33 Certificate batch's title is required

B34 The maximum duration for a token/share URL is 14 days

B35 Content template's name is required

B36 Content template's custom field name must contain English letters, digits and space

only

B37 Logo image file size must not exceed 5MB

B38 Logo image file type must be either BMP, JPG or PNG

Table 3.1 – Business rules

the content of certificate(s) received from recipient(s)

User Everyone who has an account on the CertNet system

Recipient User Individuals/Organizations who possess the certificate(s) on the

system

Issuer User Organizations whose profile has been validated and has the permission

to issue and manage the issued certificates on the system

Admin User A group of people who has the authority to manage the issuers and

system’s status

Table 3.2 – Actor description

UC-2.0 Guest View Public Issuer List

UC-3.0 Guest Search Public Issuers

UC-4.0 Guest View Public Issuer Profile

UC-5.0 Verifier Verify Certificate by Token/Share URL

UC-6.0 Verifier Verify Certificate Image with QR Code

UC-10.0 User View Personal Profile

UC-11.0 User Change Password

UC-12.0 Recipient View All Owned Certificates

UC-13.0 Recipient View Certificate Content

UC-14.0 Recipient View All Share URLs

UC-15.0 Recipient Create Share URL

UC-16.0 Recipient Delete Share URL

UC-17.0 Recipient Add Personal Ethereum Address

UC-18.0 Recipient Delete Personal Ethereum Address

UC-19.0 Recipient Request to Become Issuer

UC-20.0 Issuer Issue Certificate Batch

UC-21.0 Issuer View All Issued Certificate Batches

UC-22.0 Issuer Filter Issued Certificate Batches

UC-23.0 Issuer Revoke Certificate Batch

UC-24.0 Issuer View Certificate Batch Details

UC-25.0 Issuer Filter Certificates in Batch

UC-26.0 Issuer Revoke Individual Certificate

UC-27.0 Issuer View All Content Templates UC-28.0 Issuer Create Content Template

UC-29.0 Issuer Edit Content Template

UC-30.0 Issuer Delete Content Template

UC-31.0 Issuer Duplicate Content Template UC-32.0 Issuer Export Content Template UC-33.0 Issuer View Issuer Profile

UC-34.0 Admin View All Requests

UC-35.0 Admin Filter Requests

UC-36.0 Admin View Request Details

UC-37.0 Admin Update Request Details

UC-38.0 Admin Approve Request

UC-39.0 Admin Reject Request

UC-40.0 Admin View All Issuers

UC-41.0 Admin Filter Issuers

UC-42.0 Admin Change Issuer Issuability Status UC-43.0 Admin View Individual Issuer Profile UC-44.0 Admin Update Issuer Profile

UC-45.0 Admin Change Issuer Logo

UC-46.0 Admin Add Issuer Ethereum Address UC-47.0 Admin Delete Issuer Ethereum Address UC-48.0 Recipient Import Ethereum Address

Table 3.3 – Use case list

3.2.3.1 Guest

Figure 3.2 – Use case diagram of Guest actor

3.2.3.1.1 Register

Use Case Specification

UC ID and Name: UC-1.0 Register

Primary Actor: Guest Secondary Actors: N/A

Description: Register an account on CertNet system

Preconditions: PRE-1.1 Guest has a valid email

Postconditions: POST-1.1 When the normal flow completes successfully, a new

account is created on the CertNet system with the role of Recipient and is activated

Normal Flow: 1.0 Register

1 Guest visits CertNet website

2 System displays CertNet home page

3 Guest clicks Login or Register menu on the navigation bar

4 System displays login/register dialog box

5 Guest clicks Sign Up tab in the dialog box

6 System displays the registration form in the dialog box

7 Guest enters email address, password and confirm password

on the registration form

8 Guest clicks Sign Up button on the registration form

9 System creates a new Recipient account with the email address

and password provided

10 System generates an activation link for the account

11 System sends an email with the activation link to the provided email address

12 System displays a message to notify that the account has been created and the activation email has been sent to the registered email address

13 Guest visits his/her email account and open the activation email

14 Guest clicks the activation link

15 System activates the new account, then deletes the activation link from the database

16 System displays a message to notify that the account has been activated

17 System displays the CertNet home page

Alternative Flows: N/A

Exceptions: 1.0-E1 – Cannot communicate with API server

System displays error message

1.0-E2 – Input data in step 7 violates one or some of the business rules

System displays error message on the registration form

1.0-E3 –24 hours since the activation email is sent, the Guest does not click the activation link

System deletes the account and the activation link from database

Frequency of Use: High

Business Rules: B01, B02, B03, B04, B05, B06, B07, B18

Other Information: N/A

Assumptions: Guest can access his/her email account

3.2.3.1.2 View Public Issuer List

Use Case Specification

UC ID and Name: UC-2.0 View Public Issuer List

Description: View list of registered issuers on CertNet system without logging in Preconditions: N/A

Postconditions: N/A

Normal Flow: 2.0 View Public Issuer List

1 Guest visits CertNet website

2 System displays CertNet home page

3 Guest clicks Partners menu on the navigation bar

4 System displays the list of registered issuers, where each issuer

is presented with name, logo, email, phone number and website

Alternative Flows: N/A

Exceptions: 2.0-E1 – Cannot communicate with API server

System displays error message

3.2.3.1.3 Search Public Issuers

Use Case Specification

UC ID and Name: UC-3.0 Search Public Issuers

Primary Actor: Guest Secondary Actors: N/A

Description: Search for registered issuers on CertNet system without logging in Preconditions: N/A

Postconditions: N/A

Normal Flow: 3.0 Search Public Issuers

1 Perform the normal flow of UC-2.0

2 Guest enters search keyword on search box

3 Guest clicks search button

4 System displays the list of issuers matched with the search keyword Each issuer is presented with name, logo, email, phone number and website

Alternative Flows: N/A

Exceptions: 3.0-E1 – Cannot communicate with API server

System displays error message

Frequency of Use: Medium