Identity Management with Blockchain

Identity Management with Blockchain

Joao Gilberto Fernandes Ramos

Thesis to obtain the Master of Science Degree in

Information Systems and Computer Engineering

Supervisors: Prof. Miguel Leitao Bignolas Mira da SilvaDr. Paulo Figueiredo

Examination Committee

Chairperson: Prof. Daniel Jorge Viegas GoncalvesSupervisor: Prof. Miguel Leitao Bignolas Mira da Silva

Member of the Committee: Prof. Miguel Nuno Dias Alves Pupo Correia

June 2019

Acknowledgments

I would like to thank my parents for their friendship, encouragement and caring over all these years,

for always being there for me through thick and thin and without whom this project would not be possible.

I would also like to thank my grandparents, aunts, uncles and cousins for their understanding and support

throughout all these years.

I would also like to acknowledge my dissertation supervisors Prof. Miguel Mira da Silva and Eng.

Paulo Figueiredo 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 during the good and bad times in my life. Thank you.

To each and every one of you – Thank you.

Abstract

The digital disruption has been changing the way people live and interact with the world. One of these

great changes is the continuous evolution of the digitization of personal identity. In the digital world in

which we live today, it is becoming less practical for citizens to keep as much personal information in the

form of a physical document, be it citizen’s card, driver’s license, health card, among others. Because

different personal information comes from different sources, it is not feasible to control the digitization of

this information by a centralized entity.

With the advent of blockchain technology, for the first time it is possible to create a decentralized

eco-system where different entities can not only emit their traditional physical cards but also emit them

in digital form and with the same credibility, thus creating, for the first time a dematerialization of the

cards that today serve as a form of identification.

However, the current solutions that provide a digital identity are based on public blockchains. Since

companies prefer to minimize their risks and avoid the unknown, a private blockchain makes more

sense for more important use cases, one of which is the opening of bank accounts. Thus, there is a

gap between the needs imposed by the companies, in this case the banking institutions, and the existing

services. This way, this thesis proposes PDID, a service that provides a digital identity based on a private

blockchain. A demonstration is also done at a bank to exemplify how this type of service can facilitate

and accelerate the opening of a bank account, facilitating the KYC process.

Keywords

Digital Disruption, Digital identity, Banking Industry, KYC.

iii

Resumo

A disrupcao digital tem vindo a mudar a forma como as pessoas vivem e interagem com o mundo. Uma

dessas grandes mudancas e a contınua evolucao da digitalizacao da identidade pessoal. No mundo

digital em que hoje vivemos, cada vez e menos pratico os cidadaos guardarem tantas informacoes

pessoais sob a forma de um documento fısico, seja ele cartao de cidadao, carta de conducao, cartao

de saude, entre outros. Como diferentes informacoes pessoais provem de fontes diferentes, nao e

viavel que o controlo da digitalizacao destas informacoes seja por uma entidade centralizada.

Com o aparecimento da tecnologia blockchain, pela primeira vez, e possıvel criar um eco-sistema

descentralizado onde estas varias entidades podem, nao so emitir os seus tradicionais cartoes fısicos,

como tambem emiti-los numa forma digital e com a mesma credibilidade, criando assim, pela primeira

vez a desmaterializacao dos cartoes que hoje servem como forma de identificacao.

No entanto, as atuais solucoes que providenciam uma identidade digital baseiam-se em blockchains

publicas. Visto que as empresas preferem minimizar os seus riscos e evitar o desconhecido, uma

blockchain privada faz mais sentido para casos de uso mais importantes, sendo um deles a abertura

de contas bancarias. Assim sendo, existe assim uma lacuna entre as necessidades impostas pelas

empresas, neste caso as instituicoes bancarias, e os servicos existentes. Desta forma, esta tese propoe

o PDID, um servico que providencia uma identidade digital com base numa blockchain privada. E

tambem feita uma demonstracao na industria bancaria para exemplificar como este tipo de servicos

pode facilitar e acelerar a abertura de uma conta bancaria, facilitando o processo de KYC.

Palavras Chave

Disrupcao Digital, Identidade Digital, Blockchain, Industria Bancaria, KYC.

v

Contents

1 Introduction 1

1.1 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Related Work and Background 7

2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Hyperledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 ISO/IEC 9126 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 Multiple Criteria Decision Analysis (MCDA) . . . . . . . . . . . . . . . . . . . . . . 12

2.2 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Identity Management using blockchain . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Competing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Civic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 uPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Shocard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Research Problem 19

3.1 Problem Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Research Proposal 25

4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4 Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

4.6 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Implementation 33

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Rest API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Client Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Institution Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Evaluation 41

6.1 Proposed Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2.1 Identify the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2.2 Identify the criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.3 Weight the criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.4 Analyze documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.5 Analyze the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3 PDID Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.4 Discussion of PDID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7 Conclusion 51

7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A Appendix A 63

B Appendix B 65

C Appendix C 67

viii

List of Figures

