A Blockchain Self-Sovereign Solution for Secure Generation, Exchange

and Management of User Identity Data

Nicolae Ghibu

, Augustin Jianu

, Alexandru Lupascu

and S¸tefan Popescu

Certsign, Romania

University of Bucharest, Romania

Keywords:

Blockchain, Self-Sovereign Identity Scheme, Authentication of Identity.

Abstract:

In this day and age the need for a secure and easy to use communication system between individuals and

service providers has grown past the point of it being a matter of comfort and has entered the ﬁeld of necessity.

The traditional paradigm for such a system used to be a centralized digital model, where the platform owner

was the main trusted 3rd party and maintained a log for each individual. This manner of providing and

exchanging identity data, through centralized digital entities, is inefﬁcient in terms of duplication, at best, and

it presents considerable risks for the users, at worst. The proposed system aims to be a practical solution to

these problems, being a self-sovereign identity scheme that can be used by governments, businesses, and users

that need to make a claim veriﬁcation alike.

1 INTRODUCTION

Digital identity authentication guarantees that indi-

viduals are who they claim to be or that they have

the necessary credentials to access a service. Sub-

ject authentication, along with protecting key infor-

mation, are two main objectives in identity manage-

ment. To avoid stealing and manipulating credentials

or having to reveal unnecessary information, some

service providers implement solutions that require

multi-factor authentication (Nagaraju and Parthiban,

2016), which further complicates the system. This

type of approach also allows the control and own-

ership of data to remain in the hands of the service

provider.

One alternative to having service providers en-

trusted with the storage and management of identity

data is for the owner of the actual data to be entrusted

with storing and managing their own credentials using

a personal or company device and only revealing the

necessary information required for a given direct in-

teraction with a service provider. This model is called

”Self-Sovereign” identity.

One of the main difﬁculties that needs to be ad-

dressed is the absence of any standard way to verify

digital credentials. Trusting third parties with your

data carries the risk of misuse or susceptibility to in-

tegrity threats. The blockchain is becoming the most

often used alternative in domains such as IoT security,

healthcare, business, and many others, where users do

not trust third parties and are aware of data collection

and its usage (Syed et al., 2019). Studies (Sharma

et al., 2020; Leka et al., 2019) have shown that smart

contracts over the blockchain have become increas-

ingly used in areas such as healthcare and education.

In their white paper (Sovrin Foundation, 2018),

the Sovrin Foundation proposed ”A Protocol and

Token for Self Sovereign Identity and Decentral-

ized Trust”, an open-source blockchain protocol with

an accompanying token that tackles the problem of

sovereign identity. They do this by ﬁrstly creating a

standard format for digital credentials that can eas-

ily be automated, and secondly by creating a standard

way to verify the source and integrity of said digital

credentials. For the second objective, they propose

a private/public key pair system - the ﬁrst used for

signing the document and the second used for ver-

ifying the signature. A blockchain, whether public

or private, seems to offer some of the desired advan-

tages, like being a decentralized root of trust that is

not owned by anyone but can be used by everyone or

every registered user, and thus seems ideal for serv-

ing as a decentralized self-service registry for public

keys.

Some (Lupascu et al., 2021) have identiﬁed cer-

tain problems with the speciﬁc implementation pro-

posed by the Sovrin Foundation. Namely, their de-

sign as a ”public global utility” requires the usage

744

Ghibu, N., Jianu, A., Lupascu, A. and Popescu, Å

A Blockchain Self-Sovereign Solution for Secure Generation, Exchange and Management of User Identity Data.

DOI: 10.5220/0012148800003538

In Proceedings of the 18th International Conference on Software Technologies (ICSOFT 2023), pages 744-750

ISBN: 978-989-758-665-1; ISSN: 2184-2833

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

of their Sovrin Blockchain, which has been designed

only for identity claims and for their own Sovrin To-

ken. This requires any organization that would like to

implement this solution to alter its business model for

compatibility reasons, such as accommodating crypto

assets like the Sovrin Token. Another identiﬁed prob-

