Analysis and Enhancement of Self-sovereign Identity System Properties

Compiling Standards and Regulations

Charnon Pattiyanon and Toshiaki Aoki

Graduate School of Advanced Science and Technology,

Japan Advanced Institute of Science and Technology, Ishikawa, Japan

Keywords:

Self-sovereign Identity, Software Security, Legal and Regulatory Issues, Comparative Analysis.

Abstract:

A self-sovereign identity (SSI) system represents a paradigm shift in identity management by leveraging the

decentralization inherent in blockchain technology. The fundamental characteristics of the SSI system are

constrained by a set of guiding principles and system properties. While knowledgeable scholars and practi-

tioners have proposed such principles and properties, they have not yet been standardized. The SSI community

has agreed upon and adheres to the existing proposals when implementing the SSI system. Additionally, the

SSI system is used to manage personally identiﬁable information (PII), and compliance with certain standards

and regulations is required. We discovered that while the current proposals do correspond to some extent to

those documents, they cannot be characterized as explicitly compliant. We evaluate several well-known stan-

dards and regulations as credible sources in this work and compare them to the deﬁnitions in current proposals

in order to identify inconsistencies. Then, we propose a list of SSI system properties that could be used to

improve the security and privacy of the SSI system by addressing the inconsistencies discovered. We assess

its applicability in real-world scenarios and its appropriateness from an expert’s perspective. The proposed

properties yield meaningful results that may resolve the inconsistencies.

1 INTRODUCTION

A self-sovereign identity (SSI) system is a type of

service that utilizes blockchain technology to em-

power users with complete control over their person-

ally identiﬁable information (PII), which is securely

stored on a user-owned storage device. The funda-

mental concept is deﬁned by users’ ability to disclose

as little PII as necessary for service authentication and

authorization (Allen, 2016).

Due to the SSI system’s cutting-edge and so-

phisticated nature, deployment requires some effort

to familiarize oneself with its functions and con-

straints. Allen (2016) presented ten principles that

succinctly encapsulate the SSI system’s constraints,

regardless of the technology or method of implemen-

tation. Allen’s principles were regularly cited in the

majority of writings devoted to the SSI system. A

principle is a collection of succinct statements indi-

cating which expectations are critical and unique to

the SSI system. For instance, the existence princi-

ple (Allen, 2016) states that:

“Users must have an independent existence.

Any self-sovereign identity is ultimately

based on the ineffable ‘I’ that’s at the heart of

identity. It can never exist wholly in digital

form. This must be the kernel of self that is

upheld and supported. A self-sovereign iden-

tity simply makes public and accessible some

limited aspects of the ‘I’ that already exists.”

Principles serve as a starting point for discussions and

help to shorten the SSI system’s learning curve. Allen

did, however, acknowledge that the principles are still

subject to reﬁnement.

Naik and Jenkins (2020) was an attempt to reﬁne

Allen’s principles for compliance with the European’s

general data protection regulation (GDPR), with the

goal of preserving privacy in the SSI system. They

presented a set of 20 governing principles as an ex-

tension of Allen’s. Regrettably, their work did not

adequately identify links to the GDPR’s compliance

explicitly. Another attempt was published by Ferdous

et al. (2019). They aimed to do a thorough analy-

sis of the SSI system and extracted 17 system prop-

erties based on multiple sources, e.g., Allen’s article

and Sovrin

’s white paper (Tobin and Reed, 2017). A

An industry level solution to the SSI system.

Pattiyanon, C. and Aoki, T.

Analysis and Enhancement of Self-sovereign Identity System Properties Compiling Standards and Regulations.

DOI: 10.5220/0010877300003120

In Proceedings of the 8th International Conference on Information Systems Security and Privacy (ICISSP 2022), pages 133-144

ISBN: 978-989-758-553-1; ISSN: 2184-4356

133

property is identical to a principle, except that the sys-

tem and its components are the subjects. In Ferdous

et al. (2019) proposal, they used fundamental notions

and make no reference to standards or regulations.

Existing research identiﬁes gaps that motivate us

to enhance the security and privacy of the SSI system

through compliance with well-established standards

and regulations. A standard is a published document

that was developed collaboratively by members of a

community with the intent of assessing, controlling,

and measuring a target (i.e., an organization, factory,

system, or software). Through a series of principles,

policies, practices, and measures, the standard estab-

lished a benchmark for the target. On the other hand,

a regulation is a legal document created by national

governments. Quantiﬁable controls, endorsed tasks,

or mandatory principles for assessing or evaluating

the target were speciﬁed in the regulation. Regula-

tions are stringent, and violations will result in severe

legal consequences. For conciseness, we will refer to

standards and regulations as credible sources.

The remainder of this paper is organized as fol-

lows: Section 2 discusses a motivating problem; Sec-

tion 3 discusses current property proposals and the

controls imposed by credible sources; and Section 4

discusses our analysis method and results. Section 5

contains an evaluation of the enhanced properties;

Section 6 contains a discussion; and Sections 7 and 8

contain a comparison of related works and a conclu-

sion to this work.

2 MOTIVATION

As mentioned in Section 1, three recent proposals for

principles and properties have been made. Their pro-

posal, on the other hand, is neither clearly consistent

with credible sources nor does it include a reference

to credible sources. As such, we will illustrate a le-

gal and regulatory compliance issue that highlights

the need for property enhancement.

Assume we have a properly implemented SSI sys-

tem capable of validating and issuing claims in ac-

cordance with the fundamental notion. A user may

submit a claim, which is a brief statement attesting

to the accuracy of their personal information, and re-

quest validation from the relevant issuer. Following

the claim’s validation, the issuer creates a veriﬁable

version of it using a cryptographic schema published

on the blockchain and returns it to the user. We de-

pict the aforementioned scenario using a sequence di-

agram, as illustrated in Fig. 1. As developers, we may

intend to implement this scenario to possess the con-

sent property (Ferdous et al., 2019), that deﬁned as:

Figure 1: An illustration of the claim validation and is-

suance scenario as a sequence diagram.

“Users must agree to the use of their identity.

Any identity system is built around sharing

that identity and its claims, and an interoper-

able system increases the amount of sharing

that occurs. However, sharing of data must

only occur with the consent of the user.”

Since the user consents to the claim being read, the is-

suer has the right to read it. Once. we would want to

evaluate this system against the GDPR (2016)’s Arti-

cle 5.1.(b) purpose limitation, stated as follows:

“Personal data shall be collected for speciﬁed,

explicit and legitimate purposes and not fur-

ther processed in a manner that is incompati-

ble with those purposes;. . .”

According to the GDPR article’s deﬁnition, the con-

sent property lacked safeguards against subsequent

processes that were incompatible with the original

purpose. For example, a dishonest issuer may retain

the claim after it has been validated. The claim is re-

tained in excess of the speciﬁed purpose.

A common solution or workaround for this issue is

for developers to verify the system’s compliance with

any credible source they choose. Then, they must

increase their effort by modifying the implemented

system in order to complete all endorsed tasks. This

method is complex and time-consuming, depending

on the number of credible sources compiled.

The aforementioned issue with a common solution

presents us with two research questions:

