Compliance SSI System Property Set to Laws, Regulations, and Technical Standards

Digital identities, including names and age, provide modern information systems with valuable data. Identity management is a security feature that enables users to manage and utilize their digital identities when interacting with online services. A self-sovereign identity (SSI) system is a cutting-edge identity model that uses blockchain technology to foster peer-to-peer trust in service authentication and authorization. SSI systems typically adhere to a set of functional- and quality-related principles and properties. However, we discovered that the current information security and privacy principles and properties of SSI systems are not compliant with the laws, regulations, and technical standards. A compliance set of principles and properties must be established to support the implementation of SSI systems and to improve security and privacy. In this article, we propose CSSPS, a new compliance SSI system property set that expands upon the missing security and privacy controls specified in applicable laws, regulations, and technical standards. We used systematic comparative analysis and systematic review to identify inconsistent content from a vast collection of applicable sources, and then used them to extend the current properties of the SSI system. The proposed CSSPS increases the consistency of security and privacy controls, and is applicable in accordance with the functionality of real SSI systems, as determined by a qualitative evaluation. The proposed CSSPS contributes to SSI system implementation by facilitating correct implementation, while adhering to applicable information security and privacy sources. In addition, the proposed CSSPS can indirectly enhance the security and privacy of SSI systems.

The associate editor coordinating the review of this manuscript and approving it for publication was Diana Gratiela Berbecaru .
to central authorities and rely on their data handling mech-32 anisms. However, centralized identity management systems 33 require users to incur administrative costs in order to man-34 age their digital identities at every location they provide. 35 In order to consolidate the administration of digital identities 36 under a single identity provider, federated and user-centric 37 identity management systems were developed. Disputes also 38 arose regarding the security and privacy of identity providers' 39 digital identities. With the emergence of decentralized sys-40 tems and distributed ledger technology, decentralized identity 41 management systems have been introduced and have gained 42 prominence in the field of information security and privacy. 43 A self-sovereign identity (SSI) system is an identity 44 management system that authenticates and authorizes ser- 45 vices using a claim-based trust mechanism and blockchain 46 The auditing procedure establishes the uniformity of the 114 evaluating subjects and controls. To persuade auditors, the 115 evaluating subjects must prove how the endorsed tasks or 116 conditions are met. If subjects were reported as inconsistent, 117 it would take a considerable effort to correct and re-evaluate 118 them. It would be advantageous if the subjects were consistent 119 in the first place. 120 We observed that the SSI system's properties are compa-121 rable to source document controls in that they are all defined 122 for evaluating the desired SSI system implementation. As a 123 result, while aligning the SSI system implementation with 124 the source documents, we can check for consistency between 125 property and control definitions, assuming the implementa-126 tion appropriately possesses the properties. We consider that 127 the consistency between system properties and controls is 128 evidenced by the similarity of sentences in a system property 129 definition to the endorsed tasks or conditions of the con-130 trol. Currently, certain system properties provide a limited 131 degree of consistency with controls in source documents. 132 For example, while the consent property prohibits PII dis-133 closure without the user's consent, it is not fully consistent 134 with GDPR article 5.1. (b) due to the lack of a restriction 135 on further processing. We believe this is an opportunity 136 to enhance the SSI system's security and privacy through 137 compliance. 138 This opportunity motivates researchers to devise new pro-139 posals for system properties to enhance the SSI system's 140 security and privacy. Allen [1] was the first to propose 141 ten basic SSI principles restricting the SSI system's core 142 concepts. His proposal contained no constraints on security 143 or privacy other than those outlined by the core concepts. 144 Ferdous et al. [4] derived system properties from Allen's 145 basic SSI principles. They began incorporating security 146 and privacy features into the properties without referencing 147 source documents. López [2] extended 16 SSI principles to 148 Allen's list, aligning them with the criteria of the digital 149 identity model. Finally, Naik and Jenkins [3] is the most 150 recent proposal to reinforce Allen's principles through GDPR 151 compliance. Their proposal, however, limits the scope of data 152 privacy to a single source document. We believe that the 153 properties should be universally applicable across all scopes 154 and as consistent as possible with a large number of source 155 documents. 156 VOLUME 10,2022 This article proposes a new SSI system property set, the following terminology to comprehend the SSI system 211 properties:

212
• A subject is any entity in which claims are made. Human 213 beings, animals, and objects are examples of possible 214 subjects. Often, the subject can take the holder role, but 215 this is not always the case. For instance, a parent (the 216 holder) may own a child's claims (the subject).

217
• A holder is an entity role that holds one or more subject's 218 claims and presents them as credentials to verifiers for 219 service authentication and authorization. A holder must 220 be the role that has complete sovereignty over their PII 221 located in a locally-owned device.

222
• An issuer is a type of entity role that validates claims 223 about subjects and generates valid credentials in verifi-224 able claims based on blockchain-based proof schemas. 225 • A verifier is an entity role that requires holders to present 226 valid credentials (i.e., verifiable claims) before provid-227 ing services to them.

228
• A claim is a declaration of the identity of a subject. It is 229 a statement or structure that attests to the authenticity of 230 a particular identity attribute. Using a zero-knowledge 231 proof, the claim may imply the identity attribute so 232 that it can convince verifiers without revealing actual 233 information. Issuers must validate the claim in order for 234 it to be a valid credential.

235
• A decentralized identifier (DID) is a unique identifier 236 that combines the public/private key infrastructure (PKI) 237 key exchange mechanism with blockchain technology. 238 The DID is used as an address to resolve public keys 239 contained in a DID document that has been published 240 on the blockchain. Entities distribute DIDs in order to 241 establish trust relationships.