lem is that an identity claimed veriﬁed by a third party

cannot be unilaterally revoked before the expiration

date by said third party. For example, a driver’s li-

cense or student pass cannot be revoked by the state

issuer or by the university, respectively.

In this paper, based on certSIGN’s patent appli-

cation (Lupascu et al., 2021), we present a novel

and ﬂexible solution to the self-sovereign identity

problem that not only addresses the core challenges

but also introduces the possibility of implementing

smart contracts between users. Our approach builds

upon existing an existing implementation and lever-

ages blockchain technology to create a secure and de-

centralized framework for identity management. The

project is currently in late stage development.

In the following sections, we will begin by provid-

ing essential background information about the pro-

posed solution, outlining its speciﬁc beneﬁts, and of-

fering practical examples to illustrate its functionality.

We will present an in-depth overview of our proposed

approach, starting with a basic use-case scenario and

addressing the potential challenges that can arise and

will delve into the roles and responsibilities of each

participant within the network, highlighting their in-

teractions. We will provide a chronological list of data

transactions within a generalized scenario, illustrating

the sequence of events and data ﬂow among the par-

ticipants. For better clarity, we will showcase a step-

by-step interaction between the different entities and

how they engage with the system. Finally, we will

draw conclusions based on our ﬁndings and discuss

potential avenues for future work.

2 THE PROPOSED SOLUTION

2.1 Overview

The solution (Lupascu et al., 2021) claims to meet

the self-sovereign identity requirements in a more

business-friendly way. Speciﬁcally, it can be imple-

mented over any type of blockchain, whether pub-

lic or private, and does not require the acquisition of

any speciﬁc crypto asset. While the proposed solu-

tion refers to Bitcoin as the blockchain in use for con-

venience purposes, it can be applied to any generic

blockchain. Because blockchains are immutable,

storing personal data on a blockchain is strongly dis-

couraged, even if said data is in encrypted form. Peo-

ple can reveal their private keys by mistake, and dig-

ital information can get leaked, so good practice dic-

tates that all the information stored on the blockchain

has to be hashed, and only the hashes are stored on

the blockchain. It is also assumed that blockchain

users carry digital identiﬁers that are used to iden-

tify them by way of digital signatures that accompany

each transaction they take part in. User identity infor-

mation can be hashed and then encrypted to be stored

on the blockchain at the time of enrolling the user on

the platform. Management trust is provided by a root

user/ platform owner that authorizes new users and

user roles, such a the role of a trusted third-party, by

recording their authorization on the blockchain.

Users have the ability to create their own digi-

tal identiﬁers and trusted third-party users can en-

roll identity owners (users who will use the plat-

form for their ID authentication) by collecting their

data in a secure way such as face-to-face veriﬁca-

tion, and storing encrypted hashes of the data on

the blockchain alongside the user’s digital identiﬁer.

Each data exchange between users must be authorized

by the trusted third-party that veriﬁed the user’s at-

tributes. This authorization process involves a multi-

stage veriﬁcation protocol that accesses information

stored on the blockchain. These interactions between

users, or between users and trusted third-parties are

also archived on the blockchain.

By utilizing information stored on the blockchain

and a user identiﬁer (ex: the user’s public key) pro-

vided by the user, a computing device can obtain a

particular assertion from the multiple proofs recorded

on the blockchain. The assertion obtained by the com-

puting device can be checked by using information

provided by the user, alongside a secret key, via the

blockchain, from a trusted third-party. The secret key

is generated based on two public keys: one associated

with the computing device that wants to check the as-

sertion and the other based on the computing device

controlled by the trusted third-party. This approach

allows users to choose which aspects of their identity

they want to share with information consumers.

For example, a student accessing a virtual library

might want to share a proof that containing their name

and university status, but not their home address. In

this scenario the library acts as the information con-

sumer, the student as the user, and the University that

emitted the student license as the trusted third-party.

The library wants to check the assertion that the user

is a student, and based on the user’s identiﬁer, infor-

