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

1. Problem Statement

Centralized identity management systems face persistent security and privacy challenges, driving the adoption of Decentralized Identity (DI) and Self-Sovereign Identity (SSI). While existing research has consolidated SSI principles (e.g., existence, control, persistence) and derived quality requirements, a critical gap remains: the lack of an explicit user perspective in requirements engineering.

Previous works (e.g., [9]) have classified requirements into categories like security and privacy but fail to map these requirements to specific user roles (actors) or define who is responsible for fulfilling them. Furthermore, there is no explicit mapping between established DI/SSI design patterns and the quality requirements they are intended to address. This ambiguity hinders the development of structured, user-centric system architectures.

2. Methodology

The authors propose a systematic, three-step methodology to embed the user viewpoint into the requirements engineering process for DI/SSI systems:

1. Decomposition of Composite Requirements:
   • Building on existing SSI principles and prior work [9], the authors decomposed composite requirements into 24 atomic Non-Functional Requirements (NFRs) (e.g., breaking "Control" into specific access management tasks). These are listed in Table 1 of the paper.
2. Actor Definition and Role Mapping:
   • The study defines four key actors based on W3C standards and design patterns:
     • Data Owner (o): The individual holding and managing their identity data.
     • Issuer (i): The entity creating and signing credentials.
     • Verifier (v): The entity requesting and validating credentials.
     • System (s/w): Divided into the Global System (blockchain/ledger) and Local System (Wallet).
   • The authors analyze design patterns from literature [10, 17] to identify the goals, interests, and involvement of these actors.
3. Categorization via Responsibility and Ownership:
   • Each of the 24 NFRs was mapped to actors based on two dimensions:
     • Responsibility: Classified as Primary (direct fulfillment), Secondary (supporting/facilitating), or Tertiary (indirect benefit/reliance).
     • Ownership: Determining which actor has exclusive authority over the service, goal, or resource associated with the NFR.
   • A Dependency Model was introduced to formalize the relationships where Actor A relies on Actor B to fulfill a specific NFR to achieve a goal.

3. Key Contributions

The paper makes three primary contributions to the field of DI/SSI:

1. Refined User-Centered Requirements: A set of 24 atomic NFRs that consistently reflect a user-based viewpoint, moving beyond abstract principles to actionable quality attributes.
2. Actor-Oriented Responsibility Allocation: A comprehensive mapping (Table 3) specifying exactly which actor (Data Owner, Issuer, Verifier, or System) holds primary responsibility and ownership for each requirement.
3. Dependency Modeling: The introduction of a formal dependency model (inspired by the Tropos trust model) that explicitly describes how actors rely on one another for requirement fulfillment in a trustless environment.

4. Key Results and Findings

A. Distribution of Responsibility

The analysis reveals a distinct hierarchy of responsibility, confirming the centrality of the Data Owner:

• Data Owner (Primary Responsibility): Holds primary responsibility for 11 out of 24 NFRs (46%), including Accessibility, Autonomy, Availability, Consent, Control, Persistence, Privacy, Protection, Recoverability, Representation, and Single Source. This aligns with the core SSI principle that the user must control their identity.
• Issuer (Primary Responsibility): Responsible for 6 NFRs (25%), primarily related to the creation of trusted data: Authenticity, Compatibility, Consent, Interoperability, Standard, and Transparency.
• Verifier (Primary Responsibility): Responsible for 5 NFRs (~21%), focusing on validation and data handling: Consent, Privacy, Protection, Transparency, and Verifiability.
• System (Ownership): Global and Local systems own requirements related to infrastructure and user interface, such as Cost, Decentralization, Security, Usability, and User Experience. These are treated as system constraints rather than actor-specific duties.

B. Gaps in Design Patterns

The mapping of NFRs to existing design patterns (from [10] and [17]) revealed significant gaps. While patterns support requirements like Authenticity and Availability, they currently lack explicit support for:

• Autonomy
• Compatibility
• Consent
• Existence
• Persistence
• User Experience

C. The Dependency Model

The authors formalized relationships using the pattern depends(A, B, NFR X).

• Example: For Authenticity (NFR2), the Data Owner depends on the Issuer (depends(o, i, NFR2)), and the Verifier depends on the Issuer for a valid signature (depends(v, i, NFR2)).
• This model clarifies that even in a "trustless" blockchain environment, functional dependencies exist where actors must rely on the successful fulfillment of responsibilities by others to achieve their goals.

5. Significance

This work provides the first structured model for DI/SSI system architectures that integrates user-centered requirements with actor-specific responsibilities. Its significance lies in:

• Clarifying Accountability: By explicitly assigning ownership and responsibility, the model helps architects and developers understand who is accountable for specific security and privacy outcomes, reducing ambiguity in system design.
• Bridging Theory and Practice: It connects high-level SSI principles with concrete design patterns and operational requirements, offering a roadmap for building compliant and robust systems.
• Foundation for Future Engineering: The dependency model serves as a basis for deriving Functional Requirements (FRs) and developing operational models for DI/SSI systems. It highlights that while the Data Owner is the central figure, the ecosystem's success relies on a complex web of dependencies between issuers, verifiers, and the underlying system infrastructure.

In conclusion, the paper argues that for DI/SSI to mature, requirements engineering must shift from abstract principles to a granular, actor-oriented approach that clearly delineates who does what, who owns the data, and who relies on whom.