242
This terminology acquaints readers with the SSI system and 243 its properties. Certain alternate terminology for technology 244 and implementation is used in various publications, but the 245 meaning should remain the same. 246 The terminology establishes a conceptual foundation for 247 the SSI system analogous to the data model for verifiable cre-248 dentials. In Fig. 1, we display the high-level data communi-249 cation among components to provide a general perspective of 250 the SSI system. As can be seen, three distinct roles are being 251 played as system components that store and communicate 252 FIGURE 5. GDPR-compliant proposal of Naik and Jenkins' twenty guiding principles for SSI systems [3] (2).
In order to compare and contrast them with the appli-283 cable laws, regulations, and technical standards, this article 284 provides these four proposals of SSI system principles and 285 properties as inputs for our analysis. We do not consider the 286 latter or other proposals to be within our purview. 288 To propose the CSSPS, we employ a property enhancement 289 approach that includes a systematic review of source doc-290 uments and comparing present system properties to shared 291 controls, as seen in Fig. 7. The approach is divided into prop-292 erty consolidation, shared control derivation, and property 293 enhancement. 294 The property consolidation phase intends to develop the 295 most recent and comprehensive view of the SSI system prop-296 erties from various proposals. We noted that several SSI 297 principles were described in a manner that was similar to the 298 way SSI system properties are defined. Combining duplicates 299 in theses definitions is necessary to create a single input 300 for our analysis. This phase begins by matching compara-301 ble or identical SSI principles and system properties. For 302 FIGURE 6. 17 System properties of the SSI system proposed by Ferdous et al. [4] that categorized into five groups.

III. APPROACH OVERVIEW
instance, all four proposals defined the persistence property 303 similarly. We combine duplicate constraints from the SSI 304  The property enhancement phase aims to identify consis-329 tency between existing system properties and shared controls 330 and leverage that consistency to improve property definition. 331 We begin with the premise that some shared controls may be 332 partially consistent or inconsistent with the existing system  • An inconsistent control represents a control in which 346 none of the endorsed tasks or conditions in the shared 347 control are satisfied by any system property.

348
Finally, we enhance the definition of SSI system properties by 349 leveraging categories of shared controls. Indeed, we include 350 the missing endorsed tasks or conditions resulting from par-351 tially consistent and inconsistent shared control into the appli-352 cable current system properties. On the other hand, we may 353 introduce new system properties if the endorsed tasks or 354 conditions are deemed unsuitable. Section VI discusses the 355 CSSPS and our enhancement algorithms in detail.

357
This section will address existing SSI principles and system 358 property proposals and how we develop input for property 359 enhancement by removing duplicate constraints, consolidat-360 ing, and formalizing the SSI principles and system properties. 361

363
The SSI principles and system properties for the SSI system 364 are related somehow, and one was derived from the others. 365 These relationships result in duplications of SSI principles 366 and proposed system properties. This section outlines our 367 methodology for discovering and consolidating duplicate SSI 368 principles and system properties.

369
Duplication happens when SSI principles and properties 370 describe their evaluable constraints on the SSI system or its 371 features similarly in multiple proposals. The transparency 372 principle [1] and the transparency system property [4] are 373 compared in Table 1, revealing the presence of duplicate 374 constraints. We emphasize that both impose a constraint on 375 the system, requiring it to be open source. We should begin 376 by consolidating such duplications.

377
On the other hand, we discover unique constraints spec-378 ified by SSI principles and system properties. Due to the 379 VOLUME 10, 2022 particular constraints imposed by SSI principles, the SSI 380 system and its features may or may not be evaluable. From 381 Section I that the ''existence'' property has a constraint 382 described as ''any SSI is ultimately founded on the ineffable 383 'I' that is at the heart of identity,'' which may make it diffi-384 cult to evaluate the SSI system features directly. Constraints 385 that are not evaluable should be excluded to express system 386 properties that adhere to SSI principles. 387 We begin by evaluating the principles contained in three 388 proposals [1], [2], [3] in order to determine which constraints 389 can be applied to the SSI system's features under the follow-390 ing conditions:

391
(1) The SSI system or a system component thereof is the 392 subject of the constraint.

393
(2) The constraint directly restricts the SSI system features.

394
(3) The constraint can be interpreted as being evaluable on 395 the SSI system.

396
If at least one pair or group of constraints in SSI princi-397 ples meets the criteria above, we consider them necessary.

398
In Table 2, we present results for two additional SSI princi-399 ples. As we can see, the ''transparency'' principle [3] imposes 400 a constraint on the identity infrastructures that satisfy the 401 condition (1). In contrast, the ''interoperability'' principle [1] 402 includes the first constraint, which restricts the identity data 403 object. This constraint cannot satisfy conditions (1) and (2).

404
When we interpret its meaning, it is unclear how the SSI 405 system is evaluated to ensure that it is as widely usable as pos-406 sible. As a result, this constraint does not satisfy all specified 407 conditions. When non-evaluable constraints are excluded, 408 such SSI principles can be considered the same as SSI system 409 properties.