mation stored on the blockchain, and after a exchange

of information with the University via the blockchain

with the aid of a secure communication protocol it can

A Blockchain Self-Sovereign Solution for Secure Generation, Exchange and Management of User Identity Data

745

conﬁrm, with a high degree of assurance, that the user

is actually a student or not, without learning any other

information about them.

One of the speciﬁc beneﬁts of the solution, de-

scribed later on in detail, is its independence of the

type of blockchain used and that it provides methods

by which a trusted third-party, that has veriﬁed the

identity claim of a user in the past, can revoke any

assertion that is based upon said past veriﬁcation.

The system architecture is speciﬁcally designed

to address the self-sovereign identity problem where

a reference dataset is associated with a user’s identi-

ﬁer (e.g., public key) and two computing devices are

involved. The ﬁrst device stores the identiﬁer along

with a high assurance level that a ﬁrst dataset accu-

rately represents the reference dataset, without stor-

ing the ﬁrst dataset itself. The second device stores

the identiﬁer with a second dataset that represents a

subset of the reference dataset. Without disclosing

the second dataset to the ﬁrst computing device, the

second device needs to verify, with a high degree of

certainty, that the ﬁrst dataset accurately represents a

subset of the reference dataset.

2.2 A Basic Use-Case Scenario and the

Problems that Can Appear

We present the following working scenario: An iden-

tity owner needs to provide speciﬁc data attributes to

an online service provider, who acts as a a data con-

sumer, in order to be provided a particular service..

The data attributes can be static, such as a social num-

ber, or dynamic, such as a residency, or the place

of work. When the data consumer requests the au-

thentication of a set of attributes claimed by the iden-

tity owner, the request is recorded on the blockchain

and then answered by one or more special attributed

”trusted third-party” users. This request is also asso-

ciated with identiﬁers for both the identity owner and

the trusted third-party, permitting the option of pay-

ment between the two for each such request. The re-

quest transaction can include additional information

that can be used by the trusted third-party to create a

secure mode of communication.

The role of the trusted third-party is essential be-

cause without them, data consumers would not be

able to verify, with a high degree of accuracy, that the

data attributes presented to them are authentic. On the

other hand, identity owners couldn’t easily share just

the parts of their data attribute that are relevant to the

service they want to access, without revealing a mul-

titude of other information. The solution presented

can overcome such challenges by allowing the iden-

tity owner to encrypt only speciﬁc data attributes to be

shared with a data consumer, providing the data con-

sumer with a secret key via a secure communication

protocol alongside the encrypted data attributes that

are needed for the service. The secret key can be en-

crypted with the data consumer’s public key. Further-

more, the blockchain can be an ideal system for shar-

ing these encrypted attributes and for the data con-

sumer to receive information on the assurance level

of said data attributes. The trusted third-party also

gets to share said information to the data consumer

without having to store copies of the data attributes in

question.

2.3 The Composition of the Computing

System

The computing system comprises a network of inter-

connected computing nodes that are associated with

at most one platform owner, at least one trusted third-

party, and a various number of data consumers and

identity owners. The platform owner has the ini-

tial role of authorizing network participants to verify

identities, giving them the status of a trusted third-

party, and deﬁning the types of data attributes that are

veriﬁed, shared, and validated. For example, the plat-

form owner can authorize a network participant, such

as a university, to verify identities for their students

and deﬁne such data attributes as a string representing

a student ID number, a date representing the year the

student enrolled, etc. But the platform owner might

not deﬁne information such a the home address of the

student.

The trusted third-parties are the network partici-

pants that verify the identity of other network partici-

pants with a high level of assurance.

The identity owners in the network are the partici-

pants that make their identity data attributes available

for distribution over the network.

The data consumers in the network refer to the

participants that receive data attributes over the net-

work and need to check their validity. Therefore, they

request and receive information regarding the assur-

ance levels of the identity assertions received over the

network. Depending on the implementation, a user

can have a single role in the network or multiple roles.

For example, a participant that has authorized other

