A Method for Detecting Common Weaknesses in Self-Sovereign Identity

Systems Using Domain-Speciﬁc Models and Knowledge Graph

Charnon Pattiyanon, Toshiaki Aoki and Daisuke Ishii

Japan Advanced Institute of Science and Technology, Ishikawa, Japan

Keywords:

Self-Sovereign Identity, Weakness Detection, Domain-Speciﬁc Modeling Language, Knowledge Graph.

Abstract:

A Self-Sovereign Identity (SSI) system is a decentralized identity management system based on claims

that leverages blockchain technology to empower individuals to manage their personal information and au-

tonomously authenticate services. The SSI system is unique in that it makes use of disparate terminologies,

making analysis arduous and challenging for security specialists. Weakness analysis is a well-known security

assurance technique for determining the presence of weaknesses in a target system. Weakness analysis is cru-

cial to the deployment of the SSI system in that it can earn user trust and be veriﬁed secure if the majority of

detected weaknesses are addressed properly. We seek to leverage domain experience in this work to lessen

the effort required to analyze weaknesses by security specialists unfamiliar with the SSI system. This paper

presents two domain-speciﬁc modeling languages (DSMLs) based on the uniﬁed modeling language (UML)

communication diagram for embedding domain knowledge about the SSI system and common weaknesses.

Then, with the assistance of domain knowledge graphs, this paper presents a method for detecting weaknesses

in the links between the two models created by the proposed DSMLs. Precision and accuracy metrics are used

to determine the proposed method’s performance.

1 INTRODUCTION

A self-sovereign identity (SSI) is a claim-based, de-

centralized identity management system. It empow-

ers users to manage and control their personally iden-

tiﬁable information (PII) without the intervention of a

central authority (e.g., a service provider). It is a new

standard for protecting personally identiﬁable infor-

mation (PII) in modern software systems, however it

is not generally adopted at the moment due to its com-

plexity and concerns about its security and privacy.

To obtain user trust, the SSI system’s security has

to be taken into consideration because it’s closely

linked to the manipulation of PII. However, the SSI

system’s unique terminologies and mechanism make

it more difﬁcult for security specialists to become ac-

quainted. Due to a lack of acquaintance and domain

experience, it may result in cases being overlooked

when performing security analysis.

Weakness analysis and detection are two fre-

quently used security assurance approaches for en-

hancing the security of software systems. The ul-

timate goal is to identify and eliminate any secu-

rity weaknesses in a target system. MITRE Corpo-

ration assists security analysts by compiling a pub-

lic database, i.e., the common weakness enumer-

ation (CWE), of common software and hardware

weaknesses. Several previous works attempted to

provide a variety of methodologies for detecting com-

mon CWE weaknesses, including an ontological ap-

proach (Ansarinia et al., 2012; Salahi and Ansarinia,

2013) and a program analysis approach (Sun et al.,

2014). Unfortunately, none of them consider domain

knowledge and require domain expertise to imple-

ment. Existing methodologies are difﬁcult for inex-

perience analysts to apply to the SSI system.

Due to the cutting-edge nature of the SSI system

and its implementation’s emphasis on adhering to its

fundamental concepts, its implementation may intro-

duce several weaknesses unintentionally. Thus, weak-

ness analysis becomes critical to the SSI system’s se-

curity in the sense that it can only be proven secure

if the majority of detected weaknesses are adequately

addressed. For instance, a weakness in the cleanup of

sensitive data following processing. The fundamental

concepts made no reference to or concern themselves

with data cleansing, resulting in the retention of sensi-

tive information in the memory. Without conducting a

weakness analysis, this weakness may become a point

of attack for any threat actor.

Pattiyanon, C., Aoki, T. and Ishii, D.

A Method for Detecting Common Weaknesses in Self-Sovereign Identity Systems Using Domain-Speciﬁc Models and Knowledge Graph.

DOI: 10.5220/0010824900003119

In Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2022), pages 219-226

ISBN: 978-989-758-550-0; ISSN: 2184-4348