410
Then, we compare SSI principles and system properties 411 to discover duplicate constraints and combine duplicate and 412 unique constraints into a single system property. The follow-413 ing criteria should be used to make the comparison:    The criteria outlined above assist in determining which SSI 422 principles and system properties can be consolidated. The 423 points are that duplicate constraint that satisfies criterion (3) 424 should be combined into a single constraint that contains 425 all necessary information and that all principles and system 426 properties that satisfy criteria (1) and (2) should be consoli-427 dated into a single system property. As shown in Table 3, the 428 ''existence'' property is derived from three SSI principles and 429 one system property. References to sources are marked by the 430 IDs Sx, y, where S is the source identifier for A denotes [1], 431 F denotes [4], L denotes [2], and N denotes [3]; and x, y 432 denote the numbering scheme we use to refer to the yth 433 constraint of the xth principle or system property.   Table 3, the first constraint on the ''existence'' 435 property is derived from three sources. While the constraint 436 definition might be expressed differently, we consolidate it to 437 ensure that it contains all relevant information. While the final 438 constraint is not a duplicate, it is still necessary and should 439 also be included in the system property.

440
As a result, we obtain 20 consolidated system properties 441 aligned with SSI principles that sufficiently represent the 442 current state of knowledge about system properties. We can 443 consider these system properties as a single set of constraints 444 on implementing the SSI system. controls. As a result, we propose a formalization of the con-451 solidated system properties that minimize subjective interpre-452 tation and simplify subsequent analysis in this section. 453 We conducted an in-depth analysis of constraints in sys-454 tem properties and discovered that they all share a common 455 meaning. We presume that the meaning of a constraint is that 456 it restricts an SSI system activity or function that one or more 457 components conduct on data items. For instance, the first 458 constraint in Table 3 stipulates users that they must be able to 459 represent their existence and characteristics. Assuming this, 460 we define a system property as follows:   The 20 consolidated system properties in the preceding 495 section are formalized using the criteria above. Table 4 496 illustrates the formalized ''decentralized'' property in action.

497
As can be seen, the decentralized property's two constraints 498 have been formalized individually. The first constraint is an 499 example of an overly detailed constraint; it includes ''by 500 TABLE 4. Example of formalized ''decentralized'' system property. any proprietary organization'' to clarify the context of the 501 ''centrally'' phrase. We believe that only including the phrase 502 ''centrally'' is adequate to explain its meanings. The second 503 constraint is an illustration of data object omission. We dis-504 covered that the constraint omits data objects that the SSI 505 system should register and manage. By examining the context 506 and semantics of the constraint, we may assume that an iden-507 tity attribute is the omitted data object, which will be included 508 as the ''(identity)'' phrase. We use parenthesis to denote the 509 omitted phrase. We summarize the titles of 20 system prop-510 erties that we consolidated and formalized in Table 5. They 511 will serve as a set of inputs for the property enhancement 512 phase. Each of the formalized properties is denoted by the 513 abbreviation P CPx , which stands for the xth current system 514 property (CP).

517
Another source of information for our property enhancement 518 is the source documents' controls. However, because hun-519 dreds of source documents relating to information security 520 and privacy affect across business domains, the universality 521 and application of the system properties will be limited if 522 we enhance them with each individual source document. 523 Apart from that, not all source documents are compatible 524 with the SSI system or ideal for enhancing system proper-525 ties. We assume that the source documents for information 526 security and privacy contain a comparable set of evaluable 527 controls. As a result, we intend to derive such shared con-528 trols and use them as a universal set of knowledge sources 529 in our property enhancement by using a systematic review 530 approach. 531 VOLUME 10,2022 In this section, we organize the main contents into two This section explains how we derive shared controls 537 from source documents using a systematic review method.

538
To adhere to the standard procedure for system reviews,    to online resources that could provide us with an acceptable 583 and dependable list of titles of renowned source documents. 584 There are two trustworthy online resources, in our opinion: 585 collaborative or official websites and survey papers. We chose 586 Wikipedia as our source since it is a collaborative effort 587 in which anyone may contribute and verify facts. Although 588 Wikipedia is continuously updated, it provides us with a 589 measure of trust that the list of source documents published 590 has been subjected to community review. Another website we 591 choose is ISO.org [11]. ISO.org is the International Organi-592 zation for Standardization's (ISO) official website, which has 593 published hundreds of technical standards. ISO is a reputable 594 worldwide organization when it comes to acquiring technical 595 standards.

596
Another online resource that could supply us with a list of 597 source documents is survey papers, in which academics spend 598 their efforts acquiring and critically analyzing specific infor-599 mation and contextualizing it. Survey papers are extremely 600 reliable since they have been subjected to peer review. Online 601 repositories such as IEEE Xplore, ScienceDirect, Google 602 Scholar, and SpringerLink make bundles of survey papers 603 available to academics. Using the selected online resources, we can search for laws, 607 regulations, and technical standards that are applicable to 608 our property enhancement. We defined our search procedure 609 into three steps: (1) Perform a keyword-based search on the 610 selected online resources; (2) Gather the resulting source doc-611 ument from the online resources; and (3) Assess the gathered 612 source documents against our inclusion criteria. 613 First, we use the keyword-based search engines that these 614 websites and repositories provide. We created keywords (i.e., 615 search terms) to identify as many titles for information 616 security and privacy laws, regulations, and technical stan-617 dards. We describe the keywords used and the search results 618 in Table 6.

619
As shown in Table 6, we searched for survey papers using 620 the keywords ''information security and privacy laws, regu-621 lations, and standards'' in online repositories. We identified 622 only two survey papers [12], [13] that assess the present 623 state of knowledge regarding information security standards 624 and meet our requirements. Other survey papers discovered 625 lacked a list of source documents and referred to only one 626 or a few. Due to the limited number of source document 627 titles provided by the survey papers, we opted to include our 628 effort [6], which involved a manual search of information 629 security and privacy source documents. It should supplement 630 scholarly studies, providing another perspective on source 631 documents.