participants as trusted third-parties might himself act

as a trusted third-party in certain situations, or even

an identity owner.

The blockchain ledger is composed of records

of all the transactions related to the digital identi-

ties of the participants, and the data attributes that

have been veriﬁed and distributed. These transac-

tions are recorded in chronological order and include

ICSOFT 2023 - 18th International Conference on Software Technologies

746

authorizations granted by the platform owner, at-

tribute veriﬁcation proofs submitted by trusted third-

parties, and authentication requests submitted by ser-

vice providers which act as data consumers.

In certain implementations, the ledger may also

contain executable programs known as ”smart con-

tracts.” These programs automate several aspects of

data sharing transactions, and they can be used to fa-

cilitate the performance of tasks such as identity and

data validation.

Overall, the blockchain ledger serves as a repos-

itory of all activity within the network which is both

secure and transparent It ensures that all participants

have access to the same information, and that all

transactions are executed in a trustworthy and ac-

countable manner.

2.4 Chronology of the Data

Transactions Being Submitted to the

Ledger

Transactions with a ledger always include at least the

public identiﬁer of the issuer, alongside a digital sig-

nature of the owner of said public identiﬁer. An il-

lustration regarding the following steps can be seen in

Figure 1.

The ﬁrst transaction on the ledger is performed

by the platform owner, in which they deﬁne what

identity data attributes are acceptable on the platform.

This should include a data payload consisting of data

attribute deﬁnitions that can also serve as reference

points in the ledger for other transactions made by

participants.

Another type of transaction performed by the

platform owner is to submit a data entry, designat-

ing other participants as an authorized trusted third-

parties. These transactions may also include the pub-

lic identiﬁer of the trusted participant, thus informing

other participants that the designated participants can

now act as a trusted third-parties.

A trusted third-party can submit a transaction that

stores on the ledger proofs of data attributes associ-

ated with the public identiﬁer of an identity owner.

The data attributes in question must be of the types

deﬁned by the platform owner.

A data consumer can receive one or more data at-

tributes from an identity owner and then issue an au-

thentication request by submitting a transaction on the

ledger. To initiate such a request, the data consumer

needs ﬁrstly identify the transaction on the ledger

where a trusted third-party stored data attribute ver-

iﬁcation proofs regarding the identity owner in ques-

tion, and then direct that request to the speciﬁc third-

party. Another approach would be associating the

identity owner’s public identiﬁer with a ”smart con-

tract” so that only the issuer of data attribute (a spe-

ciﬁc trusted third-party) is allowed to respond to the

the data consumer’s request. These types of transac-

tions may also include payments from the data con-

sumer to the trusted third-party.

The trusted third-party can respond to the request

submitted by the data consumer with their own trans-

action on the ledger. The response does not reveal any

of the data attributes of the identity owner but can be

used by the data consumer to prove, with a high level

of assurance, the authenticity of said data attributes.

Moreover, as mentioned before, the trusted third-

party can revoke previous transactions that verify the

data attributes of an identity holder. Veriﬁcation

proofs can also be revoked, which is useful in in-

stances where one or more data attribute deﬁnitions

become deprecated or are totally revoked.

2.5 Step-by-Step Illustration of

Interactions Between the Devices

Controlled by Network Participants

In this section, we will describe brieﬂy how each par-

ticipant interacts with each other, starting with the

attribution of roles, the deﬁnition of data attributes,

and the veriﬁcation of a particular data claim made

by an identity owner. An illustration of the steps is

presented in Figure 2.

The ﬁrst stage is when the platform owner deﬁnes

the particular data attributes that can be made avail-

able for distribution. The deﬁnition of a data attribute

should include at least an identiﬁer and one data type.

The computing device associated with the platform

owner records these deﬁnitions on the ledger as a ﬁrst

transaction, which can be used as a reference point for

future transactions.

In the next stage, the platform owner enrolls a

trusted third-party in the network, enabling them to

verify, with a high degree of certainty, authentication

claims and record veriﬁcation proofs. At this point the