219

The purpose of this study is to exploit the SSI sys-

tem’s domain expertise and to bridge gaps in com-

monly used CWE terms. We proﬁle the uniﬁed mod-

eling language (UML) communication diagram in or-

der to propose two domain-speciﬁc modeling lan-

guages (DSMLs): one for the SSI system and another

for the CWE weaknesses. Then, we conduct a do-

main analysis to develop linkages between the SSI

system’s unique terminologies and the CWE’s com-

mon weaknesses, which we formalize as a knowledge

graph. Finally, we present a methodology for detect-

ing the CWE’s common weakness on the basis of the

knowledge graph. We undertake an experiment to de-

termine the performance of the proposed method us-

ing experts’ ground truth. The main contributions of

this paper are listed as:

• We abstract the SSI system’s native properties us-

ing a DSML that is both versatile and comprehen-

sive for modeling the SSI system’s architecture.

• We abstract the description of the CWE’s com-

mon weaknesses into a DSML that can be applied

to a variety of areas and methodologies.

• We describe an approach for bridging gaps

between standard software development and

domain-speciﬁc system development. This

method enables security specialists who are unfa-

miliar with the SSI system to do a coverage weak-

ness analysis.

The remainder of this paper is structured as follows:

Section 2 discusses the approaches employed. Sec-

tion 3 proposes a meta-model for DSMLs. Sec-

tion 4 details our proposed method for detecting

weaknesses. Sections 5 and 6 summarize our experi-

mental ﬁndings and discuss them. Section 7 compares

our work to related works, and Section 8 summarizes

our ﬁndings and suggests future directions.

2 BACKGROUND

2.1 Self-Sovereign Identity Systems

A self-sovereign identity was invented as an identity-

as-a-service solution that overcomes management dif-

ﬁculties through the decentralization of blockchain

technology. It guarantees users’ complete sovereignty

over their PII and their ability to selectively disclose

it as little as necessary (Allen, 2016). The SSI sys-

tem is built on the W3C standard for veriﬁable cre-

dential data models (Sporny et al., 2019), which spec-

iﬁes three roles: holder, issuer, and veriﬁer. A holder

is an individual who is an identity subject and who

owns PIIs. An issuer is a person, organization, or

system that is responsible for validating claims. A

Figure 1: A high-level overview of the SSI system with an

actual situation.

veriﬁer is a person, organization, or system that ver-

iﬁes claims to ensure they are valid for service au-

thentication. M

uhle et al. (2018) surveyed and re-

ported four essential components: identiﬁcation, at-

tribute storage, veriﬁable claim, and authentication.

Each entity in the SSI system is uniquely identiﬁable

using a decentralized identiﬁer (DID). An entity can

exchange a DID in order to retrieve the public key

of another entity from a blockchain. A holder could

store PIIs in the attribute storage of a local device and

create a claim attesting to a PII with little knowledge.

For instance, a holder may record his or her age and

create a claim attesting to the fact that the holder is

over the age of 18 without disclosing the actual age.

The claim should be sent to the issuer for veriﬁcation

of its accuracy. If the claim is valid, the issuer can ver-

ify it manually or against existing data and then gen-

erate a veriﬁable claim using a blockchain-published

schema. To authenticate services, a holder may offer

both claims and veriﬁed claims to a veriﬁer. The veri-

ﬁer may validate the veriﬁable claim by accessing the

related schema on blockchain.

To summarize and explain an actual example,

Fig. 1 provides a high-level overview of the SSI sys-

tem for a graduate who claims a degree in order to

seek for a job. The university that grants the degree

will publish a degree schema on blockchain, which

the company may validate.

2.2 Common Weakness Enumeration

A weakness is a type of fault that can be exploited as

a vulnerability within a software product even when it

is operating normally (MITRE, 2006). MITRE Cor-

poration urges that the IT community submit com-

mon software and hardware weaknesses to the CWE

database. They will publish proposed weaknesses in

the CWE database after a thorough evaluation.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