1. Could the SSI system properties be easily recon-

ciled with well-known credible sources?

2. Are the properties still valid for the SSI system’s

fundamental notion after the SSI system’s prop-

erties have been enhanced by the addition of en-

dorsed tasks from credible sources?

To address those research questions, we present a re-

vised list of SSI system properties in this work, which

has been enhanced to ensure consistency with well-

known credible sources. We begin by identifying in-

consistencies between the tasks endorsed by credible

sources and the proposed properties. Then we deter-

mine which tasks are pertinent to the SSI system and

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

134

should be included on the list. The following are the

work’s major contributions:

- We ﬁnd inconsistencies between current property

proposals and the selected well-known, credible

sources. It is advantageous for system implemen-

tors to be aware of these inconsistencies and to

have a starting point for addressing them through-

out their property implementation.

- We enhance the SSI system properties to be in

consistent with credible sources. These enhanced

properties will guarantee implementors of the SSI

system that their implementation adheres to the

credible sources from the ground up and they can

focus their efforts only on property veriﬁcation.

3 PRELIMINARIES

3.1 Self-sovereign Identity System and

Its Property Proposals

This section will provide an overview of the SSI sys-

tem, its terminology, and its proposed properties. To

aid in comprehension of the SSI system, the following

terms are frequently used throughout articles (Allen,

2016; Ferdous et al., 2019; Tobin and Reed, 2017;

Stokkink et al., 2020; Lee et al., 2020):

A holder is an individual who owns their identity

or a system user who has complete control over their

PII. They have the option of disclosing their PII for

the purpose of service authentication.

An issuer is an individual, an organization, or a

system that is responsible for validating the correct-

ness of users’ claim.

A veriﬁer is an individual, an organization, or a

system that provides users a service and requires cre-

dentials for service authentication and authorization.

An identity attribute is a key-value pair that is

used to store PIIs. Attributes should be stored locally

in a user-owned device.

A decentralized identiﬁer is a unique identiﬁer

that uses public-private key infrastructure as a key ex-

change mechanism using the blockchain.

A claim is a collection of succinct statements at-

testing to the user’s PII. At times, it may make use

of a privacy-preserving mechanism, such as zero-

knowledge proofs.

A claim schema is a cryptographic schema

(which contains keys or hash strings) used to deﬁne

a veriﬁcation scheme. It will serve as an input for

the creation of veriﬁable claims and will be publicly

available on the blockchain for anyone wishing to ver-

ify the claim.

Figure 2: An overview of the SSI system model.

Utilizing those terms, it can form a model of the

SSI system, which adheres to the requirement for ver-

iﬁable credential data model (W3C, 2019). We illus-

trate an overview of the SSI system model in Fig. 2.

Indeed, the technical speciﬁcation for the SSI sys-

tem has further information, but for the sake of this

work, we will utilize only this abstraction to construct

the analysis criteria.

The SSI system is implemented differently de-

pending on the technology used. To ensure that the

implementation captures the essence of the SSI sys-

tem, however, principles and properties act as con-

straints on the implementation. To establish a clear

distinction between principles and properties, the fol-

lowing deﬁnition of a principle is used.

Deﬁnition 1 (Principle) A principle is represented as

an ordered set PR = {e

: S × A × O, i ∈ N}, where

is the i-th constraint that is utilized to determine if

a principle has been realized; S denotes a set of con-

strained subjects, e.g., a system component, an infras-

tructure, or policies; A is a set of constrained activi-

ties; O denotes a set of relevant information objects.

We discovered that principles in two current pro-

posals (Allen, 2016; Naik and Jenkins, 2020) provide

with a list of constraints, such as “user must agree to

the use of their identity”. These constraints serve as a

check list for ensuring the principle is followed. Each

constraint has three pieces of important information:

constrained subjects, activities, and related informa-

tion objects. This information was used to deﬁne the

principle. On the other hand, a property is a subset of

principles that are applicable to just system compo-

nents, such as the one that was proposed by Ferdous

et al. (2019). We deﬁne a system property as below.

Deﬁnition 2 (Property) A property is represented as

an ordered set P = {e

: S

× A × O, i ∈ N} where

P ⊆ PR, S

⊆ S is a subset of constrained subjects that

scoped only system components.

We will base on these deﬁnition in our consistency

analysis and enhancement.

3.2 Standards and Regulations

Given our goal of establishing standards and regula-

tions as credible sources, we should make a clear dis-

Analysis and Enhancement of Self-sovereign Identity System Properties Compiling Standards and Regulations

135

tinction between how they will be compiled and how

they will be used.

Both standards and regulations share a common

characteristic in that they deﬁne controls that are used

to determine or assess whether a target complies with

a speciﬁed standard or does not violate a regulation. A

control is a collection of tasks that have been endorsed

and serve as a checklist for assessing its compliance.

This means that if the target system performs the en-

dorsed tasks, it will be in compliance with the applica-

ble standard or regulation. For instance, the ISO/IEC

29100:2011 control entitled “openness, transparency,

and notice” has an endorsed task stated as follows:

“PII collector should identify the purposes for

which personal information is collected, used,

retained, and disclosed.”

Control may be referred to in a variety of ways in

credible sources, including as obligations or princi-

ples. As a result of their simplicity, we will refer to

all terms as controls and deﬁne them as follows.

Deﬁnition 3 (Control) A control is represented as an

ordered set C = {t

: CT ×CF × CI, j ∈ N} where

is the j-th endorsed task; CT is a set of controlled

targets; CF is a set of corresponding functions or pro-

cesses that are controlled; and CI is a set of informa-

tion objects that subject to be controlled.

For instance, the “openness, transparency, and no-

tice” control consisted of ‘PII collector’ as a control

target, ‘identify purposes to collect’ and ‘identify pur-

poses to use’ are examples of corresponding func-

tions, and ‘personal information’ is the controlled in-

formation object. As it is obviously shown that the

deﬁnition of principle (Def. 1), property (Def. 2), and

control (Def. 3) are similar in structure, we will be

able to analyze for inconsistencies and enhance the

existing system properties based on these deﬁnitions.

4 CONSISTENCY ANALYSIS AND

PROPERTY ENHANCEMENT

This section will describe our methodology for iden-

tifying inconsistencies between existing property pro-

posals and credible sources. While we demonstrate

an inconsistent case in Section 2, it also shows that

the properties are not completely inconsistent and

somewhat align with credible sources’ controls. This

section expands on this key concept in order to im-

prove existing proposals and provide more secure and

privacy-preserving properties.

Our methodology is qualitative and comparative

in nature and is comprised of four steps, as depicted in

Figure 3: An overview of the research methodology.

Fig.3. To begin, we discovered that the principles and

properties of existing proposals are identical or share

a portion of their deﬁnition. We compare and consol-

idate the overlapping deﬁnitions in step 4.1 to arrive

at a single coherent deﬁnition. We identiﬁed twenty

properties that could be consolidated as a result of the

three proposals. Then, in step 4.2, we conduct a sur-

vey of standards and regulations in order to identify a

set of credible sources capable of enhancing the prop-

erties through the establishment of selection criteria.

Five credible sources met our criteria. In step 4.3, we