632
On the other hand, we used keywords to discover five 633 pages on Wikipedia that matched our requirements. They 634 looked at information technology security standards, cyberse-635 curity regulations, information privacy laws, and privacy law 636 policies. Each of these pages has a list of published source 637 documents. However, there were no matches for informa-638 tion privacy standards in Wikipedia. Finally, we identified 639 many information security and privacy standards on ISO.org.

640
All online resources are presented with the number of source 641 document titles it mentions (#Source).

642
After the first step, we obtained all source document titles 643 in a discriminate manner and attempted to obtain just those 644 that were publicly accessible and sufficient for analysis. 645 We gathered 211 distinct source documents, including 134 646 ISO technical standards, 65 laws and regulations, and 12 647 frameworks for assessing security or privacy.

648
The scope of this work is defined as being limited to the 649 211 source documents that we obtained. Additional source 650 documents may exist and be valuable for property enhance-651 ment, but we believe they may not widely be recognized due 652 to online resources' absence. We believe that the source doc- if the source documents discuss information security and 658 privacy, they will be unable to be used   2) When a control is named or entitled, we look for 757 controls with different names but a common purpose. 758 We assume that these controls are related.

759
3) If a control is unnamed or has a unique name, we find 760 comparable controls with at least one endorsed task 761 or condition, which may be justified as comparable or 762 identical. We assume that these controls are related. 763 We collect all groups of controls that are considered related 764 and create a taxonomy from which its elements can be iden- We consolidate the endorsed tasks and conditions of 776 related controls and construct a shared control from them.

777
The right-hand column of Table 8 illustrates how the 778 shared ''data accuracy and quality'' control is implemented. It demonstrates that accuracy and quality control are used 780 similarly in SD 104 , SD 152 , and SD 207 . Criterion (1) presup-781 poses that they are related. Additionally, all controls assumed 782 to be related share an endorsed task for determining whether 783 personal data is accurate, complete, and up to date. This 784 endorsed task is consolidated into the first endorsed task with 785 shared control. Additionally, we replace our representative 786 terms to make the text more comprehensible.

787
After our method, we identified 17 shared security and 788 14 shared privacy controls similarly stated in various source 789 documents. The titles of all shared controls are listed in 790 Table 10, separated into two categories: security and privacy. 791 S.j. and P.k. are used to denote the jth security shared control, 792 and the kth privacy shared control, respectively.   We begin by comprehensively analyzing the control def-799 inition. We break down control definitions into sentences 800 and consider them as endorsed tasks. We noticed that each 801 endorsed task is defined to restrict the functions or pro-802 cesses in which the evaluation targets must perform on data.

817
According to the definition, a shared control is composed of a 818 collection of endorsed tasks, each of which can be represented 819 by a triple (T e , F e , I e ), consisting of sets of evaluation tar-820 gets, controlled functions, and information controlled by the 821 endorsed task. However, omission and excessive amounts of 822 information circumstances have the potential to be analogous 823 to system properties. We also establish the following criteria 824 to complete our formalization: 825 1) We must analyze the endorsed task's context and 826 semantics and determine which phrases are omitted 827 when the endorsed task's targets or information are 828 empty (i.e., T e = ∅ and/or I e = ∅).

829
2) If the endorsed task's sentences contain excessive infor-830 mation, we must break it down and eliminate phrases 831 that create an analysis overhead. 832 We formalize all 17 shared security and 14 shared privacy 833 controls using the definition and criteria above. Table 11 834 illustrates an example of a formalized data integrity shared 835 control. It demonstrates that the data integrity shared control 836 includes five endorsed tasks, each of which is formalized 837 by Definition 2. Except for the fourth task (e 4 ), none of the 838 tasks endorsed include evaluation targets. After examining 839 the control's context, we found that the target should be 840 the system. We incorporate the phrase ''system'' into the 841 set of evaluation targets and indicate this with parenthesis. 842 On the other hand, an excessive amount of information is 843 omitted from the second task (e 2 ), specifically the phrase ''for 844 message signing and verification,'' which elaborates on the 845 ''key'' phrase.

847
In Sections IV and V, we prepared two sets of inputs 848 for property enhancement. We are now able to determine 849 whether the consolidated system properties are consistent 850 with the shared control. This section provides a clear 851 meaning of the consistency among system properties and 852 shared controls. Then we present our systematic method for 853 determining whether shared controls are already consistent 854 with any system properties and how to use the partially 855 VOLUME 10, 2022  This section will explain how we determine consistency 859 between SSI system properties and shared controls to iden-860 tify the lack of constraints in existing SSI system property 861 proposals.

862
As mentioned in Section I, we recognized that SSI system 863 properties are comparable to controls in source documents.

864
Both define how the targets should perform some operations 865 on data objects. Therefore, the consistency of a system prop- ∃x ∈ X , ∃y ∈ Y such that x can be justified to be comparable 877 to y based on evidence.  Following the previous section's formalization of consistency, 892 we can determine which shared controls have any consistent 893 system properties. The primary goal of determining consis-894 tency is to ascertain the number of shared controls consistent 895 with the existing set of system properties. This section will 896 describe our method for identifying consistencies and uti-897 lizing the resulting data to improve properties. We leverage 898 algorithms over formalizations to make our method system-899 atic. We illustrate our method overview in Fig. 9.