220

Multiple text ﬁelds are used to record an entry in

the CWE database, including a description, common

consequences, and demonstrative examples. To de-

termine the occurrence of a weakness, analysts must

scan through those text ﬁelds and justify the potential

in the target system. Only a few entries are provided

in the demonstrative example text ﬁeld as an example

of smelly source code. It can be seen that the most

important information for detecting a weakness is the

description text ﬁeld, e.g.:

“The software does not perform or incor-

rectly performs an authorization check when

an actor attempts to access a resource or per-

form an action.”

Discussing the contents of the description text ﬁeld, it

describes how a system actor acts on information in

a positive or negative manner. We focus on the de-

scription text ﬁeld of the common software weakness

solely because the SSI system’s unique functionalities

are based on its software application.

2.3 UML Communication Diagram

The UML communication diagram is a subset of the

interaction diagram speciﬁed by the object manage-

ment group (OMG). Hundreds of details were given in

the speciﬁcation for each option of the interaction dia-

grams (Object Management Group, 2017). They did,

however, share the same abstract syntax, even though

the communication diagram may not incorporate all

of them.

Three signiﬁcant syntaxes demand special atten-

tion: a lifeline, a message, and a general ordering. A

lifeline is a timeline that depicts the progression of a

procedure. A message is merely the record of events

occurring between two lifelines. It will be denoted by

a message occurrence speciﬁcation, which speciﬁes

the event’s name, arguments, and value. A general

ordering denotes the sequence in which the messages

appear in the diagram.

In this work, we proﬁle the domain knowledge

of the SSI system and the CWE weaknesses that de-

ﬁne two novel DSMLs using the abstract syntax of

the UML interaction diagram, particularly the section

used by the communication diagram.

2.4 Knowledge Graph

A knowledge graph is a directed labelled graph that

depicts the relationships between knowledge entities.

Ji et al. (2021) recently deﬁned a knowledge graph

G = ⟨E, R , F ⟩ in which E denotes a set of entities,

R denotes a set of relations, and F ⊆ E × R × E

denotes a set of facts showing the existence of a rela-

tionship between two entities. For example:

• (“John”, born

in, “Sydney”) is a fact denoting

john was born in Sydney.

• (“Application”, read, “data”) is a fact denoting an

application reads data.

The knowledge graph is a straightforward model

that facilitates both user accessibility and systematic

search. While it lacks the richness of other graph

representations (e.g., ontology), it is lightweight and

sufﬁces to denote simple relationships. We employ

a knowledge graph to depict the links between SSI

system-speciﬁc and common software concepts in

this work, based on the domain analysis results.

3 META-MODELS

3.1 SSI System DSML Meta-model

Due to the fact that the SSI system is deﬁned by dis-

tinct terminologies, and these terminology may vary

among publications, designing the SSI system using

the UML interaction diagram may require a generic

reference to domain-speciﬁc information.

According to (Allen, 2016; Sporny et al., 2019;

uhle et al., 2018), the SSI system consists of three

interchangeable roles, distinct data objects, and tech-

nical components, as stated in Section 1. Moreover,

Ferdous et al. (2019) studied the fundamental con-

cept of the SSI system in the literature and identiﬁed

four critical data objects in formal terms, i.e., a partial

identity, an SSI, an assertion, and a proﬁle. Likewise,

other works (Tobin and Reed, 2017; Haddouti and

Ech-Cherif El Kettani, 2019; Liu et al., 2020; Panait

et al., 2020; Wang and De Filippi, 2020; Naik and

Jenkins, 2020) studied and presented designs for the

SSI system in a variety of ways. Taking this literature

into account, we found a common structure of the SSI

system’s functionalities, i.e., technical component(s)

performs a function on SSI-related object(s). Thus,

we summarize variations of element in the common

structure in Table 1.

We use the common structure as a core notion to

create a DSML for the SSI system, as illustrated in

Fig. 2 on the left as a meta-model with a class di-

agram. The meta-model demonstrates how the SSI