compare property deﬁnitions to control from credible

sources to identify inconsistencies. This step docu-

ments three instances of consistency: Fully implies

that all tasks endorsed by credible sources are consis-

tent with some properties; Partially implies that only a

subset of tasks is consistent; and Discontent indicates

that the control is dissatisﬁed with some property. In

step 4.4, the three groups of results will be used to

enhance the existing properties.

4.1 Consolidating Overlapping

As discussed in Section 3.1, three recent proposals

for the SSI system’s principles and properties were

made (Allen, 2016; Ferdous et al., 2019; Naik and

Jenkins, 2020). Certain principles and properties

were discovered to be identical, while others shared

only a portion of their deﬁnition. It will be exhaust-

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

136

ing if we continue to improve each proposal individu-

ally. Consolidating the overlapping deﬁnitions into a

single coherent deﬁnition will make this paper more

concise and understandable.

Because Ferdous et al. (2019) and Naik and Jenk-

ins (2020) were based on Allen (2016)’s article, those

works incorporate fundamental principles. As can

be seen, each of Allen’s ten principles was incorpo-

rated into the others. As a result, there is no reason

to include Allen’s principles in order to increase ef-

fort. We will consider only those two proposals (X

for Ferdous et al. (2019), Y for Naik and Jenkins

(2020)) in this step. We compare two distinct prop-

erties (P

, P

∈ X , P

∈ Y ) by validating each pair

of constraints (e

, e

∈ P

, e

∈ P

) against the fol-

lowing conditions:

1. P

and P

share the same title.

2. P

and P

share the same high-level purposes.

3. (e

, e

) such that (S

c,m

⊆ S

c,n

)∧(A

⊆ A

), ∃m, n.

When at least one of the conditions is met, the pair of

properties is said to be overlapped. Then, two over-

lapping properties’ deﬁnitions will be consolidated

into a single property. Table 1 contains an exhaustive

list of twenty coherent deﬁnitions derived from the

two proposals. We use alphabetical superscriptions

to indicate the source of the constraint. Table 1 will

sufﬁce and will be used as an input for Section 4.3’s

consistency identiﬁcation.

4.2 Choosing Credible Sources

To accomplish our goal of enhancing the SSI system’s

security and privacy preservation through enhance-

ment of its properties, we need a collection of credible

sources that is sufﬁcient and appropriate for that pur-

pose. Hundreds of standards and regulations, on the

other hand, are enforced in numerous segments of the

IT industry. Some are directed at the organization, its

human resources, or its paperwork, while others are

directed at the operation of the system. This work fo-

cuses exclusively on the second category. Documents

pertaining to an organization, human resources, and

paperwork are not within our purview.

This step is for determining which standards and

regulations are appropriate for enhancing the proper-

ties of the SSI system. We outline the following crite-

ria for choosing credible sources:

1. The source must be, at least, targeted toward a

software product and its features.

2. The source must provide a set of controls that can

evaluate the software product’s features.

3. The source must be universally applicable regard-

less of any speciﬁc domain.

The ﬁrst criterion is to attempt to eliminate sources

Table 1: A complete list of coherent deﬁnitions - See a com-

plete comparison table in Appendix A. of (Pattiyanon and

Aoki, 2021).

Coherent Deﬁnition

P1. Existence: (1) SSIs must represent real-world user’s characteristic

a,b

(2) utilizing selective information that is necessary for use in the digital

domain

P2. Sovereignty: (1) An identity owner must have full control of their

identity to decide when they wish to release identity data and to which

entity for whatever purpose

a,b

. (2) Other person, organization, or gov-

ernment should not own or control their identity in any way

P3. Access Control: (1) An identity owner should have unrestricted

access and control over all access to their identity

a,b

P4. Transparency: (2) All systems, protocols, and algorithms employed

in an identity infrastructure should be free, open-source, as independent

as possible of any particular architecture or proprietorship

, and (1) trans-

parent for every involved entity

P5. Persistence: (1) SSIs must be persistent as long as required by their

owner

a,b

. (2) However, it must be revoked or abandoned by its owner at

any time

P6. Portability: (1) SSIs and related data can be transferred from a

medium or platform to another when the previous one disappears due to

any reason

a,b

P7. Interoperability: (1) All involved systems must be capable of

communicating with each other at any scale to maximize level of

interoperability

a,b

P8. Consent: (1) Every single piece of identity data must be released to

a third party only after the corresponding user has consented to do so

P9. Minimization: (2) When releasing SSIs to a third party, an iden-

tity owner should be requested to selectively provide or disclose

(1) the

minimum information of identity maintaining as much anonymity as

possible

a,b

P10. Protection: (2) SSIs and their communication channels should be

secured

and (1) well-protected with the latest cryptographic mechanism

satisfying the CIA (Conﬁdentiality, Integrity, and Authenticity) and non-

repudiation properties

P11. Autonomy: (1) SSIs must support full autonomy on the manage-

ment and administration of identity

P12. Single Source: (1) An identity owner should be the single source of

truth regarding their identity

that (2) maintained on the owner-controlled

storage

P13. Availability: (1) All infrastructures and services of the SSI system

must be readily available to all participants (including an identity owner)

without any discrimination to access from different platforms

a,b

P14. Sustainability: (2) An infrastructure and services of the SSI sys-

tem should be environmentally, economically, technically, and socially

sustainable

by (1) using open standards

P15. Cost Free: (1) SSIs should be offered to everyone free of cost or

negligible cost

a,b

, (2) without incurring any hidden cost, licensing fees,

or other ﬁnancial charges for creating, managing, and adopting them

P16. Flexibility: (1) An infrastructure and services should accommodate

the changing demand by facilitating diverse, decomposable, and extensi-

ble at any scale

P17. Safeguard: (1) The freedom and rights of every owners should be

safeguarded in any conditions

P18. Veriﬁability: (1) SSIs should be veriﬁable in the digital domain,

similar to a physical credential representing the real-world identity

P19. Recovery: (1) An infrastructure and services of the SSI system

should be sufﬁciently resilient to successfully recover any SSI in the case

of a key, wallet, or device lost

P20. Accessibility: (1) An infrastructure and services of the SSI system

should be user-friendly and accessible by as many people as possible

Analysis and Enhancement of Self-sovereign Identity System Properties Compiling Standards and Regulations

137

Table 2: An evaluation result of ten well-known sources

against the predeﬁned criteria.

Source Name #Page #Control

Criteria

1. 2. 3.

Security Source

ISO/IEC 15408:2009 (2009) 64 - × ×

ISO/IEC 27001:2013 (2013b) 23 114 × ×

ISO/IEC 27002:2013 (2013a) 80 14 × × ×

NIST SP800-12 (2017) 101 20 × ×

ASVS 4.0.2 (2020) 69 14 × × ×

Privacy Source

ISO/IEC 29100:2011 (2011) 21 11 × × ×

GDPR (2016) 88 7 × × ×

PDPA (2012) 44 9 × × ×

HIPAA (1996) 169 5 × ×

ISTPA RMRM (2009) 37 16 ×

that are irrelevant to our work. The second criterion

is used to eliminate sources that do not have evaluable

