Functional Requirements for Decentralized and Self-Sovereign Identities
This paper addresses the lack of reproducible evaluation methods for Decentralized and Self-Sovereign Identity systems by deriving a comprehensive set of functional requirements through a systematic operationalization methodology, thereby establishing a foundational step for future system development and assessment.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
The Problem: The "Digital Landlord" vs. The "Homeowner"
Imagine your digital identity (your name, age, address, driver's license) is like your house.
In the current system, you don't actually own the house. You live in a massive apartment complex managed by a single "Digital Landlord" (like a big tech company or a government database).
- The Risk: If the Landlord's building catches fire (a data breach like Optus or Ticketmaster), your house burns down too. You have no control over who enters your room or what they take.
- The Solution (DI/SSI): Decentralized Identity (DI) and Self-Sovereign Identity (SSI) are like building your own independent home. You hold the keys. You decide who comes in, and you can lock the door if you want. No single landlord controls the whole neighborhood.
The Problem: "It Sounds Good, But How Do We Measure It?"
The authors of this paper point out a major issue: Everyone agrees that "owning your own digital house" sounds great for privacy and security. But, nobody has a clear rulebook to check if a new system actually works that way.
Currently, people evaluate these systems using vague terms like "It feels secure" or "It seems private." It's like trying to buy a car by saying, "I want a fast car," without ever checking the engine speed or fuel efficiency. You might get a slow car that feels fast because of the paint job.
The paper asks: "How do we turn vague promises of 'privacy' and 'control' into concrete, testable rules?"
The Solution: The "Recipe Book" for Digital Identity
The authors created a Functional Requirement (FR) framework. Think of this as a strict recipe book or a blueprint for building a Self-Sovereign Identity system.
Instead of saying "The system must be private," the recipe says:
- The User must be able to click a button to say "Yes" before sharing data.
- The System must show the user exactly what data is being shared.
- The System must allow the user to take their data back and move it to a different app.
How They Built the Recipe (The 4-Step Method)
The authors used a four-step process to turn big ideas into small, testable rules:
Identify the Players (Capabilities):
They listed who is involved in the system:- The Owner (You): You hold the data.
- The Issuer (The School/Doctor): They give you the ID.
- The Verifier (The Store/Police): They check your ID.
- Analogy: They figured out exactly what tools each player needs in their toolbox.
Draw the Map (Functional Model):
They drew a map showing how these players talk to each other.- Analogy: It's like a flowchart showing how a letter moves from your hand to the post office, to the recipient, and back. They mapped out every step: "You ask for a credential," "The Issuer signs it," "You store it," "You show it to the Verifier."
Write the Logic (Predicates & Axioms):
They used math-like logic to make sure the rules make sense.- Analogy: This is like the "If/Then" rules in a video game.
- Rule: IF the User has the data AND the User clicks "Share," THEN the Verifier can see it.
- Rule: IF the User says "Stop," THEN the Verifier cannot see it anymore.
Write the Rules (Functional Requirements):
Finally, they wrote the specific rules that a computer system must follow to pass the test.- Example: Instead of saying "Be private," the rule is: "The system must ask the user for permission before sending data to the Verifier."
A Real-World Example: The "Consent" Cookie
The paper uses Consent (asking for permission) as a prime example.
- Old Way: A website just says, "We use cookies," and you have to click "Accept" or leave. You don't know what they do with your data.
- The New Rule (from the paper): The system must:
- Tell you exactly who will see your data.
- Ask you clearly (in simple language, not legal jargon).
- Let you say "Yes" or "No" for each specific piece of data.
- Let you change your mind later and say "Take it back."
Why This Matters
This paper is the first step toward a "Consumer Reports" for digital identity.
- Before: We had to trust companies when they said, "We are secure."
- After: We can look at their "Recipe Book" (the Functional Requirements) and check: "Did they include the rule about letting the user withdraw consent? Did they include the rule about not relying on a central server?"
If a system follows these rules, we know it truly respects your privacy. If it doesn't, we know it's just a fake "decentralized" system.
The Bottom Line
The authors have built a checklist to ensure that new digital identity systems aren't just marketing hype. They turned the dream of "owning your own digital self" into a set of strict, testable instructions that engineers can follow and regulators can enforce. It's the foundation for a future where you, not a corporation, hold the keys to your digital life.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.