900
As illustrated in the figure, we present two methods: iden-901 tifying consistency and enhancing system properties. The 902 first method compares each pair of an endorsed task and a 903 constraint to ascertain their consistency. Additionally, the first 904 method classifies shared controls according to the number of 905 consistent endorsed tasks. The second method shall employ 906 various categories of shared control to enhance existing sys-907 tem properties by updating missing endorsed tasks or intro-908 ducing new system properties. Each method will be discussed 909 in detail in the next sections. In Algorithm 1, we create a semi-automatic algorithm 912 to reflect our method for identifying consistency between 913 shared controls and system properties. The algorithm 914 declares two critical procedures: identifyConsistency() and 915    which requires manual input to determine the subjective con-961 sistency of two sets of phrases.

962
If the conditions in line 7 are valid, a consistency among 963 phrases is found. Then, the determineDirection() function 964 is developed to determine how much an endorsed task is 965 different from a constraint because two sets of phrases may be 966 consistent but one set contains more information than another. 967 We define the function as a partial map determineDirection: 968 ((S, A, O), (T , F, I )) → {<, =, >}, where > indicates that 969 the constraint has more information than the endorsed task, 970 < indicates that the constraint has less information than the 971 endorsed task, and = indicates that both of them contain equal 972 or similar information. The procedure uses the variable sign 973 for denoting the direction. The direction of each pair that is 974 consistent will aid us in choosing the suitable way to enhance 975 the system property.

976
In lines 9 and 10, the procedure maintains the consistent 977 pairs of an endorsed task and a constraint in a consistency 978 resultant set (R consist ) and set the flag of consistency (flag) 979 to true. An endorsed task can be consistent with multiple 980 constraints. Then, the condition in line 11 determines whether 981 the endorsed task has any consistent constraint. If so, the 982 degree of consistency (degree) will be increased, indicating 983 how many endorsed tasks in the given shared control (C) are 984 consistent. Otherwise, the endorsed task will be maintained 985 as a missing endorsed task in the set R lack .

986
The classifyControl() procedure returns a category (type ∈ 987 {''FC'', ''PC'', ''IC''}) of shared control based on the inputs: 988 the given shared control (C) and its degree of consistency 989 (degree). The degree of consistency will be compared to the 990 cardinality of the endorsed task (i.e., |C|). If they are equal, 991 all endorsed tasks are consistent with any constraint, and the 992 given shared control can be classified as fully consistent. 993 If the degree of consistency is greater than zero but less than 994 the cardinality, the given shared control can be classified as 995 partially consistent. Apart from that, the shared control is 996 classified as inconsistent. R consist ← ∅, R lack ← ∅, degree ← 0, flag ← false 3: for (T i , F i , I i ) ∈ C do 4: flag ← false 5: for P j ∈ CPL do 6: for (S k , A k , O k ) ∈ P j do 7: if (evaluate(S k , T i , PA) or evaluate(O k , I i , PA)) and determineAssociation(A k , F i ) then 8: sign shared controls are consistent with current system properties.

999
A running example of Algorithm 1 is provided below, using 1000 a constraint from the persistence system property and an 1001 endorsed task from the shared control for data erasure and between the phrases ''SSI system'' and ''system.'' As can 1008 be seen in Table 12 Table 13. The table is presented with the cate-1029 gory of shared control, the consistency resultant triples, and 1030 the missing endorsed tasks. The non-repudiation control, for 1031 example, is classified as partially consistent. Despite that the 1032 shared control has only one endorsed task that is consistent 1033 with the protection property, it has the > direction sign, indi-1034 cating that the endorsed task has more information than the 1035 constraint. Our method reports 4 fully consistent, 13 partially 1036 consistent, and 14 inconsistent shared controls. 1037

1038
In Algorithm 2, we create a semi-automatic algorithm to 1039 reflect our method for enhancing system properties of the 1040 SSI system based on three categories of shared controls. The 1041 key idea of this algorithm is to include missing endorsed 1042 tasks in partially consistent or inconsistent shared controls 1043 into the current system properties. The enhanceProperty() 1044 procedure delivers the formalized CSSPS (CSSPS) on the 1045 inputs: a set of all results from Algorithm 1 on all shared con-1046 trols (R), and a set of consolidated system properties (CPL). 1047 In line 2, an empty set CSSPS is initialized to be a resultant 1048 set of which the revised system properties are appended. 1049 Each quadruple (C, type, R consist , R lack ) ∈ R will be used 1050 to revise system properties according to the category (type) 1051 provided.

1052
If the shared control (C) is partially consistent (PC), the 1053 determineFitOrCreate() function on line 6 will scan the set of 1054 consolidated system properties CPL and the latest CSSPS for 1055 the fit property for each missing endorsed task (T i , F i , I i ) ∈ 1056 R lack . If there is a fit property, the missing endorsed task will 1057 be added as a new constraint to the property and the property 1058 will be moved to CSSPS. Otherwise, the function will append 1059 ing constraints that include less information than the cor- As can be seen, the phrases ''SSI system'' and ''system'' 1093 are comparable, and we, therefore, include only the phrase 1094 ''SSI system'' in S merge . The terms ''identities'' and ''data'' 1095 refer to the same idea in O merge . By contrast, the constrained 1096 action set contains elements from both A i and F j . The revise() 1097 function at line 10 will revise the triple of merged constraints 1098 and copy the corresponding property to CSSPS. As a result, 1099 when Algorithm 2 was executed, 42 system properties for the 1100 SSI system in the CSSPS were acquired. The resulting system 1101 properties are in a formalized form.