1.1 Evolution of digital identity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 DSRM Process adapted from [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Civic Architecture [2]: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 An overview of key elements of uPort, image and label retrieved from [3]. . . . . . . . . . 16

2.3 An overview of key elements of ShoCard, image retrieved from [3]. . . . . . . . . . . . . . 17

5.1 Diagram of Fabric Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 A possible network composed by banks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Diagram of the network interacting with the Rest API . . . . . . . . . . . . . . . . . . . . . 37

5.4 Client’s App example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.1 Weighing scale for each criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2 Overall value scores of the alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.3 Robustness analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

B.1 Rest API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

ix

List of Tables

5.1 Banks used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Banks used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A.1 Current digital identity approaches using blockchain . . . . . . . . . . . . . . . . . . . . . 64

xi

Listings

4.1 First access control rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Second access control rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Third access control rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Fourth access control rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 Fifth access control rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

B.1 Post claim example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B.2 Post transaction example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

C.1 Grant claim access transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

C.2 Revoke claim access transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

xiii

Acronyms

DID Digital Identity

CAs Certificate Authorities

DLP Distributed Ledger Platform

P2P Peer-to-Peer

B2B Business-to-Business

IS Information Systems

BS Behavioral Science

DS Design Science

DSR Design Science Research

DSRM Design Science Research Methodology

IoT Internet of Things

SIFT Scale Invariant Feature Transform

KYC Know Your Customer

App Application

DApp Decentralized Application

IPFS InterPlanetary File System

Saas Software as a Service

IdP Identity Provider

PoC Proof-of-Concept

xv

MACBETH Measuring Attractiveness by a Categorical Based Evaluation Technique

MCDA Multiple criteria decision analysis

DM Decision Maker

CISO Chief Information Security Officers

GLEIF Global Entity Identifier Foundation

PDID Portuguese Digital ID

ACL Access Control Language

SLA Service-Level Agreement

RBAC Role-Based Access Control

xvi

1Introduction

Contents

1.1 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1

Digital Identity (DID) is a concept that has been evolving in the last few decades. At the beginning of

the Internet, centralized authorities were the issuers and authenticators of digital identity. It started with

Certificate Authorities (CAs) helping e-commerce websites proving they were who they said they were.

However, this approach suffers from a problem that is also affecting the current solution in the physi-

cal world, users are conditioned on the possible misuse or malicious use from centralized authorities.

Therefore, after a few years, the second phase of digital identity started. With a federated identity, users

could use the same usermnne and password across multiple websites. Companies saw its potential and

created federated ecosystems, being the first one created by Microsoft. Once again, these federated

identities created honeypots of information and the possibility of malicious use remained. [4]

The first digital identity model towards decentralization was presented by Jordon et al [5] where a

persistent online identity was proposed. This approach valued the possibility for digital identity to be

used in multiple websites without requiring a federation. It is called user-centric because users are in

the middle of the identity process.

As implemented, user-centric methodologies tend to focus on two elements: user consent and in-

teroperability. By adopting one, users can choose whom to share their identity with. Some of the most

known methods that are based on user-centric identity are the following: OpenID [6], OpenID 2.0 [7],

OpenID Connect [8], OAuth [9], and FIDO [10].

Self-Sovereign Identity is the latest step in the evolution of digital identity. According to Christopher

Allen [11], Self-Sovereign Identity is the next step beyond user-centric identity and that means it started

where user-centric ”ended”: the user must be central to the administration of his identity. That requires

not just the interoperability of the user identity across multiple locations with the user’s consent, but

also true control of that digital identity, providing autonomy to the user. In order to accomplish this, a

self-sovereign identity must be transportable; it can not be locked down to one site or local. Figure 1.1

presents the four steps of the digital identity.

Nowadays, a few digital identity services are starting do adopt blockchain as a common database

shared by the institutions that use the service. It is no surprise that blockchain has become very popular

over the last years. It functions as a Distributed Ledger Platform (DLP) that has all transactions since

the beginning.

Unlike a traditional database, blockchain technology does not rely on a single central institution to

validate transactions. In a blockchain network, transactions can be done in a Peer-to-Peer (P2P) way

[12]. Every transaction needs to be validated by the entire network and committed into blocks that are

distributed through the network, meaning that is almost impossible to tamper it. Even an attempt to forge

a transaction would be easily detected since every node will check the block [12].

Although, most digital identity services are starting to adopt blockchain, they are using permission-

less blockchains. In this case, a user is not bounded to a single wallet address, this means that a user

3

can have several wallet addresses, allowing him to avoid identity exposure.

In this thesis, we will to take the opposite path that most similar services took. We will bound a digital

identity with a real identity to bring it clear to real world applications. Thus, we believe the future is in

using permissioned blockchain. In a permissioned blockchain, not every actor can participate in the

consensus. Only a restrict number of actors can validate transactions of a block that afterward will be

added to the blockchain [13].

These networks function in contained ecosystems, where several entities, usually Business-to-Business

(B2B), intend to exchange information and store it at the same time. In this type of blockchains, there

is no need to use complex cryptographic problems since all participants are trustworthy. This allows

transactions to be verified very quickly since there is no need to reward the miners. Only authorized

entities can write in the ledger.

Figure 1.1: Evolution of digital identity.

1.1 Research Methodology

We started with an introduction to the researched subject, giving an overview of the evolution of digital

identity, the current alternatives and a possible path towards a different approach. It is now important to

define the research methodology that will be used in order to guide this thesis.

Information Systems (IS) has a very extended literature regarding the guidelines and frameworks

for IS research. After studying the existent literature about this subject [14–17], we concluded that IS

research is divided into two main areas: Behavioral Science (BS) [14] and Design Science (DS) [14].

We decided to use Design Science Research (DSR) since it is a well-known practice and very accepted

by the IS community.

According to March et al [15], a two-dimensional four by four matrix is used as a Design Science

research framework. In the columns, it is represented the Research Activities: build, evaluate, theorize

and justify. In the rows, it is represented the research outputs that are composed of constructs, models,

methods, and instantiations. Research outputs are also usually called as artifacts.

4

Henver et al [14] extended the work made by March et al [15] by creating a guideline composed

by seven steps: Design as an Artifact, Problem Relevance, Design Evaluation, Research Contribution,

Research Rigor, Design as a Search Process and Communication of Research.

Later, Peffers et al [17] extended the work presented by Peffers et al [15] and Henver et al [14] by

presenting Design Science Research Methodology (DSRM). Design Science Research Methodology is

also a methodology used in Information Systems and it supports guidelines for evaluation and iteration

in research projects. An artifact is created and then its performance is evaluated. The goal of the artifact

is to solve an organizational problem. The artifact can be constructed (vocabulary and symbols), models

(abstractions and representations), methods (algorithms and practices), and instantiations (implemented

and prototype systems) [14].

The process of DSRM has six phases (Figure 1.2):

1. Problem Identification: In this phase, it is defined as the specific researched problem and it is

justified the value of the solution.

2. Objectives Definition: In this phase, the objectives of the solution are defined.

3. Design and Development: In this phase, the artifact is created to solve the problem.

4. Demonstration: In this phase, it is demonstrated that the artifact to solve the stated problem.

5. Evaluation: In this phase, it is evaluated the performance of the artifact. If it can solve or not the

problem stated.

6. Communication: In this last phase, it is done the communication of the problem and the proposed

solution to the scientific community.

Figure 1.2: DSRM Process adapted from [1]

5

1.2 Document Outline

This thesis is composed of 7 chapters. As we have seen so far, in Chapter 1 is made an introduction

to the subject of research, explaining the evolution of digital identity, its advantages and its connection

with blockchain. Finally, it explains the research methodology used as well as its application. Chapter

2 explains the state of the art, the existing competitive services and also the background needed to

understand this thesis. Chapter 3 explains the problem encountered, the motivation and a summary of

the interviews with the specialists in the field.

Chapter 4 describes the architecture of the solution that will solve the problem presented in Chapter

3. In Chapter 5, it is demonstrated how the architecture proposed in the previous chapter was imple-

mented.

Since there was no formal and concrete method to evaluate the proposal presented in this thesis,

Chapter 6 begins with a proposal of new method to evaluate digital identity services. Also in the same

chapter, it is demonstrated how to use it and it is made a comparison between the current alternatives

and our service.

Finally, in the last chapter, it is made a conclusion of this thesis. It also explained the limitations of

this proposal and what can be done in the future to improve it.

6

2Related Work and Background

Contents

2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Competing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Civic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 uPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6 Shocard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7

2.1 Background

2.1.1 Smart Contracts

The concept of a smart contract was originally created in 1997 by Szabo [18]. Just recently smart

contracts started to be used in blockchain [19] and the first permissioned blockchain providing that

option was Ethereum [20]. A smart contract used with blockchains is a piece of software code that is

deployed and runs in all the nodes of the blockchain.

With a smart contract, it is possible to create loops and triggers to execute actions. For example,

”John sends x Ether to Paul once a month over the next year”. Since infinite loops can be created, it

would be possible to attack a network because that loop would be running in every node of the network.

To prevent this kind of attacks, in permissionless blockchains it is necessary to pay a fee for every trans-

action. For example, Ethereum created a unit called ’gas’ [20] to prevent a user from spam transactions.

If a user wants to do a transaction, he has to pay gas to send it [21].

There are two problems yet to solve with smart contracts: the first one is the scalability, it is impossible

to expect that in the future, with the grow of smart contracts and nodes, every transaction is validated by

every node; the second is the correctness of a smart contract, making sure that it does exactly what it is

supposed to do.

2.1.2 Hyperledger

Hyperledger is an open source project founded by the Linux Foundation [22]. The Hyperledger’s goal is

to create a distributed ledger based on blockchain technology. Its focus is to create a distributed ledger

that can support transactions of global industries, including the main companies in the technological and

financial sectors, with the objective to improve several aspects of the performance and robustness.

The project aims to unite a number of independent attempts to develop open standards and protocols,

providing a modular framework that supports different components for different users. Hyperledger

includes a variety of blockchains, each with its consensus, persistence models, and services for identity,

access control, and contracts. [22]

Most popular blockchains do not support private contracts or transactions. Yet, it can be crucial for

business industries. Having this problem, IBM and Digital Asset created Fabric, that was then donated

to Hyperledger creating Hyperledger Fabric. Hyperledger Fabric is a permissioned blockchain that pro-

vides a modular, secure, and scalable architecture. In Hyperledger Fabric, smart contracts are called

’chaincondes’.

In Fabric, there are two types of nodes: peer nodes and orderer nodes. Peer nodes run the chain-

code, access the data inside the blockchain, endorse transactions and interact with the applications.

9

Orderer nodes are responsible for the consistency of the blockchain, they deliver the endorsed transac-

tions to all the peers in the network [23,24].

Hyperledger Composer is a set of tools that allow developers to build business networks and smart

contracts in a simpler and faster way. It runs on top of Fabric, allowing easy management of the Assets,

Participants, and Transactions. Assets are the data stored on the blockchain, the Participants are the

members that interact with the blockchain and for last, Transactions are smart contracts. They make the

bridge between Assets and Participants.

• Client: A client is an entity that acts as a user. It must be connected to a peer to interact with the

blockchain. Clients are the ones that create and invoke transactions. [25,26]

• Peer: Peer nodes, or simply peers, are the primary physical points that constitute a blockchain

network. They have a fundamental job in the network because they are the ones that host in-

stances of smart contrasts and ledgers. [25,26]

• Ordeer: Ordeers are the nodes in the network responsible to collect transactions from network

members, order them and group them into blocks. Then, they send them back to the peers to be

written in their ledgers on each channel. Because of their important job, they are often referred to

as the ”heart” of a network.

In the first versions of Fabric, ordering was done inside the peers, but with Fabric 1.0, it was

separated to increase peer performance.

At a physical level, it is recommended to use more than one orderer because, with only one

orderer, the network isn’t fault tolerant. However, for test or Proof-of-Concept (PoC) environments

one orderer, known as a SOLO orderer, is enough. With more orderer nodes, it is used Kafka

ordering service. [25,26]

• Certificate Authority

A Certificate Authority is responsible to issue certificates for all participants of the network. Every

entity of the network, peers, ordeers, and clients must have a certificate. It serves to identify each

entity in order to verify their permissions and the transactions they are allowed to do and channels

allowed to participate. [25,26]

• Channel

A channel e a private blockchain overlay supported by Fabric. Channels can be used by a subset

of members to share private and confidential data across the network. Multiple channels can be

created between subsets of members or with all of them. Each channel has its own specific ledger

and members must be authenticated to interact with it. [25,26]

10

• Consensus

In Hyperledger Fabric, consensus is not just a simple function algorithm. Although one of the most

important parts is the aggregation of transactions, consensus in the representation of the entire

transaction flow, from proposal and endorsement, to ordering, validation and commitment.

Ultimately, consensus is achieved when the order of transactions are according with the the policy

in responsible for those transactions.

[25,26]

• Consortium

A consortium is defined as a ”group with a shared destiny”. In Hyperledger Fabric, a consortium

is a group of non-orderer organizations together with a common goal. There are the only organi-

zations that are allowed to create channels. For example, in Figure 5.1, Org1, and Org2 created a

consortium RARB and communicate with each other using channel C1. [25,26]

• Kafka

Kafka is the ordering service recommended for production use by Hyperledger Fabric. This or-

dering service uses Apache Kafka, ”an open source stream processing platform that provides a

unified, high-throughput, low-latency platform for handling real-time data feeds”. [27]

The Kafka ordering service provides a crash fault-tolerant solution to ordering because there are

multiple ordering nodes. [25,26]

• SOLO

SOLO is the Hyperledger Fabric ordering mechanism used for test and PoC environments. SOLO

only uses a single ordering node, it does not tolerate faults. [25,26]

2.1.3 ISO/IEC 9126

The ISO/IEC 9126 is a norm from the International Organization for Standardization (ISO). It is defined

by six attributes that characterize software quality and provide a baseline for further clarification. It also

allows the creation of guidelines of the software quality [28,29].

These characteristics are [28]:

• functionality - The ability of a software to provide features that satisfy the user in their stated and

implicit needs, within a context of specific use.

• reliability - The ability of the software product to maintain a specified performance level, when

used under conditions.

11

• usability - The ability of the software product to be understood, learned, operated and attractive

to the user when used under specified conditions.

• efficiency - The runtime and resources involved are compatible with the level of software perfor-

mance.

• maintainability - The ability (or facility) of the software product to be modified, including both

enhancements or extensions of functionality as well as corrections of defects, failures or errors.

• portability - The ability of the system to be transferred from one environment to another.

2.1.4 Multiple Criteria Decision Analysis (MCDA)

A decision problem typically involves adjusting multiple, and often conflicting, criteria. Multiple criteria

decision analysis (MCDA) consists of ”a collection of formal approaches which seek to take explicit

account of multiple criteria in helping individuals or groups explore decisions that matter” [30].

Measuring Attractiveness by a Categorical Based Evaluation Technique (MACBETH) is an approach

for the evaluation of multiple-criteria [31, 32]. The Decision Maker (DM) uses qualitative judgments to

compare the differences between two elements at the same time. As responses are being introduced

into the MACBETH decision support system [33] it automatically verifies their consistency. Finally, it

generates a numerical scale by solving a linear programming problem that is representative of the DM’s

judgments for each criterion [34]. Through a similar process, it allows the generation of weighing scales

for criteria [28, 35, 36]. From the judgments and criteria weights, it is possible to compare the overall

scores of the alternatives and select the best one [12,37].

2.2 State of the Art

This section explains the studied related literature, presents current alternatives of digital identity and

analyzes the most relevant ones.

Identity management can be seen as an access control problem because, in theory, it is the pro-

cess of grant and revoke access of personal information to others. This way, we analyzed the currents

approaches being used in access control problems in order to have a better idea of a possible solution.

With the boom of the blockchain, we found that there are two main use cases for access control with

blockchain: tracking Internet of Things (IoT) devices [38, 39]; storing sensitive information like medical

records [40] and educational certificates. However, we concluded that every solution is very restricted

to its application, not being possible to extrapolate one solution to our use case.

12

2.2.1 Identity Management using blockchain

Multiple approaches have been developed in this field, most of them follow the same foundation, they are

built on top of a public blockchain. These projects have a similar goal: to provide a self-sovereign identity.

Generally, they are developed using smart contracts on top of public blockchains. The main reason is

that they are more transparent than private blockchains. uPort [41] and Civic [2] are two examples of

services being developed at the moment using Ethereum as their blockchain and Schocard is currently

using Bitcoin’s [42] blockchain (Figure 2.3).

We explored an approach presented by Liu et al [43] that uses Ethereum tokens as reputation in

order to differentiate the trusted users from the malicious ones. Its architecture is composed of two

modules: Identity Authentication Module and Reputation Management Module.

The Identity Authentication Module makes the link between an Ethereum public key and a real identity

of a user, ensuring that a person can only be linked to a single public key. Since the Ethereum Blockchain

allows a user to have multiple wallets and consequently multiple public keys, Liu et al [43] solved this

problem by hashing the user’s identity into an ID.

IDi = Hash(identityInfoi)

Furthermore, an identity is an aggregation of the public key, an ID and the amount of RPcoin tokens.

Identityi= (Addressi, IDi, RPcoini)

This approach also allows the possibility to update a user’s identity or his address while keeping the

same amount of RPcoins.

Moving on to the Reputation Management Module, this module manages the user’s reputation by

giving good rewards when the user is daily active and when tasks are approved. It also punishes users

when tasks are rejected. ”When a user always behaves truthfully and actively, the user’s reputation

should be high, and verse vice. Thus, the reputation score of a user in our system reflects the user

behavior change with time, which is innovative in the literature” [43].

Biometric-based authentication was explored as well, Hammudoglu et al [44] presented an open-

source android based approach to use fingerprints and blockchain for authentications. As Hammudoglu

et al [44] explains in details, it is a tough field since ”these resources have often been limited to legal

patents as in the case of Scale Invariant Feature Transform (SIFT) algorithm [45]” [44].

13

2.3 Competing Services

The importance of controlling our own identity is becoming more and more popular. While searching for

related work, we found more than thirty projects (Table A.1) [46] joining digital identity and blockchain.

After an analysis, we discovered that none of this projects was ready to be used as a real solution. Also,

since the 2017 blockchain hype is now gone, most of the projects were abandoned. In Appendix A, it is

presented a table with the full list of the projects found.

Now, it will be explained in detail three of the most promising projects: Civic, uPort, and Shocard.

2.4 Civic

Civic [2] is a Decentralized Application (DApp) where it is possible to store a digital identity. It was

the first project using blockchain technology for that purpose. At the moment, it is possible to use the

mobile Application (App) to do a secure authentication in a website without using personal information

(e.g. username, email or password). According to the road map, Civic also wants to use their platform

to facilitate Know Your Customer (KYC) processes, introducing for the first time the ”reusable KYC”

idea. In addition, it will also be possible to use Civic as a two-factor authenticator, replacing Google

authenticator [47] for example.

In Civic, transactions can only be done in a volunteer way (Figure 2.1, this means that both the

identity owner and the requester have to agree on the transaction. Since Civic will work as a KYC so-

lution provider, they intend to have several mechanisms to accomplish it, including combining trusted

databases with fraud detection algorithms. Civic also plans to do manual audits to validate digital iden-

tities. However, it is not specified which databases will be used and how they will manually validate

identities.

Civic is developed using smart contracts on the Ethereum network, which makes it a permissionless

DApp. As other relevant technologies, Civic uses QR codes to create a friendly authentication in a

website and uses biometric data to validate the user’s identity in the mobile application.

To finalize, all the personal information is stored in the user’s App, allowing this system to be decen-

tralized.

2.5 uPort

uPort a is a decentralized service and its goal is to ”provide a digital identity for everyone” [41]. It is

currently under development. It also uses Ethereum’s smart contracts, but since the final product is

not ready yet, the smart contracts are not deployed in Ethereum’s main net, they currently use one of

14

Figure 2.1: Civic Architecture [2]:

the Ethereum’s test net. Like Civic, it is possible to use uPort’s mobile application to do simple website

authentication without using personal information (e.g. username, email or password), they also use QR

codes to facilitate the process. To expand their use cases, they introduced a concept where users can

emit credentials for other users. These credentials can be event tickets, educational certificates, and

others.

2.5.1 Architecture

It has two main smart contracts that are responsible for the user’s identity: Controller and Proxy.

When a user creates a new account using the uPort’s mobile application, it generates a key pair

(public and private key). The private key is stored by the user and the public key is used to create

an instance of the Controller. The following is a Proxy instance is created using the reference of the

Controller. Only the instance of the Controller can invoke Proxy functions.

The private key that gives control of the uPortID is only stored on the user’s smartphone. This way,

in case of a smartphone loss, there is a protocol provided by uPort to recovery the digital identity. The

user should name uPortIDs that he trust and they can vote to replace the public key that references the

Controller. If they reach a quorum, the Controller instance is replaced, assigning a new private key to

15

the user. This allows uPortID to be persistent even in cryptographic key loss.

Finally, there is a smart contract called Registry that maps all the uPortIDs to their respective at-

tributes. Any entity can be queried to the Registry, however, only the owner of a uPortID can modify its

attributes. User’s information is stored in the form of a JSON in InterPlanetary File System (IPFS): a

distributed system where it is possible to access a file through a hash (Figure 2.2.

Figure 2.2: An overview of key elements of uPort, image and label retrieved from [3].

2.6 Shocard

Shocard [48] is a DApp that intends to offer to its users a digital identity. With this digital identity, a person

will be able to do secure authentications on websites, use it for KYC processes, and even use banks and

other online institutions to authenticate a person’s data. The company currently provides two products.

The first is a Software as a Service (Saas) that will be used for Secure Enterprise Identity Authentication

and the second is an Identity Provider (IdP) that will be similar to the services that we presented before.

It aims to solve problems such as usernameless authentication, facilitate KYC processes, credit card

authorization, call center authentication, remote authentication with biometric data, and speed up the

authentication process when traveling using biometric data. In the future, Shocard intends to enter

sectors such as the medical industry and education.

Regarding the maturity of this project, it is at a very early stage. The beta phase started in August

2018 and it is not possible yet to have personal identifications validated by Shocard.

Although some of the use cases of Civic, uPort, and Shocard may be similar, this Shocard has some-

thing unique. Shocard will allow users from all over the world to scan (take photos) of their documents

in order for them to be added as digital identifications. This means that Shocard will do KYC at a level

16

that no other digital service does. Which means that Shocard needs to be prepared to receive different

identifications from all over the world.

Shocard is the only service explained in the thesis that does not rely on a single blockchain. It works

as a layer above blockchain, allowing it to be implemented on top of both private and public blockchains.

Regarding the storage of the user’s personal information, it is stored in the user’s App.

Figure 2.3: An overview of key elements of ShoCard, image retrieved from [3].

17

3Research Problem

Contents

3.1 Problem Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

19

3.1 Problem Identification

This Chapter presents the research problem, corresponding to the problem identification and motivation

step of DSRM.

To better understand how digital identity services can help Portuguese companies, we conducted

interviews with Chief Information Security Officers (CISO) of some Portuguese companies.

3.1.1 Interviews

In order to validate our problem, we conduct a set of interviews to CISOs of Portuguese companies. We

interviewed a total of six experts: five of them having more than twenty years of experience and one with

ten years of experience. The companies they work in range from 200 to 1200 employees and they work

in the financial or security sector. The interview was composed by 5 open answer questions.

1. What is your opinion regarding companies storing a lot of information about their users?

All the interviewed believe that it is an inevitable consequence of the digitization. In general, they

agree that people share too much personal information on the internet, specially on social media,

without knowing or caring about the consequences. There will always be a trade-off between what

people want and what they are able to give in return. There was a common phrase mentioned

throughout the different interviews: ”if it is free, you are the product”. Which is true, but once again

everyone agreed that the problem is the lack of awareness of the people in general.

One person noted that the most important thing is the maintenance of free will, because nowa-

days with companies selling information about their users and with direct target marketing, it can

become difficult.

2. Do you think it is important for the Portuguese population to control, in an easy way, who

can access their personal information?

In general, the answers were very similar. Everyone believes that giving more control and infor-

mation is a positive contribution to the people. However, they all agreed that people, in general,

are not aware of the information they share in social media and the possible consequences. First,

it would be important to raise awareness and educate citizens for them to take advantage of such

features in the future.

Some of the interviewed raised security questions. To create a service that could offer that kind

of information to the Portuguese Citizens, it would be essential to have that information secure in

order to avoid access to information by third parties.

21

3. Do you think it is possible to join several companies together in an ecosystem to share their

users’ personal information in order to make it easier to accelerate onboarding processes?

All the respondents agreed that it is possible, but it needs to be backed by laws. One of the

interviewed gave an example that in the financial sector, the onboarding process of a bank is

very similar for all the banks in Portugal because it is the information required by the Bank of

Portugal. In addition, every information comes from the same sources. However, with his 20 years

of experience in that industry, he believes that no bank will assume the responsibility of the truth

of the data.

4. Do you consider safe and feasible to use a decentralized digital identity service for regis-

tration and authentication?

In general, the interviewed answered that decentralization offers more safety because data is

distributed and replicated through the network. However, all of them were concerned with the

mechanisms that would be used to ensure security. First, the information should be validated

before being introduced to the platform. Second, care must be taken not to use expired information.

This ecosystem helps to prevent fraud and fraudulent account openings. One of the interviewed

mentioned that he believes the authentication without a username, password, and keyboard are

the future. However, it is important to have strong identity validators in the user’s App (biometrics,

pin code).

5. Do you consider that a company will easily adopt a digital identity service based on a per-

missioned or permissionless blockchain? Why?

Everyone believes that a company will most likely adopt a digital identity service based on a per-

missioned blockchain. Everyone mentioned how companies do not like to take unnecessary risks.

By making part of a public ecosystem where everyone can participate, it creates a massive risk

with the unknown. In addition, public blockchain allows users to be anonymous and have multiple

accounts. One expert shared an interesting problem, if a company has to go to court, it is impor-

tant to ensure that all data is unique and that it is not replicated by other users: this can only be

ensured by private blockchain.

3.2 Motivation

Digital identity has a vast amount of use cases. Everything that nowadays requires proof of identification,

can be transformed to use a digital identity instead. Password-less login is one of the uses cases that has

been used the most. With this kind of login, users do not need to know dozens of different passwords.

They only need to prove their identity usually by scanning a QR code or by using Touch ID [49].

22

A very similar use case is automated registration. When users want to create a new account in a

website, instead of filling the same information every time, they can just scan a QR code and transfer

all the necessary information to the website. Once again, avoiding friction between both parties. In

addition, there are also advantages of digital identity for call center authentications, proof of age, road

stops and others.

With the advent of Blockchains, the possibility of validating your own identity online creates an all-

new world of possibilities. With blockchain, it is possible to achieve decentralization and have a network

where institutions and users can interact with each other and request information to anothers. Because

it can be such a good solution, there are at the moment more than thirty projects and proof-of-concepts

in the literature taking similar approaches [46].

Although there are many projects, most of them are in a very early stage, meaning they have not

developed all their functionalists or they lack maturity making them not ready a production environment.

In addition, the most developed projects, such as uPort [41] and Civic [2] are developed on top of

Ethereum Blockchain. Ethereum is a permissionless blockchain thus every person can have has many

different identities as he wants. As it was mentioned previously, the interviews show that companies will

most likely adopt a service based on permissioned blockchain rather than based on a permissionless

blockchain.

A permissionless blockchain creates a perfect decentralization, however, it also disables the pos-

sibility to restrict the actors from the network, to create private channels of communication between

participants and to give different privileges and rules to different participants.

With a permissioned blockchain, it is possible to design a network that fits best in the Portuguese or

even in the European context. The related work presented in Chapter 2 shows that most projects are

either very generic (uPort) or very limited (Civic). In addition, although many projects claim that they

work for the whole world, they will always be more compatible in the country they were created. For

example, Shocard has their own KYC process, it will always work better with American citizens than

with Portuguese citizens because they will not see Portuguese identifications so often, thus they will not

know how to handle them properly or as fast as they should be.

Despite the fact that digital identity can solve multiples problems, this thesis will analyzes how digital

identity can help the banking industry to facilitate and improve the registration and the KYC process.

Know Your Customer, usually called as KYC is the process of a business verifying the identity of its

clients and assessing potential risks of illegal intentions for the business relationship [50]. In the banking

industry, the KYC process started to prevent and detect money laundering. Banks need to verify if the

customer is who he says he is and if he is in any prohibited list [51].

In the banking industry, the process to open a new bank account is laborious. According to a sur-

vey made in 2017 by Thomson Reuters [52], a bank takes an average of twenty-four days to complete

23

the customer onboarding process. In the banking industry, the process to open a new bank account

is laborious because it is divided into two phases: the time it takes for the user to provide the neces-

sary information and the time it takes the bank to validate the information. In addition, the number of

documents that a bank may ask may differ from bank to bank [53].

The current method used by banks to validate information has a big problem with scalability because

it is done manually, so the current way to solve it, is to hire more employees. That increases compliance

costs and the problem persists if the rate of new customers per day or per month grows. According to

the survey mentioned previously, the costs have increased 22% from 2015 to 2016 and another 18%

from 2016 to 2017. Also, financial institutions spend up to $500 million annually on KYC and customer

due to diligence [53].

Data freshness is another problem, both institutions and single users update their personal informa-

tion regularly. It can easily produce inconsistencies. In fact, according to a survey made by the Global

Entity Identifier Foundation (GLEIF), it is very common to have inconsistencies with updates. The GLEIF

questioned more than one hundred senior specialists and ”58% said the associated reference data is

not up-to-date, while 46% said reference data from different sources is inconsistent.” What’s more, 49%

said the same ID is used for different legal entities. [54]

Data portability, the concept of a reusable KYC started to solve that problem, but there is not a

standard with the information needed by banks, it is different for every country. Thus it is hard to create

a universal service that has enough information about its users. In addition, a service able to provide

every information needed to open a new account may also have centralization, trust and safety problems

associated.

3.2.1 Problem Statement

As previously mentioned, the current digital identity services will not properly work in Portugal. There is

a need to create a service focused on the European laws. In addition, we will explore the advantages

and disadvantages of using a permissioned blockchain instead of a permissionless blockchain.

In this thesis, we will conduct an research to answer the question: Can a digital identity service

based on a permissioned blockchain help the banking industry to facilitate the onboarding pro-

cess?

24

4Research Proposal

Contents

4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4 Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.6 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

25

4.1 Architecture Overview

As was previously explained, each step in the evolution of digital identity has pushed the boundaries

on the ability to create an identity that is independent of any centralized authority. A self-sovereign

identity may be great for the 1.1 billion people without identity [55]. However, for a developed country

like Portugal, an identity that is not backed by any trusted institution has a very low utility because it is

not credible.

Having that in mind, in this thesis we created the architecture that is in the middle of a self-sovereign

identity and a centralized identity. By having a permissioned blockchain, it adds a layer of security that

most of the current services do not offer, because participants need to be accepted in the network.

To be accepted, users have to prove their real identity and in this case, by showing their citizen card.

In this architecture, every participant (user) has a unique identifier, and it was decided to use the Por-

tuguese citizen number as the identifier. We believe that this way we create a more reliable service since

institutions in the network will always be sure of the person they are interacting with.

After this first process, users can freely submit all the information they want in their digital identity

application. This way, users have all the privileges of a self-sovereign identity without compromising the

root of their identity.

This section is followed by the five main components of the architecture, and in the next Chapter it is

demonstrated how this architecture was implemented.

4.2 Objectives

This section corresponds to the definition of the objective phase of DSRM.

In order to explore the possibilities of a permissioned blockchain for digital identity, our goals are the

following:

1. Create a digital identity service using a permissioned blockchain.

2. Create a Web Application, called PDID, to run and interact with the digital identity service.

4.3 Participants

A participant is an actor in the network. Portuguese Digital ID (PDID) is designed to be used by three

different type participants: (i) Person, (II) Institution and (III) Regulator.

The participant Person is the participant that will submit personal identifications to PDID, in this case,

every Portuguese Citizen. The participant Institution is linked to a company, institution or organization.

For last, the participant Regulator, since this use case is in the banking industry, it is important to have

27

a neutral participant. Regulators are allowed to read everything in the network and are responsible for

the creation of the participants Person and Institution. By allowing this kind of participants, PDID fails to

create a truly decentralized network because users of the network may be conditioned on the possible

malicious use of a Regulator. However, a Regulator is restricted to read information, not being able to

write or rewrite any personal information on another’s behalf.

4.4 Claim

Since the beginning, our goal has always been to create a digital identity network that works as the

base layer for multiple uses cases. The KYC in the banking industry is just one possible use case.

However, we took special attention when we were designing the attributes of a Claim to be able to use

the same architecture in multiples uses cases. This way, more Portuguese citizens will use the service,

maximizing its success.

A Claim is a ”statement that one subject, such as a person or organization, makes about itself or

another subject. For example, the statement can be about a name, group, buying preference, ethnicity,

privilege, association or capability. The subject making the claim or claims is the provider.” [56]

As it is explained previously, Hyperledger Composer uses Assets to represent abstractions of objects

with attributes. In this case, a Claim can be seen as an Asset. A Claim has 6 attributes:

• owner: The attribute owner is a link between the Participant and the Claim. A Participant can

have multiple Claims but a Claim can only have one owner.

• id: This attribute is the unique identification of a Claim. Every Claim in the network must have a

different id. It can be a random number or a string concatenated with an integer (e.g. ”CLM 001”).

• name: Since the definition of a Claim is very generic, a claim must have a name for what it

represents. For example, if a user wants to issue a claim saying his phone number, the claim’s

name should be something like ”phone number”.

Since the same claim can be represented by several different names (e.g. ”phone number” or

”phone), it is important to have a standard code for each type of claims.

• value: This attribute represents the claim’s information. For example, a value for a possible

Portuguese phone number would be ”923444555”. Once again, this attribute is represented by a

string, to allow more flexibility for the user.

• expireDate: This attribute represents the expiration date of the claim. It is an optional attribute

because some personal information may have an expiration date and another may not have. For

28

example, some attributes in the Portuguese Citizen card have an expiration date but the user’s

name does not have an expiration date.

• authorized: This attribute represents the list of Participants that are authorized to see the Claim.

This attribute is also optional because a user may not want to store information to share with

others. Instead of creating an empty array for every claim, it is created when it is needed.

4.5 Transactions

Giving the nature of PDID, it has two possible transactions. The first one is a grant permission transaction

(Listing C.1). It means that one participant Person can grant permission to a participant Institution to

see his claim. This transaction receives two parameters, the id of the claim (claim id), and the identifier

of the participant (id foreign), that will be allowed to check the claim. The smart contract responsible

for that transaction will first see if the authorized array of that claim is initialized and then it is added the

(id foreign) to the array.

The second one has the opposite functionality. It is a revoke access transactions (Listing C.2). It

means that one participant can revoke permission to another participant to see his claim. This trans-

action also receives two parameters, the id the claim (claim id), and the identifier of the participant

(id foreign), that no longer will be allowed to see the claim. The smart contract responsible for that

transaction will remove the (id foreign) from the authorized array.

4.6 Access Control

Hyperledger Composer has an Access Control Language (ACL) that provides elements of the domain

model with declarative access control. By defining ACL rules, the person that is building the network

can determine what users/roles in the domain model of a business network are allowed to create, read,

update or delete elements.

Rules are evaluated from the top (most specific) to bottom (least specific). As soon as the Participant,

Operation and Resource match for a rule then subsequent rules are not evaluated.

29

For PDID, the following rules were created:

• Every participant is allowed to create assets to themselves (Listing 4.1).

Listing 4.1: First access control rule

1 rule CreateDocument{

2 description: "Allow all participant to create assets"

3 participant(p): "org.hyperledger.composer.system.Participant"

4 operation: CREATE

5 resource(r): "org.hyperledger.composer.system.Asset"

6 condition: (r.owner.getIdentifier() === p.getIdentifier())

7 action: ALLOW

8 }

• Every participant is allowed to do transactions (Listing 4.2).

Listing 4.2: Second access control rule

1 rule EverybodyCanSubmitTransactions {

2 description: "Allow all participants to submit transactions"

3 participant: "org.hyperledger.composer.system.Participant"

4 operation: CREATE

5 resource: "org.identity.biznet.AcessTransaction"

6 action: ALLOW

7 }

• Every participant is allowed to see all his claims (Listing 4.3).

Listing 4.3: Third access control rule

1 rule OwnerHasFullAccessToTheirAssets {

2 description: "Allow all participants full access to their assets"


4 operation: ALL


6 condition: (r.owner.getIdentifier() === p.getIdentifier())

7 action: ALLOW

8 }

30

• A participant is allowed to see a claim from another participant if he has permission for that (Listing

4.4).

Listing 4.4: Fourth access control rule

1 rule ForeignHaslAccessToOwnersAsset {

2 description: "Other person has access to owner's documents"


4 operation: READ


6 condition: (r.authorized && r.authorized.indexOf(p.getIdentifier()) >

-1)

7 action: ALLOW

8 }

• A regulator is allowed to see everything in the network (Listing 4.5).

Listing 4.5: Fifth access control rule

1 rule RegulatorCanSeeEverything {

2 description: "A regulator can see everything in the network"

3 participant: "org.identity.biznet.Regulator"

4 operation: READ

5 resource: "**"

6 action: ALLOW

7 }

31

5Implementation

Contents

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Rest API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Client Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Institution Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

33

5.1 Overview

As mentioned before, our goal is to provide a digital identity for the Portuguese citizens. In Chapter 2, it is

shown that the current services providing a digital identity are composed of big teams and have been in

development for over two years. Having that in mind, we knew it was not possible to create a service as

complete as the ones we presented in Chapter 2, especially using features such as bio-metrics [57–59]

and claims verification.

In order to develop our service as far as possible, the smart contracts and business logic were

developed using Hyperledger Composer as planned and we used IBM cloud to create the Hyperledger

Fabric network.

Thus, we created the network presented in Figure 5.1. It is composed by two organizations, Org1

with a Certificate Authority CA1 represented as blue and Org2 with Certificate Authority CA2 as Orange.

Each organization has a peer, P1 in Org1 and P2 in Org2, and they are linked by channel C1. C1 is

governed by channel policy CP1. C1 has been established by consortium RARB and it is managed

by the ordering service O1 and the network is governed according to policy rules specified in network

configuration NP1. Having only one orderer, we used the consensus mechanism SOLO.

Figure 5.1: Diagram of Fabric Network

Since this service is a proof-of-concept, we created three institutions to simulate three different banks,

’BiG’, ’Bank B’ and ’Bank C’, although one institution was enough to test transactions. All the institutions

are connected to the same organization. In a real-world application, we would like to see a network

similar to the one presented in Figure 5.2, where different banks participate in the same network to

35

facilitate transactions of information between users and banks. In this case, different banks would be

associated with different organizations.

We also generated ten different users (Table 5.2) using [60,61]. Therefore, there is not any real data

being used. In the end, the blockchain had 285 blocks and a lifetime of 4 months.

Figure 5.2: A possible network composed by banks

5.2 Rest API

Hyperledger Composer allows to generate an API using Swagger [62]. The six main operations that are

possible using PDID API are presented in Figure B.1 . However, only 3 types of operations are relevant

for now, the first one is responsible to handle claim interactions: get, post and delete claims. The other

two main transactions operations are: grant access and revoke access.

In Listing B.1 it is presented an example of a possible post of a claim. It is a JSON composed with 7

fields. The first field represents the type of asset, but in this architecture we only have one type of asset

which are the claims, so this field is the same for all the claims. The other six fields were explained in

Chapter 4.

Similar to the post of a claim, the first field of a grant and revoke transaction represents the type of

transaction we are introducing. The second field is which claim it is referring, the third field the participant

that will be granted of revoked the access, and the last is the timestamp of the post B.2.

36

Figure 5.3: Diagram of the network interacting with the Rest API

5.3 Client Application

We decided to create a web application because of its versatility, it works across different electronic

gadgets and across different operative systems. So, to design and build the front-end of the app it was

used HTML [63] and CSS [64]. For the back-end, logic and API calls, it was used javascript [65] with

JQuery [66]. In addition, it was also used bootstrap 4 [67] to create a responsive app, providing a better

mobile experience.

As explained in Chapter 4, the same type of claim can have different names, (e.g. ”phone number”

or ”phone”). In order to prevent users from using different representations of similar claims, it was

decided to provide a set of default claims: Name, Phone no, Civil ID, NIF, Age, Sex, Height, Nationality,

Social Security, Health No, Student ID, Student University, Drivers Licence, Address and Profession. By

defining the claims that can be introduced in the service, it creates a standardization, allowing companies

to query information about their users easily.

PDID also provides a login to add a layer of security. It is composed of a username and a password

and in this case, the username is the user’s citizen number. The creation of new digital identities is done

manually and it can only be done with admin or regulator privileges. This way, it is possible to simulate

the bind of a real person with a digital identity.

The App shows every claim in the main screen. The timestamp with the last update appears on the

right side of each claim. The name, value and institutions allowed to see the claim appears on the left

side (See Figure 5.4). In the main screen, the App allows users to manage their claims by clicking on

them and by clicking in the button ”Add Identification”, the user can create a new identification (claim).

37

Figure 5.4: Client’s App example

5.4 Institution Application

The foundation of this application was based on the first one, it was also developed using HTML, CSS,

javascript and Bootstrap 4. Similar to the first application, in the main screen also appears every claim

that the institution is allowed to see. However, this application has different features, it allows institutions

to query and filter information, for example, all claims by a user or all participants by type of claim.

Second, companies can ask users to have grant claims in their behalf. This feature is very important

for BiG and other banks because it allow them to ask the necessary information for onboarding all at

once. In a more advanced scenario, that information could be authenticated, allowing users to create

new bank accounts in seconds.

38

Table 5.1: Banks used

Name IDBiG I 123Bank B I 456Bank C I 789

Table 5.2: Banks used

Name IDBennie Owen 808911231Jesse Reid 407350016Bennie Hussain 224617923Lesley Lloyd 936481552Fran Francis 542554683Jackie Mills 131725913Caden Carroll 718584329Ryan Gould 816109452Jo Black 951774933Vic Mcguire 757205355

39

6Evaluation

Contents

6.1 Proposed Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.3 PDID Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.4 Discussion of PDID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

41

6.1 Proposed Evaluation

There are many benefits that digital identity can provide to organizations, as pointed out in the research

literature. With the vast amount of alternative services to support its implementation, selecting the one

that fits in the organization’s needs is still one of the most difficult decisions due to the lack of guidelines

and meaningful criteria to help decision makers.

To address it, a method to evaluate identity management services using an MCDA approach called

MACBETH was proposed. A literature review was made to extract criteria that would be proposed as

a basis to all the decision process, which would then be validated by the DM. Using DM’s judgments,

the most overall attractive alternative was found and recommended to the company, solving their initial

problem. This method has a particular focus on a multiple-criteria evaluation process and the tool’s core

concern was security, confidentiality, and regulation since it was applied in a Portuguese bank. Four

services were evaluated: uPort, Civic, Sovrin, and Shocard.

In this thesis, we also propose a guideline for companies to compare different digital identity services

based on their interests. This framework is composed of the following 5 steps:

• Identify the problem

In the first step, the goal is to identify the problem. It is important that the decision maker (DM) has

a clear idea of the problem and the features that a service must have to solve it.

• Identify the criteria

This step consists in identifying the criteria to evaluate identity services. Here, the decision maker

must create criteria based on the problem identified in the first step.

For each criterion, it is necessary to do a qualitative or quantitative indicator of the performance to

measure if the criterion is satisfied.

Also, a criterion can automatically exclude a service from the assessment if the criterion is not

fulfilled. It was created a template with a possible criteria and it is presented in the next section. In

any case, a DM can always select other evaluation criteria or descriptors of performance in order

to meet specific organization’s needs.

• Weight the criteria

In this step, a value function is built for each criterion from the preferences of the DM. There are

two references for each criterion - “neutral” and “good”. Then, the decision maker must judge the

difference in attractiveness between every two levels of performance. According to the MACBETH

semantic, there are 6 categories: very weak, weak, moderate, strong, very strong, or extreme.

Lastly, M-MACBETH, the software that facilitates the use of MACBETH, uses a linear programming

problem to generate a numerical value scale, representative of the DM’s judgments.

43

According to the MACBETH methodology, each criterion should be weighted according to ranks

attribute by the decision maker. To start, the neutral-good swings are ranked, afterward, as it

was done with the performance levels, the DM should use the MACBETH semantic categories to

judge the difference in attractiveness between every two neutral-good swings. The M-MACBETH

software uses it to create a weighing scale for all criteria. To finish, the DM can validate the

proposed weights, see if agrees and adjust if necessary.

• Analyze documentation

This step is crucial to make a good judgment of the service. It is important to read the docu-

mentation and the white paper to understand what the service can and cannot do. This area is

continually improving, but at the moment there is not a single product that is completely ready. So

it is essential to see the road-map and check if the team is developing on time and too see the

features that are already available to use.

• Analyze the results

In this step, the performances of the alternatives are transformed into value scores. The value

functions already built for each criterion are used. An overall value score is calculated for each

alternative using the weighted summation of its value scores. To finish, a final ranking of the

alternatives using the overall scores should be performed. A robustness and sensitivity analysis

should also be done in order to evaluate how volatile the model is too small changes.

6.2 Demonstration

Over the rest of this Chapter, it is demonstrated how the guideline helped to evaluate and compare

the different digital identity services. For this demonstration was also done at Banco de Investimento

Global and it was done at the beginning of this thesis. It was based on the results obtained that the DM

concluded that none of the existing services was ready to be used and it would be better to create on

from scratch. For that motive, this demonstration does not include PDID because it was not developed

at that time. PDID is evaluated at the end of this Chapter.

6.2.1 Identify the problem

In order to identify the problem, we had a meeting with the decision maker, which is a board member

at the bank. After some meetings, we came to the conclusion that the bank would like to explore the

advantages of joining digital identity with KYC verification.

How can digital identity improve the speed of account creation by facilitating the KYC pro-

cess?

44

6.2.2 Identify the criteria

After having a clear vision of the problem, the next step is to create or choose the criteria that can be

applied in the context of the problem. In our first approach, we created our own criteria. However, we

came to the conclusion that it was too technical, not giving good results. Then, we decided to use ISO

9126-1 standard [28]. The ISO 9126-1 fulfills the basic software requirements, but it was decided to add

specific ones that were important for the bank. Thus, the final criteria are presented in Table A.1.

The numerical scales were anchored on the value scores 50 and 100, which were assigned to the two

reference levels “neutral” and “good”, respectively. Those scales were proposed by the M-MACBETH

decision support system based on the set of judgments made by the DM, who then analyzed and vali-

dated them. Using the validated value scales, M-MACBETH computed their value functions. To weight

the criteria, neutral-good swings were ranked by the decision maker for all the criteria by their overall

attractiveness. Then, the decision maker used MACBETH semantic categories to judge the differences

in attractiveness between each two of them. Finally, with those judgments, the M-MACBETH created a

weighing scale that was validated by the decision maker and shown in Figure 6.1.

6.2.3 Weight the criteria

During this third step, we acted as decision analysts in order to facilitate the process. The DM decided

some criteria had the same importance, thus we ended up clustering them into three groups. Security,

Laws and Regulations and Confidentiality were equivalently the most important ones. Then followed by

Maintainability, Reliability, and Type of Blockchain. The last group was Efficiency, Functionality, Portabil-

ity, and Usability.

Using M-MACBETH software, we compared each criterion against each other having, in the end, the

result presented in Figure 6.1.

6.2.4 Analyze documentation

In this step, it was analyzed in detail the papers from uPort [41], Shocard [48], Civic [2] and Sovrin [68].

6.2.5 Analyze the results

The performances obtained in the fourth step were inputted in M-MACBETH. Using the value functions

built in the second step, this software transformed the performances into value scores, presented in

Figure 6.2, and calculated the overall scores for all selected services. The uPort service ranked first with

82,14 overall units followed by Civic with 80,36 overall units. Shocard became third with 78,58 overall

45

Figure 6.1: Weighing scale for each criteria.

units and Sovrin was the worst with 60,70 overall units. The results clearly show that uPort has a good

performance in all the criteria. None of the existent services is complete and ready for a production

environment.

Figure 6.2: Overall value scores of the alternatives

uPort does not have the highest score in the “Security” criterion. A sensitivity analysis on the weight

of criterion “Security” showed that the weight of this criterion needed to be raised up from 17.85% to

20.7% to see Civic be ranked first. A robustness analysis was also made with M-MACBETH, consid-

ering simultaneous variations of ±1% on the weights of all criteria, not allowing negative weights. This

analysis showed that uPort continues to be the best alternative within these variations on the criteria

weights. Figure 6.3 shows the results of this analysis, where the green crosses in the cells mean that

the alternative in a row, uPort, dominates all the other alternatives in columns Civic, Sovrin, and Shocard.

46

Figure 6.3: Robustness analysis

6.3 PDID Evaluation

In the beginning of this Chapter, it is proposed a new method to evaluate and compare digital identity

services. Then, it is demonstrated by comparing uPort, Civic, Shocard and Sovrin. Now, it will me

evaluated PDID using the same criteria defined in Table 6.1. This way, it will be possible to compare

PDID against the state of the art services.

• Usability: PDID is very simple and be used and can be used by a wide range of ages - This

criterion is fully completed.

• Maintainability: This criterion can not be evaluated since PDID is a PoC - This criterion is not

fulfilled.

• Efficiency: Transactions take less than one second and Hyperledger Fabric is scalable very easily

- This criterion is fully completed.

• Portability: PDID was not developed a mobile application, only a web application - This criterion

is half fulfilled.

• Reliability: PDID is not ready for a production environment, it is currently in a proof of concept

phase - This criterion is half fulfilled.

• Functionality: The service only allows to request personal information for users. Information that

could possibly be used for registration processes - This criterion is half fulfilled.

• Security: PDID protects the users’ accounts by asking for a username and password - This crite-

rion is half fulfilled.

• Type of blockchain: PDID uses a permissioned blockchain - This criterion is fully completed.

• Laws and Regulations: PDID is not subject to laws and regulations to protect clients against all

kind of irregularities in the providers country - This criterion is not fulfilled.

47

• Confidentiality and data loss: The information is restricted to authorized people - This criterion

is fully completed.

6.4 Discussion of PDID

PDID is a proof-of-concept digital identity service created at Banco de Investimento Global. Regarding

its architecture, it offers the main requests asked by BiG:

(i) it uses a permissioned blockchain;

(ii) claims are restricted to authorized people;

(iii) it allows institutions to request information about users;

(iv) it allows institutions to request a batch of claims necessary for a KYC in the banking industry;

(v) it is easily scalable to create a real network.

Despite the simplicity of PDID’s interface, it allows users to introduce their personal identifications

and manage them, letting users to decide who can have access to the information, creating for the first

time, an eco-system where Portuguese citizens are in control of their information. Further, institutions

can request information about their current and new users. This feature is very important because it

solves two of the problems identified in the Motivation: it facilitates the onboarding process because a

bank can request all the necessary information once; and they have a source where the information

about their users is always updated.

Due to the nature of PDID, we decided to not assess the Maintainability and Laws and Regulations.

However, using IBM Cloud Platform, we were able to calculate that our service had an uptime of 100%

and its average response time was 0.65 seconds.

A digital identity service compliant with GDPR [69] is very important for BiG and for all industry. We

did not explore further in this area because it was out of our scope. However, it is encouraged in the

next Chapter to continue this research and to explore how PDID can be in compliance with GDPR.

The overall score of PDID is 53,58. Although it has the lowest score, the intention behind this thesis

was never to create the best overall service, but to build a different approach and show that it is a viable

option to use a permissioned blockchain instead of a permissionless one.

uPort has the best score, it is currently the most developed service and it has more than twenty

developers working in that project. As explained in Chapter 2, uPort allows users to emit credentials,

being possible to use it to issue claims. However, uPort does not offer any standardization when issuing

claims, making it more difficult for companies to automate tasks. On the other hand, PDID was designed

to be used by a group of companies that share a common goal. By following claim standards, it makes

it easy for companies to use and share that information.

The idea of a reusable KYC: information validated once and used multiple times; came from Civic.

48

Even though Civic did not implement their feature of reusable KYC, we implemented in PDID a version

of it. PDID has a feature that allows companies to request every information necessary for an onbording

in one batch. In a real network, only the first bank would need to validate that information and then it

could be transferred to other banks without needing to validate it again.

With this evaluation, we concluded that the four services evaluated have something in common:

they desire to be global. We concluded that trying to create a service that works everywhere does not

necessarly mean that they will have more users. As a matter of fact, none of the services has a relevent

number of users, and their users are in majority tied to to the country where they were created. For

example, uPort works well in Switzerland and Shocard in the United States and consequently they have

more users in those countries.

We proved with this thesis that if a group of companies in Portugal wants to create a private network,

it is possible to accomplish it without being bound to an existent service, the service would be more

restricted, with its pros and cons. It is up to the company or the group of companies to decide which

alternative is better for them.

49

Table 6.1: Criteria

Criteria Good NeutralUsability The service can be used

transparently by all age inter-vals of population.

Targeted to certain age inter-vals.

Maintainability Uptime above 99% and Sup-port 24/7 - When there is anincident, application Service-Level Agreement (SLA) re-covery takes less than anhour.

Uptime below 99% and Sup-port 24/7 - When there is anincident, application SLA re-covery takes more than anhour.

Efficiency Apps have a interaction re-sponse time below 2 second.

Apps have a interaction re-sponse time above 2 sec-onds.

Portability The service has both mobileand Web based desktop ap-plication and can be used ina all kinds of devices and op-eration systems.

The service only has Webbased desktop Application.

Reliability The service is ready to usein a production environment- passed through quality as-surance tests

The service is ready to betested only - create tests,proofs-of-concept and usecases.

Functionality The service allows the com-pany to use it for securelogins and for registrations(KYC) and new functionali-ties are developed and deliv-ered with a clear roadmap.

The service allows the com-pany to use it for securelogins and no clear publicroadmap exists for the appli-cation.

Security The service uses one ormore mechanisms to securethe information. (e.g. biomet-rics and/or Multiple factor au-thentication solutions)

The service does not provideany mechanism to secure theinformation.

Type of blockchain The service uses a permis-sioned blockchain (privateblockchain).

The service uses a permis-sionless blockchain (publicblockchain).

Laws and Regula-tions

The service is subject to lawsand regulations to protectclients against all kind of ir-regularities in the providerscountry.

The service is subject tolaws and regulations only toprotect clients against datalosses in the providers coun-try.

Confidentiality anddata loss

The information is restrictedto authorized people andcan be integrated withRole-Based Access Con-trol (RBAC) platforms.

The information is not re-stricted to authorized people.

50

7Conclusion

Contents

7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

51

7.1 Conclusion

In this thesis, we explored whether digital identity using permissioned blockchains can provide value for

organizations, in particular in the banking industry.

We started by conducting a set of interviews with Chief Information Security Officers of Portuguese

companies to understand their needs regarding a digital identity service. We found that uPort, Civic,

Shocard and Sovrin were the most advanced and developed services available. Yet, we discovered that

there were no guidelines to compare or evaluate them. Thus, our first contribution was a paper that is

currently under review for the Journal of Information Systems where we proposed a new framework to

evaluate digital identity services.

Based on the evaluation, we discovered that the market does not offer a few important features

that companies value. With the feedback from the interviews and from Banco de Investimento Global,

we realized that companies will mostly prefer permessioned blockchains and the current alternatives

do not provide that option. Thus, we are proposing a digital identity service based on a permissioned

blockchain, called PDID.

PDID uses an Hyperledger Fabric network with the smart contacts developed in Hyperledger Com-

poser. Like other services, it allows users to share personal information with other companies in a more

accessible and convenient way. The fact that PDID is based on a permissioned blockchain gives a

certain comfort to the participants in the network because they know who is on the other side of the

transaction.

As we explained in the related work, every service claims to be generic and work across different

industries and different countries. However, after our evaluation, we realized that it is not that simple and

straightforward. Having that in mind, PDID was developed to work with Portuguese citizens and with its

focus on the banking industry, although it was designed to be used other industries and used cases with

little or even zero alterations.

In Chapter 6, we concluded with our evaluation that our architecture is as competitive as the current

alternatives, but the overall service can be improved with a better interface, allowing users to authenticate

themselves with biometric data and by offering a native mobile application.

Finally, this thesis made the first step towards the possible first decentralized ecosystem of Por-

tuguese companies and citizens in an attempt to remove physical proofs of identity by creating advan-

tages for both parties.

53

7.2 Limitations

Thought this research, we found a few limitations with our proposal:

• The architecture presented in Chapter 4 is strongly coupled with Hyperledger and its implemen-

tation. Although the architecture can be adapted to other blockchains, its 4 key elements: (i)

Participants, (ii) Claims, (iii) Transactions and (iv) Access Control; are the four main elements of

Hyperledger Composer.

• For the demonstration, it was used IBM cloud to create the nodes and deploy the smart contracts.

IBM cloud allows a quick and simple deploy of the network, but in return, each node on the network

has a cost of approximately 1000$/month. With this monthly price, small companies may not be

able to participate as nodes because it ends up being a big expense annually.

• The proof of concept created for the demonstration has only one orderer. With only one orderer,

the network does not tolerate faults.

• It is not possible to add photos or videos to the blockchain as a form of a claim. Nowadays,

every online KYC requires photos of a document (citizen card, passport, drivers license, etc) and

sometimes a specific video to prove that the person is who he says he is.

7.3 Future work

The previous section explains the limitations found in this research. For future work, there are several

research opportunities that can be addressed:

• Create a network with more than one orderer, allowing to use Kafka consensus instead of SOLO.

• Allow users to post photos and videos on PDID. It can be done using IPFS. Instead of storing the

value of the claim in the attribute value, it can be used to store the hash on an image or video

posted in the IPFS. Creating a new very important feature.

• Expand PDID to other use cases. Blockchain gained a lot of traction to store medical records and

educational certificates. Is it necessary to have a different blockchain for every single use case?

Or can all these use cases can be aggregated into PDID? This two questions can give a good

topic of research.

• Finally, it would be interesting to make a real mobile application for users. Investing in two aspects:

(i) create an App that is intuitive and that values the user experience, (ii) create better mechanisms

for authentication, for example, the use of biometric data.

54

7.4 Communication

This section corresponds to the last step in the DSRM, the Communication.

During the writing of this thesis, we created a framework to evaluate and compare digital identity ser-

vices. In order to communicate our contribution to the scientific community, we wrote a paper submitted

to the Journal of Information Systems.

In addition, we will also submit a paper to the Journal of Information Security to present the results

of this thesis.

55

Bibliography

[1] K. Peffers, T. Tuunanen, M. Rothenberger, and S. Chatterjee, “A design science research

methodology for information systems research,” J. Manage. Inf. Syst., vol. 24, no. 3, pp. 45–77,

Dec. 2007. [Online]. Available: http://dx.doi.org/10.2753/MIS0742-1222240302

[2] C. T. inc, “Civic (cvc)-whitepaper -,” 2017.

[3] P. Dunphy and F. A. Petitcolas, “A first look at identity management schemes on the blockchain,”

arXiv preprint arXiv:1801.03294, 2018.

[4] P. J. Windley, Digital Identity: Unmasking identity management architecture (IMA). ” O’Reilly Media,

Inc.”, 2005.

[5] K. Jordan, J. Hauser, and S. Foster, “The augmented social network: Building identity and trust into

the next-generation internet,” First Monday, vol. 8, no. 8, 2003.

[6] D. Recordon and B. Fitzpatrick, “Openid authentication 1.1,” Finalized OpenID Specification, 2006.

[7] D. Recordon and D. Reed, “Openid 2.0: a platform for user-centric identity management,” in Pro-

ceedings of the second ACM workshop on Digital identity management. ACM, 2006, pp. 11–16.

[8] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, “Openid connect core 1.0

incorporating errata set 1,” The OpenID Foundation, specification, 2014.

[9] E. Hammer-Lahav, “The oauth 1.0 protocol,” Tech. Rep., 2010.

[10] D. Balfanz, B. Hill, and J. Hodges, “Fido uaf protocol specification v1. 0,” 2013.

[11] C. Allen, “The path to self-sovereign identity. retrieved from http://www.lifewithalacrity.com/2016/04/

(november, 2018),” 2018.

[12] C. A. B. E. Costa and J.-C. Vansnick, “The macbeth approach: Basic ideas, software, and an

application,” in Advances in decision analysis. Springer, 1999, pp. 131–157.

57

http://dx.doi.org/10.2753/MIS0742-1222240302

[13] E. Androulaki, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh,

K. Smith, A. Sorniotti, C. Stathakopoulou, and et al., “Hyperledger fabric,” Proceedings

of the Thirteenth EuroSys Conference on - EuroSys ’18, 2018. [Online]. Available:

http://dx.doi.org/10.1145/3190508.3190538

[14] A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design science in information

systems research,” MIS Q., vol. 28, no. 1, pp. 75–105, Mar. 2004. [Online]. Available:

http://dl.acm.org/citation.cfm?id=2017212.2017217

[15] S. T. March and G. F. Smith, “Design and natural science research on information technology,”

Decision support systems, vol. 15, no. 4, pp. 251–266, 1995.

[16] R. Winter, “Design science research in europe,” European Journal of Information Systems, vol. 17,

no. 5, pp. 470–475, 2008. [Online]. Available: https://doi.org/10.1057/ejis.2008.44

[17] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science research

methodology for information systems research,” Journal of management information systems,

vol. 24, no. 3, pp. 45–77, 2007.

[18] N. Szabo, “Formalizing and securing relationships on public networks,” First Monday, vol. 2, no. 9,

1997.

[19] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk: The blockchain

model of cryptography and privacy-preserving smart contracts,” in 2016 IEEE Symposium

on Security and Privacy (SP), vol. 00, May 2016, pp. 839–858. [Online]. Available:

doi.ieeecomputersociety.org/10.1109/SP.2016.55

[20] Ethereum, “Ethereum white-paper,” 2015. [Online]. Available: https://github.com/ethereum/wiki/

wiki/White-Paper

[21] D. Gavin and W. Cto, “Ethereum: A secure decentralised generalised transaction ledger,” 2014.

[22] E. Androulaki and e. A. Barger, “Hyperledger fabric: A distributed operating system

for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference, ser.

EuroSys ’18. New York, NY, USA: ACM, 2018, pp. 30:1–30:15. [Online]. Available:

http://doi.acm.org/10.1145/3190508.3190538

[23] C. Cachin, “Architecture of the hyperledger blockchain fabric,” in Workshop on Distributed Cryp-

tocurrencies and Consensus Ledgers, vol. 310, 2016.

[24] J. Sousa, A. Bessani, and M. Vukolic, “A byzantine fault-tolerant ordering service for the hyperledger

fabric blockchain platform,” in 2018 48th Annual IEEE/IFIP International Conference on Dependable

Systems and Networks (DSN). IEEE, 2018, pp. 51–58.

58

http://dx.doi.org/10.1145/3190508.3190538

http://dl.acm.org/citation.cfm?id=2017212.2017217

https://doi.org/10.1057/ejis.2008.44

doi.ieeecomputersociety.org/10.1109/SP.2016.55

https://github.com/ethereum/wiki/wiki/White-Paper

https://github.com/ethereum/wiki/wiki/White-Paper

http://doi.acm.org/10.1145/3190508.3190538

[25] IBM, “Blockchain component overview.” [Online]. Available: https://cloud.ibm.com/docs/services/

blockchain?topic=blockchain-blockchain-component-overview#blockchain-component-overview

[26] Hyperledger, “Hyperledger glossary.” [Online]. Available: https://hyperledger-fabric.readthedocs.io/

en/release-1.1/glossary.html#channel

[27] M. S. Paul, Hyperledger[U+200A]—[U+200A]Chapter 6 — Hyperledger Fabric

Components[U+200A]—[U+200A]Technical Context. [Online]. Available: https://medium.com/

swlh/hyperledger-chapter-6-hyperledger-fabric-components-technical-context-767985f605dd

[28] I. I. 9125, “Software product evaluation – quality characteristics and guidelines for their use,” 1991.

[29] I. ISO, “Iso 9126/iso, iec (hrsg.): International standard iso/iec 9126: Information technology-

software product evaluation,” Quality Characteristics and Guidelines for their use, pp. 12–15, 1991.

[30] V. Belton and T. Stewart, Multiple criteria decision analysis: an integrated approach. Springer

Science & Business Media, 2002.

[31] N. K. Jong and P. Stone, “Keeney, rl &raiffa, h. decisions with multiple objectives: Preferences and

value tradeoffs,” in In Proceedings of the ICML-06 Workshop on Kernel Methods in Reinforcement

Learning. Citeseer, 1976.

[32] W. Edwards, R. F. Miles Jr, and D. Von Winterfeldt, Advances in decision analysis: from foundations

to applications. Cambridge University Press, 2007.

[33] C. A. Bana e Costa, J.-M. De Corte, and J.-C. Vansnick, “Macbeth,” International Journal of Infor-

mation Technology & Decision Making, vol. 11, no. 02, pp. 359–387, 2012.

[34] J. C. Lourenco, A. Morton, and C. A. B. e Costa, “Probe—a multicriteria decision support system

for portfolio robustness evaluation,” Decision support systems, vol. 54, no. 1, pp. 534–550, 2012.

[35] A. Abraham, “Self-sovereign identity,” 2017.

[36] D. G. Birch, Digital identity management: perspectives on the technological, business and social

implications. Gower Publishing, Ltd., 2007.

[37] C. A. Bana e Costa, J.-M. de Corte, and J.-C. Vansnick, “Macbeth (measuring attractiveness by

a categorical based evaluation technique),” Wiley Encyclopedia of Operations Research and Man-

agement Science, 2010.

[38] D. D. F. Maesa, P. Mori, and L. Ricci, “Blockchain based access control,” in IFIP International Con-

ference on Distributed Applications and Interoperable Systems. Springer, 2017, pp. 206–220.

59

https://cloud.ibm.com/docs/services/blockchain?topic=blockchain-blockchain-component-overview#blockchain-component-overview

https://cloud.ibm.com/docs/services/blockchain?topic=blockchain-blockchain-component-overview#blockchain-component-overview

https://hyperledger-fabric.readthedocs.io/en/release-1.1/glossary.html#channel

https://hyperledger-fabric.readthedocs.io/en/release-1.1/glossary.html#channel

https://medium.com/swlh/hyperledger-chapter-6-hyperledger-fabric-components-technical-context-767985f605dd

https://medium.com/swlh/hyperledger-chapter-6-hyperledger-fabric-components-technical-context-767985f605dd

[39] A. Ouaddah, A. Abou Elkalam, and A. Ait Ouahman, “Fairaccess: a new blockchain-based access

control framework for the internet of things,” Security and Communication Networks, vol. 9, no. 18,

pp. 5943–5964, 2016.

[40] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “Medrec: Using blockchain for medical data access

and permission management,” in Open and Big Data (OBD), International Conference on. IEEE,

2016, pp. 25–30.

[41] J. T. Z. M. Christian Lundkvist, Rouven Heck and M. Sena, “uport: A platform for self-sovereign

identity,” 2017.

[42] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.

[43] Y. Liu, Z. Zhao, G. Guo, X. Wang, Z. Tan, and S. Wang, “An identity management system based on

blockchain,” in 2017 15th Annual Conference on Privacy, Security and Trust (PST). IEEE, 2017,

pp. 44–4409.

[44] J. Hammudoglu, J. Sparreboom, J. Rauhamaa, J. Faber, L. Guerchi, I. Samiotis, S. Rao, and J. A.

Pouwelse, “Portable trust: biometric-based authentication and blockchain storage for self-sovereign

identity systems,” arXiv preprint arXiv:1706.03744, 2017.

[45] D. G. Lowe, “Object recognition from local scale-invariant features,” in Computer vision, 1999. The

proceedings of the seventh IEEE international conference on, vol. 2. Ieee, 1999, pp. 1150–1157.

[46] Waque, Identity Managment Projects using Blockchain technology. [Online]. Available:

https://github.com/waque/Identity-Managment-Blockchain

[47] google, “google authenticator.” [Online]. Available: https://github.com/google/

google-authenticator-android

[48] ShoCard, “Travel identity of the future – white paper,” 2016.

[49] I. Cherapau, I. Muslukhov, N. Asanka, and K. Beznosov, “On the impact of touch {ID} on iphone

passcodes,” in Eleventh Symposium On Usable Privacy and Security ({SOUPS} 2015), 2015, pp.

257–276.

[50] wikipedia, Know your customer. [Online]. Available: https://en.wikipedia.org/wiki/Know your

customer

[51] M. Gill and G. Taylor, “Preventing money laundering or obstructing business? financial companies’

perspectives on ‘know your customer’procedures,” British Journal of Criminology, vol. 44, no. 4, pp.

582–594, 2004.

60

https://github.com/waque/Identity-Managment-Blockchain

https://github.com/google/google-authenticator-android

https://github.com/google/google-authenticator-android

https://en.wikipedia.org/wiki/Know_your_customer

https://en.wikipedia.org/wiki/Know_your_customer

[52] T. Reuters, Thomson Reuters 2017 Global KYC Survey, April

2019. [Online]. Available: https://www.thomsonreuters.com/en/press-releases/2017/october/

thomson-reuters-2017-global-kyc-surveys-attest-to-even-greater-compliance-pain-points.html

[53] ——, “Thomson reuters 2017 global kyc surveys attest to even greater compliance pain points,”

2017.

[54] G. L. E. I. Foundation. Gleif identifies that over half of salespeople in banking spend 27% of their

working week onboarding new client organizations. [Online]. Available: https://www.gleif.org

[55] worldbank, Counting the uncounted: 1.1 billion people without IDs, worldbank. [Online]. Available:

https://blogs.worldbank.org/ic4d/counting-uncounted-11-billion-people-without-ids

[56] Claim, Wikipedia, April 2019. [Online]. Available: https://en.wikipedia.org/wiki/Claims-based

identity

[57] N. K. Ratha, J. H. Connell, and R. M. Bolle, “Enhancing security and privacy in biometrics-based

authentication systems,” IBM systems Journal, vol. 40, no. 3, pp. 614–634, 2001.

[58] Z. Riha et al., “Toward reliable user authentication through biometrics,” IEEE Security & Privacy,

no. 3, pp. 45–49, 2003.

[59] A. K. Jain, R. Bolle, and S. Pankanti, Biometrics: personal identification in networked society.

Springer Science & Business Media, 2006, vol. 479.

[60] Fantasy Name Generators, April 2019. [Online]. Available: https://www.fantasynamegenerators.

com/english names.php

[61] random.org. [Online]. Available: https://www.random.org/

[62] April 2019. [Online]. Available: https://swagger.io/

[63] HTML, HTML, April 2019. [Online]. Available: https://pt.wikipedia.org/wiki/HTML

[64] CSS, CSS, April 2019. [Online]. Available: https://www.w3schools.com/cssref/

[65] JavaScript, JavaScript, April 2019. [Online]. Available: http://vanilla-js.com/

[66] jQuery, jQuery, April 2019. [Online]. Available: https://jquery.com/

[67] April 2019. [Online]. Available: https://getbootstrap.com/

[68] A. Tobin and D. Reed, “The inevitable rise of self-sovereign identity,” The Sovrin Foundation, 2016.

[69] P. Voigt and A. Von dem Bussche, “The eu general data protection regulation (gdpr),” A Practical

Guide, 1st Ed., Cham: Springer International Publishing, 2017.

61

https://www.thomsonreuters.com/en/press-releases/2017/october/thomson-reuters-2017-global-kyc-surveys-attest-to-even-greater-compliance-pain-points.html

https://www.thomsonreuters.com/en/press-releases/2017/october/thomson-reuters-2017-global-kyc-surveys-attest-to-even-greater-compliance-pain-points.html

https://www.gleif.org

https://blogs.worldbank.org/ic4d/counting-uncounted-11-billion-people-without-ids

https://en.wikipedia.org/wiki/Claims-based_identity

https://en.wikipedia.org/wiki/Claims-based_identity

https://www.fantasynamegenerators.com/english_names.php

https://www.fantasynamegenerators.com/english_names.php

https://www.random.org/

https://swagger.io/

https://pt.wikipedia.org/wiki/HTML

https://www.w3schools.com/cssref/

http://vanilla-js.com/

https://jquery.com/

https://getbootstrap.com/

AAppendix A

63

Table A.1: Current digital identity approaches using blockchain

Name Link

Shocard https://shocard.com/uport https://www.uport.me/sovrin https://sovrin.org/

ID2020 https://www.accenture.com/us-en/insight-blockchain-id2020ID Keys https://www.jlinc.com/individuals

Authenteq https://authenteq.com/Delloite SmartID http://www.deloitte.co.uk/smartid/

Civic https://www.civic.com/SecureKey https://securekey.com/

banqu http://www.banquapp.com/Cicada https://github.com/the-laughing-monkey/cicada-platformBitID http://bitid.bitcoin.blue/

2WAY.IO 2WAY.IOVerifyunion https://verifyunion.io/Trusted Key https://www.trustedkey.com/

Tradle https://tradle.io/Nuggets https://nuggets.life/SelfKey https://selfkey.org/taqanu https://www.taqanu.com/Boson https://boson.me/Kimlic http://kimlic.com/QED-it https://qed-it.com/Tierion https://tierion.com/

Persona https://persona.im/Atentcoin http://atencoin.com/Blockauth https://github.com/TechEndeavors/BlockAuth.com/blob/mater/Whitepaper.mdBitnation https://tse.bitnation.co/

Block Verify http://www.blockverify.io/Cambridge Blockchain LLC https://www.cambridge-blockchain.com/

Credits http://credits.readthedocs.io/en/latest/getting started.htmlExistenceID https://existenceid.com/

HYPR https://www.hypr.com/Identifi http://identifi.net/

Open Idenity Exchange http://www.openidentityexchange.org/about/KYC-Chain https://kyc-chain.com/

NetKi https://netki.com/SingleID http://singleid.com/

64

BAppendix B

65

Figure B.1: Rest API

Listing B.1: Post claim example

1 {

2 "$class": "org.identity.biznet.Claim",

3 "owner": {"resource:org.identity.biznet.Person#123456789"},

4 "id": "string",

5 "name": "string",

6 "value": "string",

7 "expiryDate": "2019-04-17T18:40:15.563Z",

8 "authorized": ["resource:org.identity.biznet.Person#111222333"]

9 }

Listing B.2: Post transaction example

1 {

2 "$class": "org.identity.biznet.GrantClaimAcessTransaction",

3 "asset": {"resource:org.identity.biznet.Claim#1555526906"},

4 "acessTo": "resource:org.identity.biznet.Institution#I123",

5 "timestamp": "2019-04-17T18:40:15.626Z"

6 }

66

CAppendix C

67

Listing C.1: Grant claim access transaction

1 /**

2 * Grant claim access transaction.

3 * @param {org.identity.biznet.GrantClaimAcessTransaction}

4 * @transaction

5 */

6 async function GrantClaimAcessTransaction(tx) {

7

8 let index = -1;

9

10 if(!tx.asset.authorized){

11 tx.asset.authorized = [];

12 }

13 else{

14 index = tx.asset.authorized.indexOf(tx.acessTo);

15 }

16 if(index <0){

17 tx.asset.authorized.push(tx.acessTo);

18 }

19 const assetRegistry = await getAssetRegistry('org.identity.biznet.Claim');

20 // Update the asset in the asset registry.

21 await assetRegistry.update(tx.asset);

22 }

Listing C.2: Revoke claim access transaction

1 /**

2 * Revoke claim access transaction

3 * @param {org.identity.biznet.RevokeClaimAcessTransaction}

4 * @transaction

5 */

6 async function RevokeClaimAcessTransaction(tx) {

7

8 const index = tx.asset.authorized ? tx.asset.authorized.indexOf(tx.acessTo) : -1;

9

10 if(index > -1){

11 tx.asset.authorized.splice(index,1);

12 }

68

13 const assetRegistry = await getAssetRegistry('org.identity.biznet.Claim');

14 // Update the asset in the asset registry.

15 await assetRegistry.update(tx.asset);

16 }

69

Identity Management with Blockchain

Documents

Transcript of Identity Management with Blockchain