system’s DSML is proﬁled using the abstract syntax

of the UML interaction diagram. The technical com-

ponents of the SSI system provide a lifeline. Then,

functions and SSI-related objects are used to construct

the message and value speciﬁcation, respectively. In

this work, we will model the SSI system using the

A Method for Detecting Common Weaknesses in Self-Sovereign Identity Systems Using Domain-Speciﬁc Models and Knowledge Graph

221

Figure 2: Meta-models of the two DSMLs for the SSI system (left) and the CWE weaknesses (right).

Table 1: Common structure of the SSI system’s functions

and its variations.

Element Variation

Technical

Component

Holder, Issuer, Veriﬁer, Identity Wallet, Service End-

point, Blockchain

Function Create, Update, Delete, Modify, Read, Disclose, Ex-

change, Store

SSI-related

Objects

PII, Identity Attribute, Attribute Value, DID, DID

Document, Partial Identity, SSI, Claim, Attestation,

Assertion, Proof, Service Token, Public Key, Private

Key, Claim Schema, Request Schema, Consent

DSML and then use the model as an input to the pro-

posed weakness detection method.

3.2 CWE Weakness DSML Meta-model

As stated in Section 2.2, the CWE contains hundreds

of entries for common software and hardware weak-

nesses. However, important data is contained in the

description text ﬁeld for the purpose of detecting the

occurrence of the weakness.

We divide the important data necessary for detect-

ing the occurrence of weakness into three categories:

actors who produce the weakness; actions denote con-

nected actions that, in some conditions, result in a

weakness; information refers to a set of data elements

that are exploited by an action of weakness. Then, as

illustrated on the right-hand side of Fig. 2, we pro-

ﬁle the UML interaction diagram to highlight those

categories and propose a DSML for the CWE weak-

nesses. In this work, we will use the proposed DSML

to model each entry of the CWE weaknesses and then

use it as another input to the proposed method.

Figure 3: An overview of the knowledge graph-based weak-

ness detection method.

4 KNOWLEDGE GRAPH-BASED

WEAKNESS DETECTION

This section describes our proposed method for de-

tecting security software weaknesses in the CWE

database by leveraging the inter-model links be-

tween the two DSMLs and the predeﬁned SSI sys-

tem domain knowledge graph. We shall illustrate an

overview of the proposed method in Fig. 3.

The proposed method is built on the assumption

that a generic description of the CWE weaknesses

is adequate to compare to the SSI system’s unique

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

222

functionalities and detect the existence. At step A,

an analyst should model the target SSI system im-

plementation using the proposed DSML for the SSI

system. The resulting system model will be a UML

communication diagram enhanced with SSI-speciﬁc

stereotypes. Then, in step B, an analyst should use

the proposed DSML to model all the interesting en-

tries of common software weaknesses from the CWE

database. Models produced should follow the same

format as the SSI system design. Finally, at step C,

we propose the SSI system domain knowledge graph

based on the results of the domain analysis, which en-

ables an analyst to make use of preexisting informa-

tion when detecting which weaknesses occur in the

target SSI system implementation. In the following

sub-section, we will explain each step in details.

4.1 Detailed Methodology

Step A. Modeling of the SSI System Design. This

step will use the proposed DSML to model the SSI

system. The primary user of this methodology is an

analyst who is tasked with analyzing the security of

an SSI system implementation. First, regardless of the

design process used, an analyst should extract the im-

plementation’s functionality. It is sufﬁcient to gener-

ate a list of functions, each of which describes which

components or actors perform an action on a set of

data objects. Then, using the DSML meta-model,

an analyst should model those functions as a series

of UML communication diagrams with their con-

stituents labeled with the SSI system-speciﬁc stereo-

type (on the left-hand side of Fig. 2). It is possible for

an analyst to create many diagrams to represent all of

the implementation’s unique functionalities. An ex-

ample of a modeled communication diagram is shown

in Fig. 4. Additionally, one can observe that certain

additional notations have been added to the commu-