controls or that have controls that only evaluate non-

feature constraints. For example, several articles of

the GDPR (2016) regulate the privacy policies of the

target system, which are distinct from the system’s

features. The ﬁnal criterion is chosen to eliminate

domain-speciﬁc sources in order to increase the gen-

erality of the SSI system’s properties, as the SSI sys-

tem’s nature is self-contained and applicable to any

domain. If all of the criteria listed above are met, the

source is considered credible.

We limited our survey to ﬁve well-known security

sources and ﬁve well-known privacy sources in this

work. Then, we compare each source to our prede-

ﬁned criteria and present the results in Table 2. It con-

tains summary information about each source, such

as the number of pages (#Page) and controls that fol-

low Deﬁnition 3 (#Control). Following that, the re-

maining three columns indicate with a cross mark (×)

which criterion a source adheres to. It also reports that

two security sources and three privacy sources hold

all criteria. We will take those sources as another in-

put of consistency analysis. We explain each credible

source in the following sub-section.

A) ISO/IEC 27002:2013. deﬁnes security control

codes of practice, which supplement 114 security

controls (divided into 14 control sets) from Annex

A. of ISO/IEC 27001:2013b. However, those secu-

rity controls are aligned with the endorsed tasks in

Def. 3. Therefore, we utilize its 14 control sets as con-

trols and arrange corresponding security controls as

endorsed tasks. A control in this source will be iden-

tiﬁed by A.{Set No.}.({Control No.}), e.g., A.9.(3)

means the third controls in Annex A.9.

B) ASVS 4.0.2 (2020). is a standard that deﬁnes

hundreds of security veriﬁcation requirements for ap-

plications. This source provides 14 controls along

with objectives, high-level requirements, and detailed

requirements. The detailed requirements is too spe-

ciﬁc for the development, e.g., “Passwords are one

way hashed with a salt”. It is in a different abstraction

with the system properties. As a result, we summa-

rize the endorsed tasks from the high-level require-

ments only. A control in this source will be iden-

tiﬁed by V{Control No.}.({Requirement No.}), e.g.,

V1.(1) means the ﬁrst requirement of the ﬁrst control.

C) ISO/IEC 29100:2011. is a standard that intro-

duces a privacy framework for IT systems. This

source provide seven privacy principles, which are ex-

pressed in concise, evaluable statements. We refer to

those principles as controls and arrange those state-

ments as endorsed tasks. A control in this source is

identiﬁed by PR{Principle No.}.({Statement No.}),

e.g., PR2.(1) means the ﬁrst statements of the second

privacy principle.

D) GDPR (2016). is a well-known data protection

regulation for systems and organizations running their

business in European countries. This source provides

seven core principles in Chapter II Article 5.1 and 5.2,

which we refer to it as controls. However, other ar-

ticles were deﬁned in different aspects, from an or-

ganization to a system aspect. We add up articles

from Article 7 to 34, which the controlled targets (CT )

and data (CI) could be implied to the system compo-

nents. For example, Article 12.1 indicates that the

data controller must provide information on data pro-

cessing to the data subject, which relates to the Ar-

ticle 5.1.(a). A control in this source is identiﬁed

by Art.{Article No.}.{Paragraph No.}.({Point}), e.g.,

Art.5.1.(b) means point B in the ﬁrst paragraph of the

article 5.

E) PDPA (2012). is a legislation for systems and or-

ganization running their business in Singapore. This

source provides eleven controls in a form of obli-

gations. We take those obligations as controls and

arrange their deﬁnitions as endorsed tasks. A con-

trol in this source is identiﬁed by O{Obligation

No.}.({Statement No.}), e.g., O4.(1) means the ﬁrst

statement of the fourth obligation.

However, not all endorsed tasks of every control

are applicable for the SSI system. The task must ei-

ther endorse system components and actors, or con-

trol on data objects that are comparable to which

are in the SSI system. Therefore, at the end of this

step, we will collect controls and determine which

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

138

Table 3: An example of a control with applicable endorsed

tasks - See a complete list of controls in Appendix B of (Pat-

tiyanon and Aoki, 2021).

PR10. Accountability: (1) PII collector should ensure the compliance

with privacy and data protection requirements is able to demonstrate;

(2) Responsibilities, internal and external auditing and controlling of all

data processing should be speciﬁed;

Table 4: Pre-deﬁned system components S

that are compa-

rable to controlled targets CT .

System Component S

Controlled Target CT

Identity Owner Data Subject, Individuals

System

Application, System, Process, PII

Collector, Data Controller, Collector

Protocol

Algorithm

Infrastructure

Service

endorsed tasks are applicable. Table 3 shows an ex-

ample of a control with an applicable endorsed task

highlighted.

4.3 Identifying Consistencies

We can determine which control’s endorsed task is

consistent with the existing properties because we

received two comparable inputs from Sections 4.1

and 4.2 based on Deﬁnitions 2 and 3. Indeed, we con-

trast e

∈ P with t

∈ C, assuming that the SSI sys-

tem’s property can achieve a higher level of security

and privacy if it is more consistent with controls from

credible sources. Inconsistencies discovered during

the comparative analysis will be a valuable source of

property enhancement in Section 4.4.

In this step, we compare e

= (sc, a, o) such that

(sc, a, o) ⊆ S

×A ×O, and e

∈ P with t

= (ct, c f , ci)

such that (ct, c f , ci) ⊆ C T ×CF × CI and t

∈ C . A

constraint e

is comparable to an endorsed task t

if at

least two of the following conditions hold.

• x ∈ sc, ∃x is comparable to y ∈ ct, ∃y according to

Table 4.

• x ∈ d, ∃x is comparable to y ∈ ci, ∃y according to

Table 5.

• x ∈ p, ∃x is explicitly equivalent to y ∈ c f , ∃y.

As stated in the preceding conditions, we conduct a

domain analysis to discover a relationship between

terms in standards and regulations and terms in the

SSI system. Tables 4 and 5 were created to represent

those relationships. Unfortunately, some pairs are in-

comparable and necessitate the services of a profes-

sional consultant. We use our domain knowledge to

justify which pairs satisfy the criteria.

All pairs that demonstrate consistency will be col-

lected and classiﬁed into three categories: FC is a

collection of controls that satisfy all of their endorsed

Table 5: Pre-deﬁned pairs of data objects O that are compa-

rable to corresponding information objects CI.

Data Object O Corresponding Information CI

SSI, Personal Data, Partial

Identity, Claim

Information

Transaction

Personally Identiﬁable Information

(PII)

Data

Personal Data

Assertion, Proﬁle Credential

Table 6: Results from the consistency analysis.

Control C Class Consistent Pair (e, t) Missing

Task t

ISO/IEC 27002:2013a

A.8 DC - (6),(7)

A.9 IC (P3.(1), (4)), (P3.(1), (5)), (P10.(2), (6)) (3)

A.10 FC (P10.(1), (2)) -

A.12 DC - (6)-(10)

A.13 DC - (1), (3)

A.14 IC (P10.(2), (3)) (2)

A.17 FC (P13.(1), (4)) -

A.18 FC (P10.(1), (4)) -

OWASP ASVS 4.0.2 (2020)

