Rethinking Self-Sovereign Identity Principles: An Actor-Oriented Categorization of Requirements

Rethinking Self-So v ereign Iden tit y Principles: An A ctor-Orien ted Categorization of Requiremen ts Daria Sc humm [0009 − 0004 − 1154 − 4799] and Burkhard Stiller [0000 − 0002 − 7461 − 7463] Univ ersity of Zürich Binzm ühlestrasse 14, CH—8050 Zürich, Switzerland [schumm, stiller]@ifi.uzh.ch Abstract. Cen tralized iden tity managemen t systems contin uously exp erience securit y and priv acy challenges, motiv ating the exploration of Decen tralized Identit y (DI) and Self-Sov ereign Iden tity (SSI) as user-fo cused alternatives. Although prior researc h has consolidated SSI principles and deriv ed quality requiremen ts for DI/SSI systems, it is significan tly limited in in tegrating the user viewp oin t. This work addresses this gap b y embedding a user p ersp ective into the requiremen ts engineering process for DI/SSI systems. Building on existing SSI principles, comp osite requiremen ts w ere decomp osed into 24 simple quality or non-functional requiremen ts (NFR). The resulting NFR are systematically mapp ed to the k ey actors, namely data o wner, issuer, verifier, and system, based on v arying degrees of resp onsibility and o wnership. A dep endency mo del is introduced to formalize relationships b etw een actors. Inspired by trust mo deling concepts, the mo del explicitly describes ho w actors interact and rely on each other for requirements fulfillment. By in tegrating user-centered requirements, resp onsibilit y allo cation, ownership specification, and dep endency mo deling, this work provides the first structured mo del for DI/SSI system architectures. Keyw ords: Decentralized Iden tity · Self-So vereign Identit y · Requiremen ts Engineering · System Mo deling 1 In tro duction With the gro wing num b er of vulnerabilities in centralized iden tit y managemen t, illustrated by numerous data breac hes [18,1], other alternativ es should be considered to enable more secure handling of p ersonal data. Decen tralized Iden tity (DI) and Self-Sov ereign Identit y (SSI) offer an alternativ e to traditional iden tity management approaches b y enabling data o wners to retain con trol ov er their identit y data without reliance on centralized services. Existing DI/SSI systems largely build on SSI principles, such as existence, con trol, and persistence, originally introduced b y [5]. Other w orks, suc h as [9], extended these principles and provided more elab orate descriptions 2 Sc humm and Stiller and classifications based on m ultiple sources ( e.g. , [5,11,23,4]). [9] outlined a comprehensiv e set of quality requirements that comp ose a DI/SSI system. The authors classified identified requirements into five categories, namely security , priv acy , adoption and sustainability , usability and user exp erience, and con trollability , and prioritized them based on the exp ert’s feedback. The main limitation of [9] is the lack of an individual user p ersp ective on requirements, whic h largely misrepresents the actual users and user-fo cused approach of DI/SSI. Similarly , DI/SSI design patterns, presen ted in [10,17], provide a limited p ersp ective on user roles and requiremen ts but comprehensively outline the functionality and interactions of DI/SSI systems. Design patterns are frequen tly used in softw are engineering to define how a certain ob jectiv e in soft ware dev elopment can b e achiev ed and to describe a solution to a recurring problem [19]. In the context of DI/SSI, there is currently no explicit mapping b et ween the established design patterns and the quality requiremen ts they are in tended to address. The ob jectiv e of this work is to address the lac k of a user viewp oin t within the DI/SSI domain and to em b ed the user into the requiremen ts engineering pro cess. T o address this ob jective, this w ork builds on the requirements aggregated by [9]. Some comp osite requirements ( e.g. , existence and representa tion) hav e b een brok en do wn into indep endent, simple quality requirements or non-functional requiremen ts (NFR), resulting in a total of 24 requirements, as outlined in T able 1. Design patterns, outlined in [10,17], w ere considered to iden tify goals, interests, and inv olv ement of v arious users (or actors) within DI/SSI systems, as well as explicitly map them to the requiremen ts presented in T able 1. As a result, this work contributes (i) a refined set of user-centered requiremen ts that consistently reflect a user-based viewp oint, (ii) sp ecification of resp onsibilities and ownership for each requirement across users, and (iii) a dep endency mo del that sp ecifies where, when, and by whom eac h requiremen t is realized within DI/SSI systems. This work is organized as follows. Section 2 sp ecifies a generalized use case, definitions used throughout the pap er, and the metho dology that was used to map and categorize requiremen ts. Section 3 maps design patterns and NFR, follo wed by Section 4, which provides a concise discussion of each NFR concerning its assignment. Section 5 summarizes the results of NFR categorization and introduces the dep endency mo del for DI/SSI systems. Section 6 concludes the w ork and indicates future work. 2 Use Case, Definitions, & Metho dology Categorizing requiremen ts requires a clear understanding of who is responsible for what within the DI/SSI system. First, a generalized use case is described to illustrate the fundamental pro cesses common to all DI/SSI systems. Then, the users of a DI/SSI system are defined, along with k ey concepts, suc h as resp onsibilit y and o wnership. Lastly , the three-step metho dology for systematic requiremen ts categorization is outlined. Title Suppressed Due to Excessive Length 3 T able 1. Non-F unctional Requiremen ts of DI and SSI Systems Key Qualit y Description NFR1 A ccessibility User must b e able to access and retriev e data NFR2 Authen ticity Source of identit y data m ust b e trust worth y and pro v able NFR3 Autonom y User m ust b e able to manage their identit y indep enden tly NFR4 A v ailabilit y Iden tity data must b e a v ailable at any time NFR5 Compatibilit y Iden tity data must b e compatible with legacy systems NFR6 Consen t User must explicitly consen t to the use of their data NFR7 Con trol User must b e able to con trol access to their iden tity data NFR8 Cost All comp onents must hav e minimal costs NFR9 Decen tralization All components should not rely on centralized elements NFR10 Existence User identit y must hav e an indep endent existence without relying on other services NFR11 In terop erability Iden tity data must b e usable across different platforms and services NFR12 P ersistence Iden tity data must remain v alid and accessible for as long as necessary NFR13 P ortability User must b e able to mov e their identit y data NFR14 Priv acy User m ust b e able to minimize information required to share NFR15 Protection Iden tity data m ust be protected against misuse NFR16 Reco verabilit y User must b e able to recov er identit y data in case of loss and compromise NFR17 Represen tation Users must b e able to create multiple identities NFR18 Securit y All comp onents m ust ensure the data is secure NFR19 Single Source User must b e the single authoritative source of their iden tity NFR20 Standard Creden tials m ust adhere to op en standards NFR21 T ransparency Information ab out data use m ust be readily av ailable NFR22 Usabilit y User must b e able to use their data efficiently and in tuitively NFR23 User Exp erience Iden tity managemen t process must be simple, consisten t, and user-friendly NFR24 V erifiability Iden tity data must b e v erifiable 4 Sc humm and Stiller 2.1 Generalized Use Case Use cases provide a structured mec hanism for analyzing resp onsibilities and requiremen ts within a system [16]. The DI/SSI domain has numerous use cases, ranging from healthcare to education. By omitting implementation details, eac h use case reveals a recurring pattern. F or example, a DI/SSI system for a go vernmen t service and for even t tick eting migh t ha ve differen t goals, but they represen t the same underlying functionalities and in volv e the same core stak eholders or users ( e.g. , credential issuer and verifier), and rely on the same fundamen tal pro cesses ( e.g. , credential issuance and verification). A shared goal of b oth systems is the “identification of a human”, adapted to a different con text. The v alidity of a generalized use case argumen t is supp orted b y evidence from existing systems. F or example, Sovrin [3] and IDunion [2] op erate in differen t regulatory and op erational environmen ts. How ev er, they b oth rely on common arc hitectural comp onents ( e.g. , a data owner) and technical features ( e.g. , V erifiable Creden tials (VC)) to achiev e their goals. F urthermore, the systems share comparable design choices in credential lifecycle management and priv acy-preserving user con trol, including creden tial issuance, presen tation, and verification. These recurring patterns across implementations suggest a common underlying mo del that captures these fundamental pro cesses. Moreo ver, the existence of design patterns for DI/SSI systems further suggests that certain aspects are not only generalizable but are necessary to describe the core functionalit y and capabilities of any DI/SSI system. T o form ulate a generalized use case, this work follo ws the approach outlined in [16]. The metho d b egins by defining the final state of the system and then expands it in to in termediary steps required to reac h that state. In a DI/SSI system, the end goal is for a data o wner to get authen ticated and authorized for a specific service of their c hoice. The use case, therefore, begins with the data owner requesting a creden tial from an issuer. The issuer then issues a creden tial, either using an existing creden tial sc hema or creating a new one, based on the information it holds about the data owner. As the next step, the data owner presen ts a credential to the verifier for verification. During v erification, the verifier verifies the issuer’s signature and c hecks whether the creden tial has b een revok ed. Once verification is complete, the v erifier considers the data o wner authorized to access the service or authen ticated and enables access. 2.2 Definitions Eac h requirement outlined in T able 1 w as assigned to one or more relev ant primary users, namely data o wner, issuer, or v erifier, as defined by the W3C standards [15,22,21]. A system pro vides an interface to users and is treated as a separate comp onent in this w ork b ecause it supp orts multiple user in teractions. A system is divided into global and local components, indicating that it has t wo interfaces. The following definitions of comp onents are used throughout this w ork: Title Suppressed Due to Excessive Length 5 – The data owner ( o ; or identit y owner, DID sub ject) is the entit y that receiv es, stores, and presen ts a credential (or VC). – The issuer ( i ) creates and signs credentials, asserting claims about the data o wner. – The verifier ( v ) requests and verifies the v alidity of credentials presen ted by the data o wner. – A glob al system ( s ), referred to simply as a system, represen ts a block chain comp onen t that enables decentralization of the identit y management system. – A lo c al system , referred to as a w allet ( w ), is softw are that the data o wner in teracts with. Eac h component can b e referred to as an actor . A ctors are domain stak eholders who in teract with one another to achiev e goals [8]. An actor has a goal within a system and represents agents, such as an organization or a p erson [14]. A go al is the interest of an actor, which can b e satisfied with a specific task [14]. An actor has a certain level of resp onsibility for an NFR. The r esp onsibility is a relationship betw een t wo actors with resp ect to a particular state of affairs, capturing the underlying reasons why an actor p erforms a given action [7]. Resp onsibilities can b e satisfied dir e ctly by p erforming a role or indir e ctly by delegating resp onsibilit y to another actor [7]. A r ole refers to “what has to b e done” and provides an abstraction for actions, which change the system state (in other words, functions) [7]. In this work, resp onsibility is classified as primary (direct), secondary (supp orting), or tertiary (indirect influence). – Primary responsibility refers to the fundamen tal resp onsibility that an actor p erforms directly and guaran tees its fulfillment. – Se c ondary resp onsibility reflects a supp orting role, where an actor facilitates the p erformance of another actor’s resp onsibility . – T ertiary resp onsibility indicates indirect resp onsibility , where an actor b enefits from or relies on others to p erform the fulfillment. Similarly , an actor ma y ha ve ownership ov er NFR. Ownership represen ts whic h actor is an o wner of a service, goal, task, or resource [13,14]. The owner has exclusiv e authority ov er a service or access, and their enforcement [14]. 2.3 Metho dology Eac h assignment of a requirement to an actor is supp orted b y a concise justification, based on actor roles, resp onsibilities, and architectural relev ance. The justification was formulated by considering whether an actor has a stake in, deriv es benefits from, or is responsible for enforcing a particular soft ware qualit y , dra wing on relev ant literature, particularly [9,10,17]. Overall, the categorization pro cess follow ed three steps metho dology , namely (i) iden tification of goals and in terests of actors, (ii) resp onsibilit y , and (iii) o wnership assignments. 6 Sc humm and Stiller As the first step, the goals and in terests of each actor were iden tified through a literature review of DI/SSI design patterns ( e.g. , [9,10,17]) and relev ant standards ( e.g. , [15,22,21]). The analysis fo cused on iden tifying which soft ware qualities each actor is inheren tly resp onsible for, b enefits from, or relies on. F or example, priv acy preserv ation for the data o wner, as the data is o wned by them and they ha ve a primary interest in keeping it priv ate. Similarly , verifiabilit y for the v erifier, b ecause the primary goal of the v erifier is to v erify a creden tial. As the second step, the relev ance and impact of eac h NFR on actors were ev aluated through a structured assessment that assigned eac h actor a degree of resp onsibility for the NFR. F or example, the data owner is resp onsible for storing their own data, thereby b earing primary resp onsibility for accessibilit y . Lastly , ownership was assigned to each actor. F or example, the data o wner owns their p ersonal data, whereas the verifier should seek consent to pro cess it. 3 Mapping Design P atterns to Requirements This section maps DI/SSI requiremen ts to the design patterns describ ed in [10] and [17], which serve as the basis for the requirements categorization presented in the next section. Although design patterns are not requirements sp ecifications, they still implicitly provide necessary information ab out functional requirements (FR) and NFR. F or example, [17] outlines the benefits of the “Master and Sub Key Generation” pattern as identifiabilit y , priv acy , and a v ailability . In addition to these qualities, the pattern also implies functional asp ects, such as “master-key manages sub-keys”, “sub-keys used for signing messages”, and “sub-key is linked to a unique iden tifier”. These statemen ts are similar to FR, as they describ e sp ecific system capabilities and b ehaviors. How ever, not all identified b enefits corresp ond directly to the NFR used in this work. F or instance, “identifiabilit y”, men tioned in [17], do es not directly match any of the NFR in T able 1, while other b enefits, suc h as “priv acy” and “a v ailabilit y”, align well with NFR. Both [10] and [17] sp ecify the qualit y b enefits of each design pattern. Therefore, it is p ossible to systematically map these patterns to NFR they in tend to supp ort. T able 2 presents an example of the resulting mapping b et ween five NFR and their corresponding design patterns, based on the b enefits describ ed. Several NFR identified in this w ork are not addressed by the existing design patterns. In particular, no design pattern explicitly supp orts the autonom y , compatibility , consen t, existence, p ersistence, and user exp erience requiremen ts. Despite these gaps in design patterns, the mapping provides a v aluable starting p oint for systematic analysis of NFR. The complete mapping b et ween design patterns and NFR is provided in T able 2 of the App endix 1 . 1 h ttps://github.com/sc hummd/categorization Title Suppressed Due to Excessive Length 7 T able 2. Example of Mapping Design Patterns and Non-F unctional Requirements Key NFR Design Patterns [10] Design Patterns [17] NFR1 Accessibilit y Public Institution Registry; T rusted Sc hemas Registry; Status Registry; Decen tralized Iden tifier (DID) Registry; Public DIDs; Lo cal (Priv ate) Storage; External (Remote) Cloud Storage - NFR2 Authenticit y V erifiable ID; Dual Resolution; Qualified V erifiable Creden tials (VC; V C signing); Binding VCs and Qualified Electronic Certificates - NFR3 Autonomy - - NFR4 A v ailability Status Registry; DID Registry; Public DIDs Master and Sub Key Generation; Multiple Registration NFR5 Compatibility - - 4 Categorizing Requiremen ts F ollowing the metho dology outlined previously , 24 NFR were analyzed and categorized, resulting in the assignment of each NFR to an actor, the justification for the assignmen t, as w ell as the iden tification of resp onsibilit y and o wnership of an actor ov er NFR. T able 3 summarizes the categorization results. NFR1: Accessibilit y may refer to tw o different things. First, accessibility ensures that the data is in an accessible format, allo wing users, regardless of ability , to use it [21]. The typical approach to ensure accessibility is to follo w a certain standard on data represen tation and format, suc h as DID or VC, defined b y W3C [22,21] How ever, in DI/SSI, accessibility refers to data accessibilit y . That is, how easy it is to lo cate and access the data. The data o wner is resp onsible for storing their own data and, thus, is the primary actor resp onsible for lo cating and accessing it. The v erifier has a tertiary resp onsibility b ecause they b enefit from the data owner p erforming the fulfillment. In other words, the v erifier uses the data pro vided b y the data owner. The issuer has no direct resp onsibilit y for data access. Nevertheless, they need to access credential sc hemas to enable effectiv e credential issuance [20]. Therefore, an issuer is not responsible for the 8 Sc humm and Stiller T able 3. Categorization, Resp onsibility , and Ownership of Non-F unctional Requiremen ts Resp onsibilit y Key Qualit y o v i Ownership NFR1 Accessibilit y Primary T ertiary - o , w NFR2 Authenticit y T ertiary Secondary Primary i NFR3 Autonomy Primary - - o NFR4 A v ailability Primary - - o , w NFR5 Compatibility T ertiary Secondary Primary i NFR6 Consent Primary Primary Primary o NFR7 Control Primary - - o , w NFR8 Cost T ertiary T ertiary T ertiary s NFR9 Decentralization T ertiary T ertiary T ertiary s NFR10 Existence Primary - - o NFR11 Interoperability T ertiary Secondary Primary i NFR12 Persistence Primary - - o NFR13 Portabilit y T ertiary - - w NFR14 Priv acy Primary Primary Secondary o , v , i NFR15 Protection Primary - - o , w NFR16 Recov erability Primary - - w NFR17 Representation Primary - - o NFR18 Security T ertiary T ertiary T ertiary s NFR19 Single Source Primary - - o NFR20 Standard T ertiary Secondary Primary i NFR21 T ransparency T ertiary Primary Primary i , v NFR22 Usability T ertiary - - w NFR23 User Exp erience T ertiary - - w NFR24 V erifiability T ertiary Primary Secondary v , i Title Suppressed Due to Excessive Length 9 definition of accessibility used in this work. Ownership of NFR1 is assigned to the data owner, who is primarily resp onsible for storing, accessing, and retrieving the data, and to the lo cal system (wallet), which enforces accessibility . NFR2: The issuer is primarily resp onsible for the authen ticity of the creden tial. Authenticit y is achiev ed by attac hing a signature to the credential, whic h can later b e verified to attest to the authenticit y of the information [9]. The verifier verifies the signature created by the verifier (the resp onsib ilit y of the issuer), thereb y fulfilling secondary responsibility . The data o wner has a tertiary resp onsibilit y b ecause they b enefit from the issuer’s fulfillment of that resp onsibilit y . That is, an authentic and v erifiable signature ensures the creden tial is v alid and the data o wner can access or use a service. Ownership of NFR2 is assigned to the issuer, who is primarily responsible for the correctness and authen ticity of the issued credentials. NFR3: Autonom y NFR refers to the abilit y of the data owner to manage their iden tity indep endently of other actors and entities. The data owner is primarily resp onsible for this NFR and is the owner, while the v erifier and issuer are not in volv ed in this NFR. NFR4: A v ailability refers to the contin uous av ailability of identit y data. Since the data owner is resp onsible for storing and retrieving the data, they must also ensure that the data is av ailable to them at any time and others when necessary [9]. Th us, the data o wner owns and is primarily responsible for NFR4. The o wnership of NFR also b elongs to the local system (W allet) b ecause it supp orts its tec hnical enforcement. NFR5: The identit y data m ust b e compatible with legacy systems, other wallets, and infrastructures [9]. Since the issuer is primarily resp onsible for issuing a creden tial and ensuring it adheres to the standards, the issuer is also resp onsible for and owns the compatibilit y NFR. The v erifier has a secondary resp onsibility b ecause it facilitates verification, which may be p erformed by a different system than the one in which the credential was issued. Th us, verifiers facilitate the p erformance of compatibilit y . The data o wner has the tertiary responsibility o ver compatibilit y , since they b enefit from credentials b eing widely usable and v erifiable across different infrastructures. How ever, it is important to note that compatibilit y is not visible to the data owner due to wallet abstractions [9]. NFR6: The data owner has primary responsibility for providing consent to any access to and use of their p ersonal data [9,20]. Additionally , the verifier is primarily resp onsible for obtaining the data owner’s consen t for the collection, pro cessing, and storage of data [9]. Moreov er, the issuer is primarily resp onsible for obtaining the data owner’s consent b efore issuing a creden tial that contains p ersonal data [9]. How ever, this is typically done outside of the DI/SSI system. Ownership of NFR6 lies with the data owner. 10 Sc humm and Stiller NFR7: Con trol refers to a user’s ability to manage access to their p ersonal data. Since the data owner is resp onsible for storing and retrieving the data, control lies with them. Neither the v erifier nor the issuer has con trol o v er the data o wner’s p ersonal data. A lo cal system or a wallet also has ownership of NFR7 b ecause it tec hnically supp orts data protection. NFR8: Cost affects all actors of a DI/SSI system. Data owner, issuer, and verifier all hav e a tertiary resp onsibilit y , since there is no direct fulfillment resp onsibilit y , but they all b enefit from its fulfillment. The o wnership of this NFR lies with the DI/SSI (global) system b ecause the costs are ro oted in the softw are application’s design c hoices. NFR9: Similar to cost (NFR8), decen tralization affects the main actors but is not their resp onsibility . Data o wner, issuer, and verifier all ha v e a tertiary resp onsibilit y , as they b enefit from it but are not resp onsible for its fulfillment. The o wnership b elongs to the DI/SSI (global) system. NFR10: The existence means that the data owner’s identit y has an indep enden t existence and do es not rely on other services [9]. This NFR is indirectly fulfilled b y the data owner and facilitates the p erformance of other resp onsibilities, such as accessibility (NFR1), av ailability (NFR4), and con trol (NFR7). Therefore, the data owner has a primary resp onsibility ov er NFR10. Both verifier and issuer should also exist indep enden tly , but do not directly in teract with this NFR. Ownership of NFR10 lies with the data o wner. NFR11: Interoperability is closely related to compatibility (NFR5) and standard (NFR20). Similar to compatibility (NFR5), the issuer is primarily resp onsible for issuing credentials in an in terop erable format, while the verifier has a secondary resp onsibilit y . The data owner has a tertiary resp onsibility since they b enefit from the fulfillment of interoperability by other actors. The ownership of NFR11 b elongs to the issuer. NFR12: Persistence aligns with accessibility (NFR1) and av ailability (NFR4) by ensuring that data is p ersistent and accessible ov er time. Since the data o wner is resp onsible for storing and accessing the data, they are also primarily resp onsible for retaining it for as long as necessary . Ownership of this NFR lies with the data o wner. NFR13: The data owner should b e able to mov e their p ersonal data from one system to another [20]. This makes the data owner b eneficiary of the fulfillment of p ortability , but not resp onsible for its fulfillment. Th us, the data owner has a tertiary resp onsibility , and ownership lies with a wallet (lo cal system). The w allet enables the exp ort and imp ort of identit y data and credentials. Title Suppressed Due to Excessive Length 11 NFR14: Priv acy in the DI/SSI domain refers to data minimization. The data o wner should b e able to select a minimal set of personal data to be shared. This implies that the data o wner is primarily resp onsible for maintaining the priv acy of their data, as they make the decisions ab out sharing the information. Imp ortantly , the verifier also shares primary resp onsibilit y for priv acy , as minimal disclosure w ould not be achiev ed if the v erifier requests more information than necessary . The issuer has a secondary responsibility since they issue a credential that supports selectiv e disclosure. Ownership of NFR14 is shared among the data o wner, verifier, and issuer. NFR15: A ccording to the protection NFR, p ersonal data sh ould b e protected against misuse. Since the data owner is primarily responsible for storing and managing his p ersonal data, protection also falls within his primary resp onsibilit y . This aligns with accessibility (NFR1), av ailability (NFR4), con trol (NFR7), existence (NFR10), and representation (NFR17). The data o wner is responsible for protecting data during storage and transmission. In DI/SSI systems, the verifier typically do es not store p ersonal data in plain text. Thus, the v erifier shares no responsibility for data protection. How ev er, the verifier ma y request more data than the minimum subset, thereby making it primarily resp onsible for data protection. Lastly , the issuer shares some resp onsibilit y for data protection, but not within the DI/SSI system. The issuer holds data ab out the data o wner b efore issuing a credential ( e.g. , a univ ersity has records of a student before issuing a digital certificate attesting to their successful graduation). This do es not fall under the NFR of DI/SSI systems and, as a result, the issuer shares no resp onsibility in NFR15. Ownership of this NFR lies with the data owner and the lo cal system (wallet). NFR16: The data owner has primary resp onsibility for data recov erabilit y , as they store and manage it, aligning with accessibility (NFR1), av ailability (NFR4), con trol (NFR7), existence (NFR10), and protection (NFR15). There are multiple approaches to recov erabilit y dep ending on how the data was lost ( e.g. , compromise, physical loss of a mobile phone). Therefore, there are m ultiple wa ys to fulfill recov erabilit y , some of which dep end on the DI/SSI system capabilities ( e.g. , a wallet provides a backup). Ownership of this NFR is held b y the wallet (lo cal system). NFR17: Representation refers to the data o wner’s abilit y to create m ultiple iden tities for different in teractions [9]. Therefore, the data owner has primary resp onsibilit y for and ownership of NFR17. NFR18: Securit y has m ultiple definitions, and within the DI/SSI domain, it refers to the general principle that data should b e secure at all times. [9] p oints out that the data o wner should hav e confidence in the soft ware and other actors of the system, as well as o verall security asso ciated with data storage and transmission. This implies that security is a service owned by the DI/SSI (global) system rather than by sp ecific actors who use it, while the wallet (lo cal 12 Sc humm and Stiller system) enforces security features to protect data storage. Therefore, the data o wner b enefits from the securit y but do es not alwa ys enforce it or guarantee its fulfillmen t, indicating that the data o wner has tertiary resp onsibilit y . Similar to the data owner p ersp ective and protection (NFR15), the data should remain secure during v erification and credential issuance. How ev er, this security should b e ensured by the inherent softw are design, while the verifier and issuer b enefit from its fulfillmen t. Thus, the verifier and issuer ha ve tertiary resp onsibility . NFR19: The data holder should b e the single authoritative source of their p ersonal identit y data [9]. Th us, the data owner has primary resp onsibilit y for and ownership of this NFR. The verifier and issuer do not share any resp onsibilit y nor b enefit from it. NFR20: The standard closely aligns with compatibilit y (NFR5) and in terop erability (NFR11), explicitly stating that credentials should follow a sp ecific op en standard [9]. The issuer is primarily resp onsible for guaranteeing the fulfillment of this NFR. While adherence to the standards is not explicit to the data holder, they b enefit from the fulfillment of this NFR b ecause it pro vides more flexibility and facilitates interoperability (NFR11), implying tertiary responsibility . The verifier has a secondary resp onsibilit y b ecause they can specify which credential standards they can verify . As a result, the issuer is fulfilling its resp onsibility to adhere to a sp ecified standard. The ownership of this NFR b elongs to the issuer. NFR21: T ransparency in the context of DI/SSI systems refers to the readiness of the information ab out data use [9]. Since the verifier is the only actor who ma y request data from the data holder and use it for authorization, it bears primary resp onsibility for providing transparency to the data owner. Moreov er, [20] p oints out that issuers should also supp ort transparency b y ensuring the creden tial issuance pro cess is auditable and understandable. Similarly , the issuer shares the primary responsibility . The data o wner b enefits from the fulfillment of transparency , thus sharing the tertiary resp onsibility . The o wnership of this NFR is shared b et ween the verifier and issuer. NFR22: Usability ensures that the data o wner can use the system and its functionalit y effectively and intuitiv ely [9]. While a data holder benefits from the system’s usability , they are not resp onsible for its fulfillment, indicating a tertiary resp onsibility . Since the verifier and issuer do not hav e a usability requiremen t, they are not resp onsible for it. Ownership of this NFR is held by the w allet (lo cal system). NFR23: While usability (NFR22) and this NFR are closely related, user exp erience refers to the supp ort of identit y managemen t pro cesses b eing simple, consistent, and user-friendly [9]. Therefore, similarly to usability (NFR22), the data owner b enefits from a go o d user exp erience but is not directly resp onsible, indicating tertiary resp onsibility . Ownership of this NFR is held b y the wallet (lo cal system). Title Suppressed Due to Excessive Length 13 NFR24: The verifier should b e able to indep enden tly v erify creden tials provided b y a data owner, indicating that the verifier is primarily resp onsible for fulfilling this NFR. The issuer pla ys a supp orting role in ensuring that the credential is tec hnically verifiable ( e.g. , it includes the necessary cryptographic elements, such as the issuer’s signature), thereb y assuming a secondary resp onsibility . The data o wner b enefits from the fulfillmen t of the NFR and relies on the verifier to fulfill it, indicating tertiary resp onsibilit y . The ownership of this NFR b elongs to the v erifier and issuer. 5 Discussion & Dep endency Mo del Based on the categorization outlined in previous section, the data o wner is the most frequen t actor with primary resp onsibility , with 11 out of 24 NFR (around 46%) in total, namely accessibility (NFR1), autonom y (NFR3), a v ailability (NFR4), consent (NFR6), control (NFR7), p ersistence (NFR12), priv acy (NFR14), protection (NFR 15), recov erabilit y (NFR16), representation (NFR17), and single source (NFR19). This list of primary resp onsibilities encompasses most of the original SSI principles outlined by [5], with appro ximately 60% of the original principles falling under the data owner’s primary responsibility . This shows the importance and cen tralit y of the data o wner to a DI/SSI system. The issuer is primarily resp onsible for six NFR (25%), namely authen ticity (NFR2), compatibilit y (NFR5), consen t (NFR6), in terop erability (NFR11), standard (NFR20), and transparency (NFR21). This reflects the issuer’s role in generating trusted and verifiable credentials and adhering to standards and legal frameworks. The verifier is primarily resp onsible for five NFR (around 21%), namely consent (NFR6), priv acy (NFR14), protection (NFR15), transparency (NFR21), and verifiabilit y (NFR24). This indicates the verifier’s role in supp orting priv acy and protecting the data owner’s data, as well as ensuring that creden tials can b e verified. Figure 1 illustrates the primary resp onsibilities of each actor within the DI/SSI system. The o wnership of each NFR w as assigned to actors according to whether the actor can pro vide or supp ort the service. F or instance, the issuer is the o wner of the authenticit y (NFR2) b ecause only the issuer can supp ort this service. In other w ords, authenticit y originates from the issuer via cryptographic signatures. F ew NFR, such as cost (NFR8), decentralization (NFR9), p ortability (NFR13), security (NFR18), usability (NFR22), and user exp erience (NFR23), w ere assigned to the system ownership. The system is not an actor or comp onen t exclusive to a DI/SSI system and is present in an y soft ware application. How ever, within the DI/SSI system, primary actors (data o wner, issuer, and verifier) are not the owners of these NFR. F or example, the data owner b enefits from portability but is not the o wner of that NFR b ecause they share no primary responsibility in its fulfillmen t. How ever, the data o wner relies on the system to enforce the functionality , while the system provides p ortabilit y as a service to the data owner. Therefore, these NFR can b e treated 14 Sc humm and Stiller Fig. 1. Primary Resp onsibilities Ov er Non-F unctional Requirements as constraints on DI/SSI systems rather than requirements. A c onstr aint is a requiremen t that “do es not add any capability to a system”, but con trols how capabilities are ac hieved [6]. Building on the results of the NFR assignmen t to actors, a dep endency mo del is dev elop ed. The dep endency mo del, inspired b y the trust model in tro duced in T rop os metho dology [12], represen ts relationships betw een actors and dep endencies within a DI/SSI system. Since DI/SSI systems t ypically op erate in a trustless environmen t, supp orted by a neutral blo c kc hain comp onen t, the original notion of the trust mo del was shifted to a dependency mo del to more accurately reflect the nature of the relationships b etw een actors. Ev en though actors within DI/SSI systems do not require m utual trust, dep endencies on the fulfillment of functional requirements remain, as evident from the discussion in Section 4. P articularly , the dep endency mo del formalizes dep endencies within the system, follo wing the dep ends(A, B, NFR X) pattern, meaning that actor A relies on actor B to fulfill NFR X to achiev e a goal of actor A. The dependency mo del assumes that primary resp onsibility for NFR requires a certain degree of trust from other actors. In other words, actor A must rely on actor B to fulfill NFR X. F or example, in the case of authenticit y (NFR2), the issuer is primarily resp onsible for ensuring the credential is authentic. A t the same time, the data o wner relie s on the issuer to fulfill NFR2 so that they can b enefit from the fulfillmen t (tertiary resp onsibility) and obtain access to a service that requires this credential. The verifier do es not benefit from the fulfillmen t of NFR2, but b y p erforming the verification pro cess, they provide a Title Suppressed Due to Excessive Length 15 Fig. 2. Dep endency Mo del supp orting role (secondary resp onsibility). Therefore, to represent dep endency relationships, (i) the data owner trusts the issuer with credential v alidity , and (ii) the verifier trusts the issuer with an authentic signature on the credential (in this instance, trust is supp orted b y the cryptographic v alidity of a signature). Based on this approac h, the dep endency relationships can be mo deled, as sho wn in Figure 2, where dep endency is represented with D. In this mo del, o wnership represents authority ov er the service or data and is denoted by O. T able 4 provides an example of the dep endency mo del for fiv e NFR. The complete dep endency mo del is av ailable in T able 4 of the App endix 2 . 6 Conclusions and F uture W ork This work addresses the limited integration of the individual user p ersp ective in to the requiremen ts engineering proce ss in the DI/SSI domain. While prior w ork consolidated SSI principles, which comprehensively represen t quality requiremen ts or NFR of a DI/SSI system, they did not explicitly em b ed user roles, resp onsibilities, and dep endencies. Building on existing requirements, this w ork refined and decomp osed SSI principles into 24 atomic NFR and systematically mapped them to DI/SSI design patterns, as w ell as 2 h ttps://github.com/sc hummd/categorization 16 Sc humm and Stiller T able 4. Dep endencies Betw een Actors for Eac h Non-F unctional Requirement Key NFR PR a O b Dep endency P attern NFR1 A ccessibility o o V erifier relies on the data owner to presen t accessible credential data. dep ends( v , o , NFR1) w o The data owner dep ends on the w allet to pro vide access to data. dep ends( o , w , NFR1) NFR2 Authen ticity i i The data owner relies on the v alidity of creden tials. dep ends( o , i , NFR2) i i V erifier relies on a v alid signature of a creden tial. dep ends( v , i , NFR2) NFR3 Autonom y o o – – NFR4 A v ailability o o V erifier dep ends on the data o wner to pro vide creden tials. dep ends( v , o , NFR4) w o The data owner dep ends on the w allet for the data to b e accessible. dep ends( o , w , NFR4) NFR5 Compatibilit y i i V erifier relies on the issuer to issue a credential in a compatible format. dep ends( v , i , NFR5) i i The data owner dep ends on the issuer for a credential to b e usable. dep ends( o , i , NFR5) a Primary Resp onsibility b Ownership Title Suppressed Due to Excessive Length 17 participating users, namely data o wner, issuer, v erifier, and s ystem. The results highligh t the central role of the data owner, who b ears primary resp onsibility for most NFR, thereby supp orting the user-centric foundations of DI/SSI. At the same time, the allocation of responsibilities and o wnership clarified ho w issuers, verifiers, and the system contribute to the fulfillment of securit y , priv acy , in terop erability , and usabilit y ob jectives. F urthermore, the proposed dep endency mo del formalizes relationships among actors by explicitly sp ecifying how actors rely on one another to realize requirements. As a result, the mo del captures functional dep endencies of DI/SSI systems. F uture work will fo cus on identifying the capabilities of each actor in DI/SSI systems, building on the in tro duced dependency mo del. F ollow ed b y systematic op erationalization of NFR, deriv ation of FR, and developmen t of a functional mo del for DI/SSI systems. Additionally , mapping design patterns to NFR rev ealed that not all NFR are addressed b y the patterns. Identifying and describing missing design patterns would enable a more comprehensive and complete o verview of the DI/SSI system architectures. References 1. 700Cr edit Suffers Data Br e ach . 700Credit. https://www.700credit.com/notice/ (accessed Dec. 18, 2025) 2. IDunion – Ermö glicht Selbstb estimmte Identitäten . IDUnion. https://idunion. org/ (accessed Dec 18, 2024) 3. Overview . Sovirn. https://sovrin.org/overview/ (accessed May 16, 2024) 4. Principles Of SSI v3 . Sovrin. https://sovrin.org/principles- of- ssi/ (accessed June 4, 2024) 5. Allen, C.: The Path to Self-Sover eign Identity . https://www.lifewithalacrity. com/article/the- path- to- self- soverereign- identity/ (accessed on Ma y 12, 2024) 6. An toniou, C., Bassiliades, N.: A T o ol for Requirements Engineering Using On tologies and Boilerplates. Automated Softw are Engineering 31 (1), 5 (2024). https://doi.org/https://doi.org/10.1007/s10515- 023- 00403- y 7. Blyth, A.: Using Stakeholders, Domain Knowledge, and Responsibilities to Sp ecify Information Systems’ Requiremen ts. Journal of Organizational Computing and Electronic Commerce 9 (4), 287–296 (1999). https://doi.org/https://doi.org/ 10.1207/s153277440904_3 8. Bresciani, P ., Perini, A., Giorgini, P ., Giunchiglia, F., Mylopoulos, J.: T rop os: An Agen t-Oriented S oft ware Developmen t Metho dology. In: Autonomous Agents and Multi-Agent Systems, vol. 8, pp. 203–236. Springer (2004). https://doi.org/ https://doi.org/10.1023/b:agnt.0000018806.20944.ef 9. Čučk o, Š., Bećirović, Š., Kamišalić, A., Mrdo vić, S., T urk ano vić, M.: T ow ards the Classification of Self-Sov ereign Identit y Prop erties. IEEE Access 10 , 88306–88329 (2022). https://doi.org/https://doi.org/10.1109/access.2022.3199414 10. Čučk o, Š., Keršič, V., T urk anović, M.: T ow ards a Catalogue of Self-Sov ereign Iden tity Design Patterns. Applied Sciences 13 (9), 5395 (2023). https://doi.org/ https://doi.org/10.3390/app13095395 11. F erdous, M.S., Chowdh ury , F., Alassafi, M.O.: In Search of Self-Sov ereign Identit y Lev eraging Blo ck chain T echnology. IEEE Access 7 , 103059–103079 (2019). https: //doi.org/https://doi.org/10.1109/access.2019.2931173 18 Sc humm and Stiller 12. Giorgini, P ., Massacci, F., Mylop oulos, J., Zannone, N.: Filling the Gap Bet ween Requiremen ts Engineering and Public Key/T rust Managemen t Infrastructures. In: Katsik as, S.K., Gritzalis, S., Lóp ez, J. (eds.) Public Key Infrastructure, pp. 98–111. Springer (2004). https://doi.org/https://doi.org/10.1007/ 978- 3- 540- 25980- 0_8 13. Giorgini, P ., Massacci, F., Mylop oulos, J., Zannone, N.: Mo deling Securit y Requiremen ts Through Ownership, Permission and Delegation. In: 13th IEEE In ternational Conference on Requirements Engineering (RE’05). pp. 167–176. IEEE (2005). https://doi.org/https://doi.org/10.1109/re.2005.43 14. Giorgini, P ., Massacci, F., Mylop oulos, J., Zannone, N.: Requirements Engineering Meets T rust Management: Mo del, Metho dology , and Reasoning. International Journal of Information Security 5 , 257–274 (2006). https://doi.org/https: //doi.org/10.1007/s10207- 006- 0005- 7 15. Hamilton-Duffy , K., Grant, R., Gropp er, A.: Use Cases and R e quir ements for De centr alize d Identifier . W3C W orking Group Note. https://www.w3.org/TR/ did- use- cases/ (accessed No v 17, 2025) 16. Hull, E., Jackson, K., Dick, J.: W riting and Reviewing Requirements. In: Requiremen ts Engineering, pp. 93–111. Springer (2017). https://doi.org/https: //doi.org/10.1007/978- 3- 319- 61073- 3_4 17. Liu, Y., Lu, Q., Paik, H.Y., Xu, X.: Design Patterns for Block chain-Based Self-So vereign Identit y . In: Proceedin gs of the Europ ean Conference on Pattern Languages of Programs 2020. pp. 1–14 (2020). https://doi.org/https://doi. org/10.1145/3424771.3424802 18. P etrakos, K.: Mor e than 1.6m Sign Petition Opposing Starmer’s Plan for Digital ID Car ds . The Guardian. https://www.theguardian.com/politics/2025/sep/27/ petition- opposing- starmer- plan- digital- id- cards (accessed Dec. 18, 2025) 19. Six, N., Herbaut, N., Salinesi, C.: Blo ck chain Softw are P atterns for the Design of Decentralized Applications: A Systematic Literature Review. In: Blo ck chain: Researc h and Applications. vol. 3, p. 100061. Elsevier (2022). https://doi.org/ https://doi.org/10.1016/j.bcra.2022.100061 20. Soltani, R., Nguyen, U.T., An, A.: A Survey of Self-So vereign Identit y Ecosystem. Securit y and Comm unication Netw orks 2021 (1), 8873429 (2021). https://doi. org/https://doi.org/10.1155/2021/8873429 21. Sp orn y , M., Longley , D., Chadwic k, D., Steele, O.: V erifiable Cr e dentials Data Mo del v2.0 . W3C, 2024. https://www.w3.org/TR/vc- data- model- 2.0/ (accessed No v 17, 2025) 22. Sp orn y , M., Longley , D., Sabadello, M., Reed, D., Steele, O., Allen, C.: De centr alize d Identifiers (DIDs) v1.0 . W3C Recommendation, 2022. https://www. w3.org/TR/did- core/ (accessed Nov 17, 2025) 23. Stokkink, Q., P ouw else, J.: Deploymen t of a Blo ck chain-Based Self-Sov ereign Iden tity . In: 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE cyb er, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). pp. 1336–1342. IEEE (2018). https://doi.org/https://doi.org/ 10.1109/cybermatics_2018.2018.00230