1103
As a result of our approach, the CSSPS is described in the for-1104 malized system properties, which may make adoption more 1105 difficult. This section describes our method for converting the 1106 formalized system properties back to plaintext. 1107 We discovered that the enhanced system properties con-1108 straint should be written in plaintext to make acceptance and 1109 translation into system requirements easier. The formalized 1110 constraint is compared to the constraint specifications for 1111 the consolidated system properties and the endorsed task to 1112 achieve this. The excessive amount of information that may 1113 be excluded under our Sections IV-B and V-B criteria should 1114 be carefully considered. Our method aims to incorporate 1115 all specific information required by the formalized CSSPS 1116 and provide a plaintext description of the CSSPS. Table 14 1117 demonstrates how we formulate the persistence system prop-1118 erty in CSSPS. It demonstrates how we revise the constraint 1119 by inserting all two critical points from the set of constrained 1120 actions (A) and substituting information such as the sentence 1121 ''the corresponding user wishes to modify, revoke, or delete 1122 them'' into the plain text.

1123
On the other hand, we realized that the CSSPS has over 1124 40 system properties, which may make it difficult for sys-1125 tem implementors to integrate it quickly. We categorize the 1126 system properties into five categories to aid in adoption if 1127 system implementors need to comply with only a subset of 1128 them: SSI foundation, information security, system security, 1129 information privacy, and ease of use. In Fig. 10, we present 1130 the taxonomy of system properties in CSSPS. Each system 1131 property in CSSPS is designated by the identifier IPx, where 1132 x denotes the xth system property in CSSPS according to our 1133 ordering approach. for (C, type, R consist , R lack ) ∈ R do 4: if type = ''PC then 5: 8: if sign = > then 9: else if type = ''IC then 12: for , CPL, CSSPS) 14: return includeExistingProperty(CPL, CSSPS)

1135
The CSSPS is offered as a new set of system properties for  The sets of system properties and the set of source documents 1182 consistent with the SSI system's system properties are two 1183 groups of independent variables in our experiment. 1184 We defined two distinct sets of system properties: one for 1185 the present proposal and another for the CSSPS. The existing 1186 set is derived from the list of consolidated system properties 1187 obtained in Section IV, as it combines four proposals. This 1188 should be an excellent depiction of the property proposal's 1189 current state. On the other side, we will evaluate the CSSPS in 1190 contrast to the existing set of consolidated system properties. 1191 For the set of source documents, we divide our source 1192 documents into two categories: those that were used to 1193

1221
In this section, we describe our experimental procedure and 1222 provide our findings in the following manner:  We illustrate an overview of our experimental procedure in 1231 Fig. 11. As illustrated in the figure, our experimental proce-1232 dure consists of two rounds. The analyst is asked to compare 1233 the existing set of consolidated system properties to the four 1234 source documents in the first round. We request justification 1235 from the analyst on why the system properties are consistent 1236 with the controls in each source document. In the second 1237 round, we request that the analyst compare the identical set 1238 of source documents to the CSSPS's system properties. After 1239 both rounds, we collect the analyst's decisions, justifications, 1240 and comments. Then, using Equations 3 and 4, we calculate 1241 the percentage of consistency and the difference between 1242 the existing set of consolidated system properties and 1243 the CSSPS. We summarize the computed percentages of consistency 1246 and differences in Table 15. It can be observed that the 1247 source column indicates the source documents used in the 1248 comparison, and the TC column represents the number of 1249 controls provided by the source document. The XC Exist and 1250 PC Exist columns indicate the number of controls in the source 1251 document (source) and the percentage of consistency that 1252 are consistent with system properties in the existing set, 1253 respectively. Similarly, the XC CSSPS and PC CSSPS denote 1254 the number of controls and the percentage of consistency 1255 that properties in the CSSPS are consistent with the source 1256 document (source). The last column reports the difference in 1257 consistency between the existing set of consolidated system 1258 properties and the CSSPS.

1259
There are crucial pieces of information that demonstrate 1260 the CSSPS's success in terms of consistency percentages. 1261 Below, we discuss each observation we made: 1262 Finding 1: The differences ( Exist,CSSPS ) indicate a higher 1263 level of consistency across all source documents used in our 1264 enhancement.

1265
In almost every control, the CSSPS can be consistent with 1266 two source documents in the case of the source documents 1267 utilized in our enhancement. Each source document contains 1268 a single control that is deemed inconsistent. The analyst con-1269 tends that the existence system property appears to violate the 1270 fundamental concepts of the SSI. For example, the GDPR's 1271 storage limitation control is consistent with the CSSPS's 1272 properties, except that it defines storage for public interest 1273 purposes, which may contradict the users' initial consent. 1274 VOLUME 10, 2022  By adjusting independent variables and measuring dependent 1317 variables, we build an experiment to test our hypothesis. 1318 Below, we detail each of the settings used in our experiment: 1319 a: DEPENDENT VARIABLE 1320 We are interested in possession of system property in 1321 real-world SSI systems as a dependent variable. However, 1322 we examine such possessions solely based on the SSI sys-1323 tem's documentation. Occasionally, the documentation is 1324 insufficient to ascertain whether the SSI system possesses 1325 the required system properties. As a result, we establish three 1326 distinct types of system property possessions:

1327
• Yes indicates that the documentation proves that the SSI 1328 system possesses the system property.

1329
• Unclear indicates that the documentation did not pro-1330 vide any evidence that the SSI system possesses the 1331 system property, but we can justify it based on the SSI 1332 system's functions and internal mechanisms that the SSI 1333 system may possess.

1334
• No indicates that the documentation provides some evi-1335 dence that the SSI system's functions or internal mech-1336 anisms conflict with the system property.