V2. IC (P10.(2), (4)), (P19.(1), (5)), (P10.(2), (7)) (1)-(3),

(6),(8)

V3. DC - (1)-(3)

V4. IC (P3.(1), (1)) (2)-(4)

V5. DC - (1)-(3)

V6. IC (P10.(1), (1)), (P10.(2), (3)) (2)

V7. DC - (1)-(4)

V8. FC (P10.(1), (1)), (P10.(1), (2)), (P10.(1), (3)) -

V9. FC (P10.(2), (1)), (P10.(1), (2)), (P10.(1), (3)) -

V10. DC - (1)-(4)

V11. DC - (1)-(3)

V12. DC - (1),(2)

V13. DC - (1)-(3)

V14. DC - (1)-(3)

ISO/IEC 29100:2011

PR1. FC (P2.(1), (1)), (P8.(1), (2)) -

PR2. DC - (1),(2)

PR3. IC (P5.(1), (1)) (2)

PR4. FC (P9.(1), (1)) -

PR5. FC (P2.(1), (1)), (P5.(2), (2)) -

PR6. DC - (1),(2)

PR7. IC (P2.(1), (2)), (P4.(1), (3)) (1),(4)

PR8. FC (P2.(1), (1)), (P5.(2), (2)) -

PR9. IC (P10.(1), (1)), (P17.(1), (1)) (2)

PR10. DC - (1)

GDPR (2016)

Art.5.1.(a) IC (P8.(1), (1)) (2)-(5)

Art.5.1.(b) DC - (1),(2)

Art.5.1.(c) FC (P9.(1), (1)) -

Art.5.1.(d) IC (P5.(2), (2)), (P5.(2), (3)) (1),(4)

Art.5.1.(e) FC (P5.(1), (1)) -

Art.5.1.(f) FC (P10.(1), (1)) -

Art.5.2 DC - (1),(2)

PDPA (2012)

O2. DC - (1)

O3. IC (P8.(1), (1)) (2),(3)

O4. IC (P5.(1), (1)) (2)

O5. DC - (1)

O6. FC (P10.(2), (1)) -

O7. FC (P5.(1), (1)) -

O8. DC - (1)

O9. IC (P3.(1), (1)) (2)

O11. FC (P6.(1), (1)) -

tasks (∀t) by any property; IC is a collection of con-

trols that satisfy some of their endorsed tasks (∃t) by

any property; and DC is a collection of controls that

satisfy none of the endorsed tasks.

The results of the consistency analysis between

a list of properties’ coherent deﬁnitions and credible

sources’ controls are shown in Table 6 . Each control

is identiﬁed by its category, pairs that demonstrate its

Analysis and Enhancement of Self-sovereign Identity System Properties Compiling Standards and Regulations

139

consistency, and missing endorsed tasks that were not

met by any property. Regrettably, the absence of en-

dorsed tasks indicates inconsistencies that may con-

tribute to improvement. In the following section, we

will examine the feasibility of adding the missing en-

dorsed tasks to the properties of the SSI system.

4.4 Revising the Properties

The inconsistencies discovered in the previous step

provide insights into areas where current proposals

for the properties of the SSI system fall short. In this

step, we either add the missing endorsed tasks from

Table 6 to existing properties or develop new prop-

erties to cover the gaps in compliance with credible

sources. Our improvement is based on three criteria,

which are listed below.

1. For a control C that is classiﬁed as IC:

(a) We enhance a property EP that relates to a con-

sistent pair (e, t) by adding missing endorsed

task t if there are ﬁt to the property context.

(b) We introduce an additional property AP, which

includes missing endorsed tasks t ∈ C that are

not ﬁt to the related property context P that con-

tains e from the consistent pair.

2. For a control C that is classiﬁed as DC, we intro-

duce an additional property AP that includes miss-

ing endorsed tasks t ∈ C.

3. For all properties, including current, enhanced,

and additional properties, we revise their elements

to subject to the SSI system.

We obtain a list of the SSI system’s properties using

the preceding criteria, as shown in Tables 7 and 8. As

can be seen from the list, we also specify three types

of properties: Ps are current properties that are only

revised based on the third criteria; EPs are enhanced

properties that include corresponding endorsed tasks

from controls from credible sources; APs are addi-

tional properties that are developed from discontent

controls or endorsed tasks from controls that are not

suitable for any property context.

The critical outcome of this paper will be a list

of the SSI system’s properties, which will aid in the

analysis, design, and development of the SSI system

implementation.

5 EVALUATION

This section will discuss how the proposed list of SSI

system properties was evaluated. They are evaluated

using two methods: use cases and a questionnaire for

experts. The subsequent sub-sections will detail the

evaluation procedure and results.

Table 7: A complete list of the enhanced SSI system prop-

erties with their deﬁnition.

Property Name P and Its Deﬁnition (Property Elements e)

P1. Existence: (1) An SSI system must allow its users to represent their real-world

characteristics in the digital domain; (2) An SSI system requires to utilize selective

information that is only necessary for use in the digital domain;

EP2. Sovereignty: (1) An SSI system must provide full control to an identity owner to

decide when they wish to release identity data and to which entity for whatever purpose;

(2) An SSI system must not allow other person, organization, or government to own or

control user’s identity in any way; (3) PR.7.(4) An SSI system should inform relevant

stakeholders to understand possible risks and actions they can take to control their iden-

tity;

P3. Access Control*: (1) An SSI system must allow identity owners to have unre-

stricted access and control over all access to their identity;

EP4. Transparency: All systems, protocols, and algorithms in the SSI domain should

be transparent for every involved entity; (2) All systems, protocols, and algorithms in the

SSI domain should be free, open-source, and as independent as possible; (3) PR7.(1) An

SSI system should provide notice about its policies and procedures to the identity owner;

EP5. Persistence: (1) An SSI system must persist SSIs as long as it is required by an

owner; (2) An SSI system must revoke or abandon SSIs as requested by an owner at any

time; (3) PR3.(2) An SSI system must observe the type and amount of SSI suitable for

its purpose; (4) Art.5.1.(d).(4) An SSI system must communicate any rectiﬁcation or

erasure of SSIs to every participant;

P6. Portability: (1) An SSI system must allow SSIs and related data to transfer to

another medium or platform when it disappears due to any reason;

P7. Interoperability: (1) All involved systems in the SSI domain must be capable of

communicating with each other at any scale to maximize level of interoperability;

EP8. Consent: (1) An SSI system release SSIs to a third party after an owner has con-

sented to do so; (2) Art.5.1.(b).(2) An SSI system should demonstrate the processing of

SSIs regarding the owner consent; (3) Art.5.1.(b).(3) If the consent is given as a written

declaration, an SSI system should represent the consent in an intelligible and easily ac-

cessible form, using clear and plain language; (4) Art.5.1.(c) & O3.(2) An SSI system

must provide a right of an identity owner to withdraw their consent at any time with

noticing of the likely consequences; (5) Art.5.1.(d) An SSI system must provide any

information relating to the processing to the identity owner in a concise, transparent,

intelligible and easily accessible form, using clear and plain language; (6) O3.(3) Once