platform owner records a transaction on the ledger,

making all other participants aware of the newly au-

thorized trusted third-party. This may sometimes in-

volve recording a public identiﬁer of the trusted third-

party. In other cases, the enrollment may require

recording several public identiﬁers, which may all be

authorized to act on behalf of the newly appointed

trusted third-party.

At the third stage, an identity owner uses their

computing device to generate a digital identiﬁer that

will be used throughout the network. In some imple-

mentations, this identiﬁer can be a public-private key

pair that will be further used to encrypt, decrypt, and

A Blockchain Self-Sovereign Solution for Secure Generation, Exchange and Management of User Identity Data

747

Figure 1: Generic transactions stored on the ledger by network participants.

sign data.

At the fourth stage, the identity owner presents ev-

idence of their data attributes to the trusted third-party

for veriﬁcation. This step requires a physical interac-

tion between the two involved parties. The identity

owner uses their computing device and the identiﬁer

generated in the previous stage to create a signed con-

sent for data attribute veriﬁcation and data processing,

and sends it to the trusted third-party.

At the ﬁfth stage, the trusted third-party generates

the resulting veriﬁcation proofs and stores them on the

ledger, alongside the identity owner’s consent. Some

variations of this step involve hashing each individual

data attribute and then encrypting them before storing

them on the ledger. The encryption is done by gen-

erating a secret key that the trusted third-party stores

in a tamper-resistant key manager on their computing

system. This same key will be used later on, at stage

nine, to decrypt the data attribute hashes.

In stage six, the identity owner’s computing de-

vice generates and signs an identity claim that in-

cludes their public identiﬁer generated in stage three,

as well as one or more attributes required to access

a service. This type of interaction is advantageous

in scenarios where the data owner does not wish to

disclose all of their attributes, but only the necessary

ones.

In stage seven, the identity owner sends the gener-

ated identity claim to a data consumer who is respon-

sible for identifying users requesting a particular ser-

vice. This stage usually involves establishing a shared

secret over an insecure channel.

In stage eight, the data consumer’s computer de-

vice generates an identity request that is stored on the

ledger. The request consists of the identity owner’s

previously obtained public identiﬁer and the identi-

ﬁers of the claimed attributes. In this type of proto-

col, the data consumer does not disclose to the trusted

third-party that will be charged with verifying the

identity claims the values of the attributes received by

the identity owner. The authentication requests also

includes information necessary to establish a secure

channel of communication between the two.

In stage nine, the computation device of a trusted

third-party responds to the previously generated re-

quest. The computation device checks the attribute

identiﬁers included in the request and extracts only

speciﬁc veriﬁcation proofs out of all the ones gener-

ated at stage ﬁve. If the request includes identiﬁers

for which there is no veriﬁcation proof, or that said

proofs have been revoked, then the request is met with

a failure to authenticate. Otherwise, the trusted third-

party conﬁrms the attributes of the identity owner us-

ing a secure communication protocol with the data

consumer.

At the tenth stage, the trusted third-party records

the veriﬁcation result on the ledger. This is necessary

in cases where there needs to be an unalterable record

of access to identity data without recording the actual

identity data or anything that might be used to recon-

struct it.

In stage eleven, the data consumer receives the re-

ICSOFT 2023 - 18th International Conference on Software Technologies

748

Figure 2: Step-by-step interaction of platform participants.

sult of the previous stage and determines the authen-

ticity of the identity claim received at stage seven.

The computing device of the data consumer reads the

response recorded on the ledger in the previous stage

and uses that information to build a secure commu-

nication protocol with the trusted third-party. Over

this secure communication system, the identity claim

is conﬁrmed by the trusted third-party via the recon-

struction of a message authentication code recorded

on the ledger in encrypted form at the previous stage.

This protocol is useful because, in this way, the data

consumer is left with unalterable proof that the trusted

third-party actually conﬁrmed the authenticity of the

identity owner’s claims.

At the last stage, the computing device of the data

consumer triggers the sending of a message to the