1337
Each system property and real-world SSI system will be 1338 assigned one of the three types of possessions. In this experiment, we defined two independent variables: the 1341 set of CSSPS system properties and real-world SSI systems. 1342 We would include all 42 system properties in the CSSPS in 1343 the analysis, even if our work did not enhance them.

1344
For the set of real-world SSI systems, we chose three 1345 industrial-level products of the SSI system to cover the broad 1346 landscape of the real-world adoption: uPort, Sovrin, and IBM 1347 Verify Credentials. These SSI systems are different in size, 1348 features, and marketing targets. 1349 uPort is an SSI system product that does not adhere to 1350 the SSI system's commonly used open standards, namely 1351 DID and the Verifiable Credential data model. Numerous 1352 articles [51], [52] have alluded to uPort as a sample of SSI 1353 systems. uPort has been phased out and replaced by another 1354 product called Veramo. However, it remains an excellent 1355 representative of SSI systems with distinct features and tech-1356 nology. We use a white paper by uPort [53] as a data source 1357 for our evaluation.

1358
Then, Sovrin is an SSI governance network that provides 1359 trustworthy blockchain validators who act as the net-1360 work's stewards. Sovrin simply provides the decentralized 1361 network and connects implementors' development appli-1362 cations to it. However, Sovrin suggests an architecture 1363 of edge-cloud agents that is compatible with the Sovrin 1364  TABLE 15. Percentages of consistency and the differences of consistency collected from the experiment session. Network's connectivity. Sovrin is a representative of the SSI system that operates under the stringent administration of a 1366 decentralized network. We analyzed using data from a white 1367 paper [54] provided on Sovrin's website.  We can observe that 11 system properties in the CSSPS 1400 are marked as Yes in all products (for example, the existence 1401 property). This case demonstrates that real-world products 1402 already possess those eleven system properties. Following 1403 that, we consider 23 system properties indicated by a combi-1404 nation of Yes and Unclear. It indicates that real-world prod-1405 ucts may not place a premium on documenting such system 1406 properties. However, given the existing technology, features, 1407 and functions available, we may justify that these system 1408 properties have the potential to be included in products. 1409 Finally, we can see that those six system properties in the 1410 CSSPS are marked as No due to incompatibility with the 1411 technology employed or difficulty in adopting such system 1412 properties.  Table 18 demonstrates an example of the possession types 1417 of the ''data recovery'' system property in three products. 1418 This property is worth focusing on because it was marked 1419 as Yes, Unclear, and No in different products. The uPort 1420 is the only product that clearly mentions the mechanism 1421 to recover the wallet through the recovery contacts. It is 1422 adequate to mark uPort as Yes. However, the documenta-1423 tion for Sovrin implies an edge-cloud design, in which per-1424 sonal data is kept on a potentially lost artifact. It is up 1425 to implementors to provide procedures for recovering edge 1426 agents. We cannot locate such mechanisms in the present 1427 documentation. As a consequence, we are classifying this 1428 as Unclear. Finally, the IBM VC is listed as No since its 1429 edge agents exclusively serve as credential storage. The IBM 1430 VC only permits the re-issuance of credentials when the 1431 edge agent is lost or destroyed. As a result, data recovery 1432 looks to be challenging to execute in the present state of the 1433 IBM VC.  First, we observed that our property enhancement could explicitly identify consistency between the existing system 1442 properties and the shared controls and use the results as 1443 information to enhance the system properties. The differences 1444 ( ) in Section VII-A reflect that the CSSPS has enhanced its 1445 consistency in all cases. The results also indicate that, in the 1446 cases of source documents used to enhance the system proper-1447 ties, the CSSPS can achieve greater than 85% of consistency.

1448
Only one control is missing for each source document due 1449 to a conflict with the SSI system's fundamental concepts.

1450
Additionally, the results ensure that an SSI system achieving 1451 the CSSPS is highly likely to comply with applicable laws, 1452 regulations, and technical standards. 1453 Second, we observed that deriving shared controls con-  information security and privacy controls and evaluation 1458 objectives. The experimental findings reported in Table 15 1459 show that the CSSPS enhances approximately 10% of con-1460 sistency in the case of source documents that were not used 1461 in our enhancement. This benefits implementors who are 1462 concerned about and seek to enhance the level of information 1463 security and privacy in their implementation of the SSI system 1464 with minimal effort. 1465 We identified one shortcoming that affects the degree of 1466 consistency: the broad definition of controls. A control may 1467 specify the tasks for which it is endorsed, which may apply to 1468 both software applications and organizations. Incorporating 1469 such endorsed tasks into the CSSPS may help ensure the SSI 1470 system is implemented in accordance with them, but this does 1471 not ensure that auditors will agree that the controls are being 1472 followed in all areas.

1474
The ability to apply the CSSPS in real-world SSI systems 1475 is necessary to ensure the CSSPS's adoption. We discov-1476 ered three noteworthy advantages and a shortcoming of the 1477 CSSPS, and we will discuss them in this section.

1478
First, we observed that current SSI systems already influ-1479 ence most system properties in the CSSPS. According to the 1480 findings in Section VII-B, 35 of 42 system properties in the 1481 CSSPS are considered as Yes or Unclear, indicating that about 1482 84% of them have the potential to be adopted by existing SSI 1483 systems.

1484
Second, we observed that system properties designated 1485 as Unclear are potentially useful even if they are not 1486 documented. The findings indicate that current technolo-1487 gies and architectures of SSI systems may support the 1488 CSSPS. It enables implementors to examine the CSSPS and 1489 incorporate them into future versions of SSI systems to elicit 1490 requirements.