the consent is withdrawn, an SSI system must cease to collect, use or disclose the cor-

responding SSIs;

P9. Minimization: (1) When releasing SSIs to a third part, an SSI system must allow

an identity owner to release the minimum information of identity maintaining as much

anonymity as possible; (2) An SSI system must allow an identity owner to selectively

provide or disclose them;

EP10. Protection: (1) An SSI system protects SSIs and their communication channels

with the latest cryptographic mechanism satisfying the CIA (Conﬁdentiality, Integrity,

and Authenticity) and non-repudiation properties; (2) An SSI system must use a secure

storage and communication channels for SSIs and related data; (3) A.14.(2) All services

of an SSI system must be protected from public networks; (4) V6.(2) When an SSI

system generates a randomized numerical data, a suitable random generator is used;

(5) PR9.(2) An SSI system must identify and protect both physical and logical against

privacy risks;

P11. Autonomy: (1) An SSI system must support full autonomy on the management

and administration of identity;

P12. Single Source: (1) An SSI system accepts SSIs from an owner who is a single

source; (2) An SSI system must maintain SSIs in the owner-controlled storage;

P13. Availability: (1) An infrastructure and services of an SSI system must be readily

available to all participants (including an identity owner) without any discrimination to

access from different platform;

P14. Sustainability: (1) An infrastructure and services of an SSI system should use

open standards; (2) An infrastructure and services of an SSI system should be environ-

mentally, economically, technically, and socially sustainable;

P15. Cost Free: (1) An SSI system should offer its services to anyone free of cost or

negligible cost; (2) An SSI system should not incur any hidden cost, license fees, or

other ﬁnancial charges for creating, managing, and adopting SSIs;

P16. Flexibility: (1) An infrastructure and services of an SSI system should accommo-

date the changing demand by facilitating diverse, decomposable, and extensible at any

scale;

P17. Safeguard*: (1) The freedom and rights of every owners should be safeguarded

in any conditions;

P18. Veriﬁability: (1) An SSI system should allow the identity veriﬁcation in the digital

domain, similar to a physical credential representing the real-world identity;

P19. Recovery*: (1) An infrastructure and services of an SSI system should be resilient

to successfully recover any SSI when a key, wallet, or device lost;

P20. Accessibility: (1) An infrastructure and services of an SSI system should be user-

friendly and accessible by as many people as possible;

AP21. Information Handling: (1) A.8.(6) An SSI system should label user per-

sonal information based on privacy and sensitivity; (2) A.8.(7) An SSI system should

handle user personal information properly according to its privacy and sensitivity;

(3) A.12.(6) Information should be backed up regularly;

AP22. Authentication: (1) A.9.(3) An SSI system must implement a formal user reg-

istration and de-registration; (2) V2.(8) & V4.(2) & V13.(1) An SSI system must au-

thenticate users with valid credentials to services before use; (3) V2.(2) & V2.(6) An

SSI system must use strong authenticator with single or multi-factor one time veriﬁer;

(4) V2.(1) & V2.(3) An SSI system employs password security mechanisms and ver-

iﬁes valid lifecycle of password and credentials; (5) V3.(1) & V3.(2) & V13.(1) An

SSI system employs session management mechanisms using session tokens that bind to

the user authentication; (6) V3.(3) An SSI system must control session and enforce to

terminate due to timeout;

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

140

Table 8: A complete list of the enhanced SSI system prop-

erties with their deﬁnition (Cont’).

Property Name P and Its Deﬁnition (Property Elements e)

AP23. Accountability: (1) A.12.(7) & A.12.(9) & Art.5.2.(2) An SSI system should

keep administrative, operative, and system event logs and review them regularly;

(2) A.12.8 & V7.(2) An SSI system must protect log information against tampering

or unauthorized access; (3) V7.(1) An SSI system does not log sensitive information

unless required; (4) V7.(3) An SSI system does not store logs forever; (5) PR10.(1)

& Art.5.2.(1) An SSI system should ensure the compliance with privacy and data

protection requirements is able to demonstrate;

AP24. Communication Security: (1) A.13.(1) Networks in the SSI domain are

managed and controlled; (2) A.13.(3) Groups of users, services, and systems are

segregated; (3) O8.(1) An SSI system transfers SSIs to any system in another country

if the country stated requirements prescribed to the comparable level of regulations;

AP25. Secure Conﬁgurability: (1) A.12.(10) The clocks of every component in

the SSI domain are synchronized; (2) V14.(1) An SSI system has a secure, repeat-

able build environment; (3) V14.(2) An SSI system has hardened third-party library,

dependency and conﬁguration management; (4) V14.(3) An SSI system has a secure-

by-default conﬁguration;

AP26. Role Manageability: (1) V4.(3) An SSI system deﬁnes roles and privileges to

every users; (2) V4.(4) An SSI system protect role and responsibility metadata from

replay and tampering;

AP27. I/O and Error Handling: (1) V5.(1) & V13.(2)-(3) An SSI system should

use input validation, output encoding architecture, and effective secure controls for

system and web services; (2) V5.(2) An SSI system should validate, check length

or range, sanitize or ﬁlter input data; (3) V5.(3) An SSI system encode or escape

output data per the data context; (4) V7.(4) & V10.(1) An SSI system must handle

malicious activities securely and properly; (5) V10.(2)-(4) An SSI system should

protect application-based vulnerabilities including time-based attacks, phone home

code, or unauthorized code; (6) V11.(1)-(3) An SSI system must verify that both

normal and high value business ﬂows are sequential, processed in order, and cannot

be bypassed, as well as are protected against automated attacks; (7) V12.(1)-(2) An

SSI system should handle and store untrusted ﬁles in a secure manner with limited

permissions;

AP28. Purpose Limitation: (1) PR2.(1) & Art.5.1.(b).(1) An SSI system

collects SSIs or personal data for speciﬁed, explicit and legitimate purposes;

(2) Art.5.1.(b).(2) & O2.(2) An SSI system must not process SSIs beyond its pur-

poses; (3) PR2.(2) & O2.(1) An SSI system must communicate the purposes of SSI

processing to an owner;

AP29. Accuracy: (1) PR6.(1)-(2) & Art.5.1.(d).(1) & O5.(1) & O9.(2) An SSI

system must check periodically that SSIs are accurate, complete, correct and up-to-

date;

* Properties that are classiﬁed into IC, but they are not suitable for adding missing

endorsed tasks t.

5.1 Use Cases

To generate use cases that incorporate the proposed

list of SSI system properties, we must ﬁrst identify a

domain that will use the SSI system for user authen-

tication. We assume that the use cases were created

using the uniﬁed modeling language (UML) with the

intent of attestation some properties. Authors with

experience in both system design and the SSI system

will create the system design.

Case 1: HR Application - Assume a business in-

tends to construct a human resources (HR) application

that would authenticate organizational software ser-

vices and gather personnel background information.

In the component of service authentication where

the employee’s name, postal address, and educational

background are required, the HR application will im-

plement the SSI idea. Assume that each employee is

required to install the business’s employee wallet ap-

plication on their own mobile phone in order for the

corporation to obtain their personal data. The wal-

let application requires a link to a service provided

by the institution from which an employee graduated,