nication diagram to clarify the particular stereotype.

Step B. Modeling of the CWE Weaknesses. This

step will use the proposed DSML to model the CWE

database’s weaknesses in the same way as the SSI sys-

tem does. At the start of this step, an analyst must

determine the extent of software weaknesses to ex-

amine. While it is ideal to model and use all soft-

ware weaknesses in the CWE database, this can be

scoped to conserve resources and effort. Then, an an-

alyst should utilize the DSML meta-model to repre-

sent each software weakness entry as a detailed com-

munication diagram, as this may contain sufﬁcient

information to detect a weakness (according to the

right-hand side of Fig. 2). A single entry for a soft-

ware weakness should have a single matching model.

An example of a modeled communication diagram is

Figure 4: An example of a communication diagram speci-

ﬁed by the proposed DSML for the SSI system.

Figure 5: An example of the CWE 212 communication dia-

gram speciﬁed by the proposed DSML for the CWE weak-

nesses.

shown in Fig. 5. Speciﬁed weakness conditions are

highlighted in red texts.

Step C. Detecting of the Occurrence of Each CWE

Weakness. This step will examine two groups of

communication diagrams and identify the inter-model

links between them. Regrettably, the two groups

are frequently represented in disparate circumstances,

particularly in terms of nomenclature.

To overcome this issue, we propose a knowledge

graph including pre-deﬁned links between the SSI

system’s speciﬁc and common software terms. We

analyzed a collection of research papers on the design

of SSI systems and discovered that, even within this

discipline, distinct names were employed to denote

the same meaning. For instance, the terms “user” and

“holder” are used interchangeably to refer to a holder.

In accordance with (Ji et al., 2021)’s deﬁnition, we

limit the scope of relations R in the proposed knowl-

edge graph to the equivalence-to relation (abbreviated

“eqv to”). In Fig. 6, we deﬁne links between SSI

system-speciﬁc terms that share a common meaning

through the use of blue relational edges.

On the other hand, we also found that the SSI

system-speciﬁc terms are somewhat different to com-

mon software development terms. We take the spe-

ciﬁc terms to search in a thesaurus corpora

and in-

clude synonyms of the speciﬁc terms into the knowl-

edge graph. We deﬁne links between SSI system-

speciﬁc terms to common terms using orange rela-

tions edges in Fig. 6.

This step detects the occurrence of a weakness

in the target SSI system implementation using the

An online thesaurus database: www.thesaurus.com

A Method for Detecting Common Weaknesses in Self-Sovereign Identity Systems Using Domain-Speciﬁc Models and Knowledge Graph

223

Figure 6: The proposed knowledge containing pre-deﬁned

linkages of terms.

knowledge graph and a series of methods outlined

in Algorithm 1. This algorithm indicates that all el-

ements of two communication diagrams are iterated

and compared using a procedure called CHECKE-

QUIVALENT(). The procedure should verify if a pair

of elements are present in the knowledge graph and

have relevant relations. If this is the case, the pair

will be collected for the purpose of indicating the oc-

currence of weakness. Otherwise, a manual judgment

will be required to update the knowledge graph.

Algorithm 1: Weakness detection between communication

diagrams for the SSI system and the CWE weakness using

the knowledge graph.

Input: A communication diagram of the SSI system (S)

A communication diagram for a weakness (W )

A knowledge graph (G

SSI

)

Output: A boolean decision of the weakness occurrence.

1: Initiate Rel

= False, Rel

= False;

2: for each component c in S do

3: for each actor a in W do

4: if CHECKEQUIVELENT(c, a) then

5: Rel

= True;

6: for each function f in S do

7: for each action p in W do

8: if CHECKEQUIVALENT( f , p, G

SSI

) then

9: Check conditions and Rel

= True;

10: for each SSI-related object or its inheritance o in S do

11: for each information i in W do

12: if CHECKEQUIVALENT(o, i, G

SSI

) then

13: Rel

= True;

return Rel

and Rel

;

14: procedure CHECKEQUIVALENT(t

, t

, G

SSI

)