identity holder, informing them of the results. This

technique is useful in the scenario where the iden-

tity owner needs to receive a service over an untrusted

channel, but the data consumer needs to trust the data

provided by the identity owner.

3 CONCLUSIONS

The solution described in this paper offers a some-

what original approach to addressing the self-

sovereign identity problem. It provides a ﬂexible and

secure solution for communication between all net-

work participants via a blockchain alongside a pub-

lic/private key communication protocol. This allows

for a more secure information exchange between net-

work users, which is important when dealing with

identity attributes.

A main advantage of their proposed solution is the

ﬂexibility it grants, as it is independent of any speciﬁc

blockchain or crypto asset. This means that it can

be adapted to work with any blockchain, thus being

a signiﬁcant advantage for companies and organiza-

tions that already have a speciﬁc blockchain in place.

The solution is also able to offer a payment mech-

anism for each proof generated, which provides in-

centive for users to participate in the network and gen-

erate proofs only when necessary. This is important

because it helps ensure that relevant attributes are the

ones being checked. This can improve efﬁciency and

reduce error risk.

Most importantly, the solution is designed to work

under a zero-knowledge framework, which means

that it does not require the disclosure of any unneces-

sary information, thus ensuring the privacy and conﬁ-

dentiality of the identity users.

The use of a blockchain framework also pro-

vides signiﬁcant beneﬁts, namely it allows for the

secure distribution of data attributes among indepen-

dent users and service providers. This helps ensure

security, transparency, and access right management,

which are all critical factors when dealing with sensi-

tive information.

Another notable advantage of the proposed solu-

tion is its ability to record binary ﬁles on the ledger,

which can act as ”smart contracts” between network

participants. This allows for some more complex in-

teractions between network users, which greatly in-

creases the practical scenarios where it can be uti-

lized.

Overall, the solution proposed offers a ﬂexible and

secure approach to addressing the self-sovereign iden-

tity problem, with the potential to provide signiﬁcant

beneﬁts to organizations across a range of industries.

The main challenge with this approach lies in devel-

oping a governance framework that reaches a balance

between decentralized control and centralized over-

sight, fulﬁlling the needs and interests of the partici-

pants while ensuring compliance with legal and ethi-

cal standards.

Regarding future work, the proposed solution is

A Blockchain Self-Sovereign Solution for Secure Generation, Exchange and Management of User Identity Data

749

currently in its developmental stage and will undergo

various testing and reﬁnement as it reaches its beta

stage. Continuous collaboration with the develop-

ment team will be crucial for further enhancements

and improvements.

ACKNOWLEDGEMENTS

This research was supported by the European Re-

gional Development Fund, Competitiveness Oper-

ational Program 2014-2020 through project IDBC

(code SMIS 2014+: 121512)

REFERENCES

Leka, E., Selimi, B., and Lamani, L. (2019). Systematic lit-

erature review of blockchain applications: Smart con-

tracts. pages 1–3.

Lupascu, A., Jianu, A., and Ghibu, N. (September

2021). System and method for secure generation, ex-

change and management of a user identity data us-

ing a blockchain, european patent application number

20164682.5.

Nagaraju, S. and Parthiban, L. (2016). Secauthn: provably

secure multi-factor authentication for the cloud com-

puting systems. Indian Journal of Science and Tech-

nology, 9(9):1–18.

Sharma, A., Tomar, R., Chilamkurti, N., and Kim, B.-G.

(2020). Blockchain based smart contracts for inter-

net of medical things in e-healthcare. Electronics,

9(10):1609.

Sovrin Foundation (January 2018). A protocol and token

for self-sovereign identity and decentralized trust.

Syed, T. A., Alzahrani, A., Jan, S., Siddiqui, M. S.,

Nadeem, A., and Alghamdi, T. (2019). A compara-

tive analysis of blockchain architecture and its appli-

cations: Problems and recommendations. IEEE ac-

cess, 7:176838–176869.

ICSOFT 2023 - 18th International Conference on Software Technologies

750