which veriﬁes the employee’s claim of receiving a

degree. The aforementioned use case is designed as

Figure 4: A use case for the HR application’s service au-

thentication scenario.

a sequence diagram in Fig. 4. Three properties are

speciﬁed for the application: P3, EP5, and EP8. For

instance, the EP5 Persistence property deﬁnes a con-

straint as follows:

“A SSI system must communicate any rectiﬁ-

cation or erasure of SSIs to every participant.”

Using this constraint, we may be concerned about

a claim’s rectiﬁcation after it has been validated by

the institution. As a result, we add two additional

messages to the sequence diagram (i.e., messages 8

and 9), which satisfy this constraint.

Case 2: Trafﬁc Police Application - Assume that

a city’s police department wishes to construct a trafﬁc

police application. This program is intended to en-

able a trafﬁc police ofﬁcer to conduct driver’s license

checks while on patrol. Drivers must carry a wallet

application containing their personal information re-

lated to their driver’s license. A police ofﬁcer would

do the checks by asking a driver to share their veriﬁ-

able claim on their driver’s license on the police appli-

cation. The police application will validate it against

a relevant blockchain schema. The above scenario is

depicted in Fig. 5 as a sequence diagram. Assume that

this application is developed with the goal of achiev-

ing two properties: AP28 and AP29. For example,

the AP28 Purpose Limitation property deﬁnes a con-

straint as follows:

“A SSI system must communicate the pur-

poses of SSI processing to an owner.”

This property may be held in this circumstance if the

application is required to process a veriﬁed claim on

the driver’s license, which goes beyond the applica-

tion’s initial purposes. It necessitates informing the

owner of the additional purposes, which results in the

insertion of message 7.

These two use cases indicate how the proposed list

of properties can be used to real-world applications in

a variety of different disciplines.

Analysis and Enhancement of Self-sovereign Identity System Properties Compiling Standards and Regulations

141

Figure 5: A use case for the trafﬁc police application’s li-

cense checking scenario.

Table 9: A summary of the questionnaire’s responses - See

the raw data attached in (Pattiyanon and Aoki, 2021).

Property Name Agreed Responses (%)

EP2. Sovereignty 100.0%

EP4. Transparency 100.0%

EP5. Persistence 100.0%

EP8. Consent 100.0%

EP10. Protection 100.0%

AP21. Information Handling 100.0%

AP22. Authentication 100.0%

AP23. Accountability 85.71%

AP24. Communications Security 85.71%

AP25. Secure Conﬁguration 100.0%

AP26. Role Management 100.0%

AP27. I/O and Error Handling 100.0%

AP28. Purpose Limitation 100.0%

AP29. Accuracy 100.0%

5.2 Expert Opinion

The preceding section discussed the applicability of

the proposed set of properties in terms of their ease of

adoption in speciﬁc use scenarios. Through an online

questionnaire (Google Forms), we seek expert opin-

ion on the proposed list of properties in this section.

We created a questionnaire with two sections. The

ﬁrst section discusses the SSI system in general, its

functions, and the proposed set of properties. The

second section includes a set of fourteen questions

that assess if the limits imposed by each added and

upgraded property contradict with the SSI system’s

fundamental concept. If a conﬂict arises, we will seek

justiﬁcation from a relevant expert.

We contacted 21 participants with a minimum of

one year of expertise in the identity management sec-

tor. We believe that the qualiﬁcation will help demon-

strate that professionals can grasp the notion of the

SSI system even if they have no prior experience with

it. We had eight responses, but one was from a devel-

oper with fewer than a year of experience. We omit

that response from the conclusion in favor of a sum-

mary in Table 9.

The result that most of the properties are compat-

ible with the notion of the SSI system. An expert,

on the other hand, disputes two additional properties:

AP23 and AP24. An expert argues that the AP23 Ac-

countability property’s deﬁnition should contain an

audit log and that the AP24 Communication Secu-

rity property’s deﬁnition should reﬂect the consent

obtained when data is communicated. Because audit

logging is optional in the system aspect and consent

is deﬁned by another property (the EP8 Consent prop-

erty), we infer that those inputs are suggestions.

6 DISCUSSION

The evaluation ﬁndings in two areas demonstrate sig-

niﬁcant beneﬁts and limitations for SSI system imple-

menters. These advantages and limitations are worth

considering. This section discusses the ﬁndings in re-

lation to the pre-deﬁned research questions discussed

in Section 2 as well as potential threats to validity.

“RQ1. Could the SSI system properties be

easily reconciled with well-known credible

sources?”

We discovered that by examining and demonstrating

the proposed list of properties in domain use cases

(Section 5.1), the proposed properties could assist SSI

system implementors by offering insight into what

should be controlled. The sequence diagrams (Figs. 4

and 5) demonstrate that some functions may be lack-

ing in the absence of the proposed properties. The

new functionalities assist the SSI system in acquiring

fundamental concepts and requirements while also

ensuring compliance with credible sources. How-

ever, two limitations are evident in its applications:

(1) The proposed properties do not entirely recon-

cile the SSI system’s implementation with credible

sources, as some endorsed tasks are not directed at

the system (as we excluded in Section 4.2). It may

need additional effort on the part of an organization to

comply with them, but the effort will be signiﬁcantly

less than the effort required to implement without the

proposed properties; and (2) the proposed properties’

deﬁnition is subjective to implementors. Due to the

fact that the proposed properties are speciﬁed in nat-

ural language, their application may result in human

errors or misconceptions.

“RQ2. Are the properties still valid for the SSI

system’s fundamental notion after the proper-

ties have been enhanced by the addition of en-

dorsed tasks from credible sources?”

Due to the fact that the SSI system’s fundamental

notion are deﬁned differently from those of credi-

ble sources, it is possible that the proposed proper-

ties with the addition of endorsed tasks will conﬂict

with the fundamental notion. Plus the fact that our

approach for analyzing consistency in Section 4 did

not take the fundamental notion into consideration,

we created our evaluation procedure to utilize expert

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

142

opinions to test the proposed properties against them.

The ﬁrst section of the questionnaire instructs experts

to review fundamental notion that may bolster their

conﬁdence in the experts’ comprehension. The result

in Table 9 indicates that the majority of experts feel

the proposed properties remain valid for the funda-

mental notion of the SSI system. However, the pro-

posed properties were unable to demonstrate their va-

lidity against real-world SSI system solutions. This

disadvantage is viewed as a limitation of this research.

6.1 Threat to Validity

As of our research design, we found two groups of

threats to validity: internal and external threats. We

will discuss on each group, respectively.

Internal Validity. This research identiﬁes three in-

ternal threats to validity. First, this work relies on

only ﬁve credible sources to bolster the SSI system’s

properties. It validates our work for certain sources

but may invalidate it for others. This is, neverthe-

less, a starting point for individuals interested in im-

proving the properties further. Additionally, credi-

ble sources are drawn from well-known and widely-

applicable standards and regulations. At the very

least, such sources were embraced globally. Second,

as stated previously, this work does not include an as-

sessment of its application to real-world SSI system

solutions. The evaluation of use cases is entirely the-

oretical. However, we feel that the use cases we used