1491
Finally, we discovered that the CSSPS might be used to 1492 improve data security and privacy. The CSSPS meets the 1493 consistency with source documents pertaining to information 1494 security and privacy while allowing adoption in real-world is advantageous to implementors because it enables them to 1497 focus their efforts on developing an SSI system and possess- dictates that they act as constraints rather than requirements.

1508
It is important to define corresponding system requirements 1509 to achieve system properties. We are unable to define sys- Unclear may be adopted. 1540 Finally, the shared controls required to enhance the prop-1541 erty are retrieved from a specific version of the source doc-1542 uments. Shared controls may become outdated when laws, 1543 regulations, and technical standards are regularly changed. 1544 We believe that the shared controls were derived and inte-1545 grated from several source documents, and that not all source 1546 documents will be changed at the same time. Furthermore, 1547 the concepts of information security and privacy are likely 1548 to stay intact. The shared controls should not be affected by 1549 modifications made to specific source documents. 1550 2) EXTERNAL THREATS 1551 We detected an external threat to the validity of this work: 1552 the analysis of applicability was limited to three real-world 1553 SSI systems. However, this threat is mitigated by various 1554 product sizes, features, and target markets. We made an effort 1555 to incorporate as many real-world SSI systems as feasible. 1556 We selected to cover the various sizes with a smaller-sized 1557 product (uPort) and a larger-sized product (Sovrin and IBM 1558 VC). Additionally, although others do, uPort does not fully 1559 embrace the SSI system's fundamental concepts. This may 1560 reflect some differences in the features. This external threat 1561 should be addressed during the careful selection process.

1563
In this section, we compare our proposal for the CSSPS 1564 with other proposals for SSI system principles and properties. 1565 In addition, we compare our work to other studies to deter-1566 mine the value of utilizing CSSPS properties.
1567 Table 19 details the comparison between our work and 1568 other proposals. As the principles and properties are deemed 1569 crucial to the development of SSI systems, there have been 1570 numerous proposals to analyze and enhance them. The table 1571 indicates that, to our knowledge, five works have been pub-1572 lished previously [1], [2], [3], [4], [6]. 1573 Allen [1] offered ten basic principles, generally acknowl-1574 edged as the SSI system's guiding principles. His proposal, 1575 however, is limited to constraining the fundamental concepts. 1576 Regarding the degree of consistency, the CSSPS is more 1577 compliant with information security and privacy require-1578 ments than his proposal, as we incorporate missing endorsed 1579 tasks of source documents' controls. In terms of application, 1580 we believe that Allen's proposals and the CSSPS are equiv-1581 alent, as several of the system properties in the CSSPS are 1582 similar to those in Allen's. The CSSPS is superior to Allen's 1583 proposal since it addresses information security and privacy 1584 concerns and adheres to source documents more closely.

1585
As Allen was the first to propose a set of guiding prin-1586 ciples for the SSI system, all subsequent works referenced 1587 his proposal, and three of them [2], [3], [6] used Allen's 1588 principles to improve security and privacy. Nevertheless, it is 1589 clear that only one of the existing proposals [6] addresses 1590 both security and privacy. None of them, however, included 1591 compliance with a large number of laws, regulations, and 1592 technical standards. 1593 Naik and Jenkins [3] were the first to incorporate concerns 1594 about data privacy into the SSI system's principles. They 1595 enhanced Allen's basic principles to make them consistent 1596 with GDPR. The inclusion of concerns about information 1597 privacy from the GDPR's privacy principles in their proposal 1598 contains a few references to demonstrate which sections 1599 are adopted. The CSSPS is more compliant in term of 1600 VOLUME 10, 2022   In summary, the CSSPS is more comprehensive than theirs 1607 in terms of consistency and shares similar applicability.

1608
In conclusion, the CSSPS could meet the requirements 1609 of security and privacy in the SSI system's principles and   1618 We enhanced the SSI system's existing properties to increase 1619 its likelihood of compliance with applicable laws, regula-1620 tions, and technical standards. We use a methodical approach 1621 to reviewing source documents and determining whether 1622 their controls are consistent with existing system properties. 1623 We searched through 211 source documents and discovered 1624 28 that are suitable for property enhancement. We extracted 1625 17 shared security and 14 shared privacy controls from the 1626 selected source documents. Then, we combined four different 1627 proposals for SSI principles and system properties to arrive 1628 at a relative set of 20 system properties. We analyzed shared 1629 controls and consolidated system properties in order to iden-1630 tify tasks that were not endorsed. We introduced the CSSPS, 1631 a collection of 42 system properties that should be consistent 1632 with shared controls from source documents.

1633
Through a series of experiments, we evaluated the CSSPS. 1634 The findings indicate that the CSSPS increases the percentage  We recommend future directions for this work to address 1640 the shortcomings associated with subjective interpretation 1641 of technical requirements by specifying and verifying such 1642 system properties using some formal methods. Additionally, 1643 we look forward to distributing and standardizing the CSSPS. 1644 Conforming system properties to shared controls derived 1645 from laws, regulations, and technical standards is also appli-1646 cable to other critical systems and information systems that 1647 manipulate PII. It should provide a significant opportunity to 1648 improve the security and privacy of other systems.
He was a Senior Technical Leader with the Department of Iden-1814 tity and Access Management, Security Division, G-Able Company Ltd., 1815 from 2017 to 2019. His research interests include software engineering, 1816 identity and access management, information security and privacy, natural 1817 language processing, and formal methods.