15: if (t

, eqv to, t

) in F of G

SSI

then

16: return True;

17: else

18: return Determine whether t

and t

are equiva-

lent and update G

SSI

;

Table 2: Statistical data of the experimental runs.

Product #SSI #CWE #Pair #Rel #Detect Time

IBM 5 10 18,363 9 3 1.49s

Sovrin 7 10 20,528 15 3 1.67s

uPort 2 10 10,551 13 3 1.32s

Fig. 4 and 5 illustrate the proposed method’s re-

sults in action. Assume we model a function repre-

senting an implementation in Fig. 4 and the CWE 212

entry in Fig. 5 using steps A and B. According to the

CWE 212 weakness, the product does not remove or

only partially remove sensitive information prior to

transfer, allowing other users to access it. Using the

knowledge graph, Algorithm 1 determines if an issuer

endpoint is equivalent to a product (see at the top-right

of Fig. 6). Additionally, the claim is equivalent to sen-

sitive information. The discovered relationships ap-

pear to suggest that there is a possibility of CWE 212

entry in the SSI system implementation.

5 EVALUATION

5.1 Implementation

We develop a Python command-line interface tool to

aid in the implementation of the proposed method in

real-world scenarios. The program accepts two JSON

ﬁles as inputs: one containing the SSI system model

and another containing an entry for a CWE weakness.

The JSON keys are deﬁned using the DSMLs and are

structured according to the UML communication dia-

gram’s core elements. The tool is then used to conduct

Algorithm 1 semi-automatically, as some aspects still

require manual judgment. The knowledge graph, on

the other hand, is designed to be evolutionary, and its

updating will bring the tool closer to automaticity.

5.2 Experiment Settings and Findings

We conducted an experiment to determine the SSI

system’s performance in real-world implementations.

We chose three implementations of the SSI system as

examples: IBM Verify Credentials, Sovrin, and uPort.

The IBM Verify Credentials and the Sovrin have

a similar target market (i.e., enterprise-level busi-

nesses), but their network governance mechanisms

are distinct. uPort, on the other hand, is more compact

that includes a variety of features. They are excellent

representations of real-world differences.

In JSON ﬁles, we encode the functions of the

three implementations and 10 CWE weakness en-

tries. The 10 entries were chosen at random from

a bucket of software weaknesses with adequate de-

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

224

Table 3: An evaluation result of the proposed method.

Product

Confusion Matrix

Accuracy Precision

TP FP FN TN

IBM 3 0 1 6 90.00% 100.00%

Sovrin 3 0 0 7 100.00% 100.00%

uPort 2 1 2 5 70.00% 66.67%

scriptions to enable detection of their occurrence. The

JSON ﬁles are then supplied into the implemented

tool, which detects the occurrence of weaknesses. Ta-

ble 2 summarizes statistical data from experimental

runs in which three implementations were compared