are deﬁned by the SSI system’s fundamental notions.

If real-world SSI system solutions are derived from

those notions, the proposed properties cannot be used

in any other way. Finally, the evaluation described

in Section 5.2 was not undertaken with SSI system

experts. We were unable to gather signiﬁcant input

for this work due to the scarcity of SSI system exper-

tise. However, we invite professionals in the domain

of identity management, which is closely tied to the

SSI system. As a result, they can use their skills ef-

fectively to comprehending the SSI system after it is

introduced.

External Validity. We discovered only a threat to

validity externally. Apart from the use cases evalu-

ated, real-world SSI system solutions may incorporate

a variety of complex technologies. This may have an

effect on the suitability of the proposed property def-

inition, as it may be inapplicable to certain technolo-

gies. Regrettably, we were unable to verify that all

implemented versions adhere to the proposed proper-

ties. However, as illustrated in Tables 7 and 8, the

proposed properties are described at a high level of

Table 10: A comparison of this work with other property

proposals.

Related Work #Property Security? Privacy? Source

Allen (2016) 10 No No N/A

Ferdous et al. (2019) 17 No No Notions

Naik and Jenkins (2020) 20 No Yes GDPR

Our work 29 Yes Yes 5 sources

abstraction. It should be able to apply them without

difﬁculty with the manual interpretation.

7 RELATED WORK

The evaluation and discussion demonstrate the in-

herent advantages and disadvantages of the proposed

properties. However, there are other proposals that

seek to strengthen the SSI system’s security and pri-

vacy as well. This section will compare the proposed

properties to existing ones and discuss how the SSI

system will be enhanced in related works.

To begin, we compare the proposed properties

to those already proposed for the SSI system. Ta-

ble 10 summarizes our comparison and emphasizes

our strengths. Our work supports the ideas made

by Allen (2016) and Ferdous et al. (2019), who made

no reference to credible sources of property. Further-

more, whereas our work considers both the security

and privacy aspects of the SSI system, Naik and Jenk-

ins (2020)’s approach focused exclusively on the pri-

vacy issue and made a reference to the GDPR only.

On the other hand, various initiatives have been

undertaken to enhance the SSI system’s security and

privacy. The majority of them, however, concen-

trated on enhancing certain technological features,

such as the process for establishing zero-knowledge

proofs (Lee et al., 2020) and the network communi-

cation protocol Stokkink et al. (2020). Additionally,

the researchers tried to build trust in the SSI system

by building a quantitative approach for assessing is-

suer reputation (Bhattacharya et al., 2020). Our work

focuses on the overall enhancement of the SSI system,

and it should be applicable in conjunction with other

related work.

8 CONCLUSIONS

The terms “principle” and “property” refer to con-

cise statements describing constraints based on the

SSI system’s fundamental concepts. While the cur-

rent principles and properties proposed were not stan-

dardized, they were widely embraced and acknowl-

edged in academic and industrial works on the SSI

system. We determined that existing proposals vio-

Analysis and Enhancement of Self-sovereign Identity System Properties Compiling Standards and Regulations

143

lated well-established standards and regulations. We

undertake a comparison analysis in this study to dis-

cover inconsistencies and then use them to suitably

update the property deﬁnition. We propose an ex-

panded list of 29 SSI system properties that includes

the endorsed tasks that are missing from ﬁve credible

sources. The proposed properties are demonstrated in

two use cases and are concluded the deﬁnition agreed

upon by identity management specialists.

This work is limited across some ways, including

its relevance and suitability for real-world SSI system

solutions, as well as the ambiguity of its deﬁnition.

They may serve as a guide for our future work, which

will concentrate on showing them in real-world cir-

cumstances using rigorous techniques such as model

checking. With a formal model of the SSI system and

formalized properties, it might be used successfully

and proﬁtably to real-world solutions.

REFERENCES

Allen, C. (2016). The Path to Self-Sovereign Iden-

tity. http://www.lifewithalacrity.com/2016/04/the-

path-to-self-soverereign-identity.html.

Bhattacharya, M. P., Zavarsky, P., and Butakov, S. (2020).

Enhancing the Security and Privacy of Self-Sovereign

Identities on Hyperledger Indy Blockchain. In Int.

Symp. on Netw. Comput. Commun., pages 1–7.

Centers for Medicare & Medicaid Services (1996). The

Health Insurance Portability and Accountability Act

of 1996 (HIPAA).

Ferdous, M. S., Chowdhury, F., and Alassaﬁ, M. O.

(2019). In Search of Self-Sovereign Identity Leverag-

ing Blockchain Technology. IEEE Access, 7:103059–

103079.

International Organization for Standardization (2009). In-

formation technology - Security techniques - Evalua-

tion Criteria for IT Security (ISO/IEC 15408:2009).

International Organization for Standardization (2011). In-

formation technology - Security techniques - Privacy

framework (ISO/IEC 29100:2011).

International Organization for Standardization (2013a). In-

formation technology - Security techniques - Code of

Practice For Information Security Controls (ISO/IEC

27002:2013).

International Organization for Standardization (2013b). In-

formation technology - Security techniques - Infor-

mation Security Management System - Requirements

(ISO/IEC 27001:2013).

Lee, J., Hwang, J., Choi, J., Oh, H., and Kim, J. (2020).

SIMS : Self-Sovereign Identity Management System

with Preserving Privacy in Blockchain. IACR Cryptol.

ePrint Arch. https://eprint.iacr.org/2019/1241.pdf.

Naik, N. and Jenkins, P. (2020). Governing Principles

of Self-Sovereign Identity Applied to Blockchain En-

abled Privacy Preserving Identity Management Sys-

tems. In Proc. Int. Symp. on Sys. Eng., pages 1–6.

Nieles, M., Dempsey, K., and Pillitteri, V. Y. (2017). NIST

Special Publication 800-12 Revision 1 - An introduc-

tion to information security. NIST Special Publica-

tion.

OWASP (2020). Application Security Veriﬁcation Standard

4.0.2.

Pattiyanon, C. and Aoki, T. (2021). Analysis and En-

hancement of Self-Sovereign Identity System Proper-

ties Compiling Standards and Regulations (Full Ver-

sion). https://doi.org/10.5281/zenodo.5792398.

Stokkink, Q., Epema, D., and Pouwelse, J. (2020).

A Truly Self-Sovereign Identity System. arXiv.

https://arxiv.org/pdf/2007.00415.pdf.

The European Parliament and the Council of the Euro-

pean Union (2016). European General Data Protec-

tion Regulation (GDPR).

The International Security Trust and Privacy Alliance

(ISTPA) (2009). Privacy Management Reference

Model Version 2.0.

The Personal Data Protection Commission (2012). The Per-

sonal Data Protection Act 2012.

Tobin, A. and Reed, D. (2017). The Inevitable Rise of Self-

Sovereign Identity: A white paper from the Sovrin

Foundation [White Paper]. https://sovrin.org/wp-

content/uploads/2017/06/The-Inevitable-Rise-of-

Self-Sovereign-Identity.pdf.

W3C (2019). Veriﬁable Credential Data Model 1.0.

https://www.w3.org/TR/vc-data-model/.

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

144