to 10 entries (#CWE). The implementation is encoded

as a series of communication diagrams (#SSI), each

of which contains a signiﬁcant number of elements

to compare against the CWE weakness entries. The

fourth column (#Pair) denotes the number of iter-

ated term pairs in Algorithm 1, while the ﬁfth and

sixth columns (#Rel and #Detect) denote the num-

ber of discovered relations and detected weakness en-

tries, respectively. The ﬁnal column indicates the

time required for the implemented tool to complete

the detection. It should be noted that the time is only

recorded for the automatic phase, and the time spent

on manual judgment is not included.

We invited three specialists with at least three

years of expertise in the ﬁeld of identity manage-

ment, security training, and a sufﬁcient level of En-

glish reading ability to manually identify instances

of weakness. Expert responses serve as the ground

truth for the evaluation, in which we assess the pro-

posed method’s performance using the confusion ma-

trix. It has four possible values: true positive (TP)

indicates an accurate detection that corresponds to ex-

pert opinion; false positive (FP) indicates an incorrect

detection of the occurrence; false negative (FN) in-

dicates an incorrect detection of the non-occurrence;

and true negative (TN) indicates an accurate detec-

tion of a weakness that will not occur. The results of

each implementation are shown in Table 3, along with

computed precision and accuracy measures.

6 DISCUSSION

Performance of the Proposed Method. Due to the

fact that the two domains are deﬁned in distinct con-

texts, the proposed method’s performance is charac-

terized by its ability to close gaps and identify the

occurrence of weaknesses. Two performance advan-

tages are clear from the experimental results. To be-

gin, the accuracy and precision measures indicate that

the information retrieval performance is satisfactory.

Indeed, accuracy is greater than 70% and precision is

greater than 65% in three real-world scenarios. Al-

though the accuracy and precision ratings are unsur-

prisingly high, analysts unfamiliar with the SSI sys-

tem may have a decent starting point for narrowing

the search scope for CWE database weaknesses. Sec-

ond, the proposed method makes advantage of an evo-

lutionary knowledge graph. It may be updated on a

regular basis, and its performance could be improved

over time. It is advantageous that the implemented

tool runs in less than two seconds, which is faster than

manual scanning.

Two limits in terms of faulty cases were observed.

In Table 3, we identiﬁed instances of false positives,

indicating a deceptive detection. The cases may re-

sult from the procedure’s imperfect knowledge graph.

However, due to its evolutionary nature, it has the po-

tential to transcend this constraint over time. The lim-

itation is the potential of false negative situations due

to a lack of semantic continuity. For instance, cer-

tain CWE weaknesses necessitate human judgment

that goes beyond the concept of links. This constraint

implies that the proposed method will continue to re-

quire human engagement.

Extensibility in the Domain. Although the pro-

posed method is designated to be domain-speciﬁc, it

still provides opportunity to different variations. It

shows in the experiment that the proposed method is

applicable to different representatives of the SSI sys-

tem’s implementation. If there is an implementation

that does not align with the fundamental notion of the

SSI system, the proposed method and DSMLs may be

limited and require further modiﬁcation.

Threat to Validity. This work identiﬁes two threats

to validity. First, the basis for expert opinions must

be reliable. Even if the invited specialists work in the

ﬁeld of identity management, they are not involved

with the SSI system. We believe that their experience

in that ﬁeld is adequate for them to comprehend the

notion of the SSI system. Second, the sample size of

weakness entries is quite small. Given the human fac-

tor, the sample size should be modest enough to avoid

human error. While the sample size is modest, the

size of each entry is reasonable, as more than 10,000

pairs are iterated.

7 RELATED WORK

There are several works attempted to propose weak-

ness detection method in the past few year. An on-

tological approach is a prominent way to represent

the weakness and detect its presence as in used in

A Method for Detecting Common Weaknesses in Self-Sovereign Identity Systems Using Domain-Speciﬁc Models and Knowledge Graph

225

(Ansarinia et al., 2012; Salahi and Ansarinia, 2013),

but the existing ontologies formulate only the domain

of the CWE weakness only. It still requires domain

knowledge to understand the target system. Another

approach is the use of program analysis, e.g., Sun

et al. (2014) and Son et al. (2015), but not all entries

contain code examples or resources to perform pro-

gram analysis. Most existing techniques did not take

the domain knowledge of the target into account.

For the proposals for domain-speciﬁc models on

security purposes, there are some works that at-

tempted to use DSMLs to capture the security charac-

teristics, e.g., security concerns (Silva Gallino et al.,

2012), security objectives (Saleem et al., 2012), or at-

tack surfaces (Sun et al., 2020). To the best of our

knowledge, none of work has attempted to model the

domain-speciﬁc knowledge of the two domains.

8 CONCLUSIONS

This paper proposes two DSMLs for proﬁling

domain-speciﬁc knowledge of the SSI system’s and

the CWE weaknesses. We also propose a method

for detecting common software weaknesses in a tar-

geting implementation of the SSI system. The pro-

posed method compares two system models utilizing

the knowledge graph. We implement a command-line

interface tool to semi-automatically process the pro-

posed method and conduct an experiment for evaluat-

ing its performance. The proposed method achieves a

certain performance that is acceptable.

However, the proposed method obscures some

of the knowledge graph’s inadequacies and seman-

tic continuity. We believe that the domain knowledge

examined and applied in this study might facilitate fu-

ture research aimed at eliminating those issues.

REFERENCES

Allen, C. (2016). The path to self-sovereign iden-

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

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

Ansarinia, M., Asghari, S. A., Souzani, A., and Ghaznavi,

A. (2012). Ontology-based modeling of ddos attacks

for attack plan detection. In IST 2012, pages 993–998.

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.

Haddouti, S. E. and Ech-Cherif El Kettani, M. D.

(2019). Analysis of identity management systems us-

ing blockchain technology. In CommNet 2019, pages

1–7.

Ji, S., Pan, S., Cambria, E., Marttinen, P., and Yu, P. S.

(2021). A survey on knowledge graphs: Representa-

tion, acquisition, and applications. IEEE Transactions

on Neural Networks and Learning Systems, pages 1–

21.

Liu, Y., He, D., Obaidat, M. S., Kumar, N., Khan, M. K.,

and Raymond Choo, K. K. (2020). Blockchain-based

identity management systems: A review. Journal

of Network and Computer Applications, 166(Febru-

ary):102731.

MITRE (2006). Common Weakness Enumeration (CWE).

https://cwe.mitre.org/.

uhle, A., Gr

uner, A., Gayvoronskaya, T., and Meinel, C.

(2018). A survey on essential components of a self-

sovereign identity. Computer Science Review, 30:80–

86.

Naik, N. and Jenkins, P. (2020). Governing principles of

self-sovereign identity applied to blockchain enabled

privacy preserving identity management systems. In

ISSE 2020, pages 1–6.

Object Management Group (2017). Uniﬁed Modeling Lan-

guage: Speciﬁcation. Version 2.5.1. formal/17-12-05.

Panait, A.-E., Olimid, R. F., and Stefanescu, A. (2020).

Analysis of uport open, an identity management

blockchain-based solution. In TrustBus 2020, pages

3–13. Springer International Publishing.

Salahi, A. and Ansarinia, M. (2013). Predicting network

attacks using ontology-driven inference. http://arxiv.

org/abs/1304.0913.

Saleem, M. Q., Jaafar, J. B., and Hassan, M. F. (2012). A

domain-speciﬁc language for modelling security ob-

jectives in a business process models of SOA applica-

tions. Advances in Information Sciences and Service

Sciences, 4(1):353–362.

Silva Gallino, J. P., De Miguel, M., Briones, J. F., and

Alonso, A. (2012). Domain-speciﬁc multi-modeling

of security concerns in service-oriented architectures.

Lecture Notes in Computer Science, 7176:128–142.

Son, Y., Lee, Y., and Oh, S. (2015). A Software Weakness

Analysis Technique for Secure Software. Advanced

Science and Technology Letters, 93:5–8.

Sporny, M., Longley, D., and Chadwick, D. (2019). Veriﬁ-

able credential data model v1.0. https://www.w3.org/

TR/vc-data-model/.

Sun, F., Xu, L., and Su, Z. (2014). Detecting logic vulner-

abilities in e-commerce applications. In DNSS 2014,

pages 23–26.

Sun, T., Drouot, B., Golra, F., Champeau, J., and Guerin,

S. (2020). A Domain-speciﬁc Modeling Framework

for Attack Surface Modeling. In ICISSP 2020, pages

341–348.

Tobin, A. and Reed, D. (2017). The in-

evitable rise of self-sovereign identity: A

white paper from the sovrin foundation.

https://sovrin.org/wp-content/uploads/2017/06/

The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf.

Wang, F. and De Filippi, P. (2020). Self-sovereign identity

in a globalized world: Credentials-based identity sys-

tems as a driver for economic inclusion. Frontiers in

Blockchain, 2(January):1–22.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

226