---
title: Revisiting §3 - Operationalizing SSI - From Principles to Properties
robots: noindex, nofollow
---

DRAFT!!!

# Operationalizing SSI - From Principles to Properties
- Revisiting the Ten Principles of Self-Sovereign Identity (part two)

*— Article 3 in the "Revisiting the Ten Principles of Self-Sovereign Identity" Series (2025)*
(see [Overview](https://hackmd.io/oUIM9j8TTa-wvhBvvO5vZA))

## I. Introduction: Why Operationalize SSI?

- **From ideals to infrastructure**
The 10 Self-Sovereign Identity (SSI) principles defined a philosophical direction: one rooted in autonomy, consent, and user dignity. But a decade later, questions persist: *How do we measure compliance? How do we enforce these values in real systems?*

- **The CSSPS as a compliance backbone**
The Compliance SSI System Property Set (CSSPS), proposed by Pattiyanon & Aoki in [IEEE Access (2022)](https://ieeexplore.ieee.org/document/9875265), aims to fill this gap by defining **42 system-level properties**, each with specific constraint expressions, enabling technical assessment and comparison.

- **Why this matters:**
- Gives **regulators**, **engineers**, and **auditors** a common language.
- Allows for **SSI certification schemes** and **interoperability assessments**.
- Strengthens the SSI movement’s credibility by aligning with privacy law, cybersecurity standards, and operational best practices.

> “An SSI system must enable individuals to encode their personal characteristics... and must associate individual users’ identities with their unique identifiers.”
> — *CSSPS, IP1: Existence* ([PDF](https://ieeexplore.ieee.org/document/9875265))

## II. What Is the CSSPS?

- **Authored by:** Charnon Pattiyanon and Toshiaki Aoki
- **Published in:** IEEE Access, 2022
- **Purpose:** Establish a standards-based framework for testing whether SSI systems comply with legal norms and technical safeguards.

- **What it includes:**
- 42 properties (IP1–IP42), grouped thematically.
- Emphasis on user rights, cryptographic verification, environmental sustainability, and governance.
- Concrete constraint expressions (e.g. must, should) designed for implementation and audit.

- **Why important:**
Where the 10 principles articulate *why* SSI matters, CSSPS begins to answer *how we know when it’s real.*

## III. Where CSSPS Enhances the Original 10 Principles

### 1. **Existence → Clarified and Contested**
- **Original framing:** Existence is intrinsic — every person has the right to a digital identity.
- **CSSPS IP1:**
> “An SSI system must make identities open and accessible to the public.”
- **Why important:**
This exposes a tension. Making identities “open” may violate privacy, especially for vulnerable groups. The principle must affirm **existence without exposure**.

- **Reframed version:**
> “Existence means that one’s digital self is acknowledged and protected — not contingent on being public, encoded, or externally recognized.”

### 2. **Control → Technically Enforced**
- **CSSPS IP2 (Sovereignty):**
> “An SSI system must prevent other individuals, organizations, or governments from controlling the identities of users.”
- **Why important:**
Goes beyond permission to enforce **exclusive authority**, aligning with agency law. Strengthens the legal footing for **Principal Authority** ([link](https://www.blockchaincommons.com/articles/Principal-Authority/)).

### 3. **Consent → Made Verifiable**
- **CSSPS IP16:**
> “An SSI system must enable the deliberate and well-understood presentation of consent... and allow users to revoke their consent.”
- **Why important:**
This introduces **procedural consent** — the need for transparency, informed choice, and reversibility. Aligns with GDPR and avoids “checkbox sovereignty.”

### 4. **Access → Augmented with Rights of Review and Challenge**
- **CSSPS IP11 & IP42:**
> “An SSI system must provide users unrestricted access to their identities...”
> “...must provide users with reasons for denials of their requests and the right to challenge such denials.”
- **Why important:**
Transforms “access” into an enforceable **data subject right**, backed by dispute resolution and rectification. Moves from *read-only access* to *right to know, edit, and contest.*

### 5. **Minimization → Codified as Cryptographic Practice**
- **CSSPS IP17:**
> “In order to share identities, an SSI system must employ selective disclosure, range proof, and other zero-knowledge techniques.”
- **Why important:**
No longer just a privacy ethic — becomes a cryptographic requirement. Encourages privacy-by-design and avoids overcollection defaults.

### 6. **New Properties to Integrate into Next-Gen Principles**

#### 🧾 **Principle 11: Auditability & Non-Repudiation**
- **CSSPS IP27–28:**
> “An SSI system must maintain sufficient log information... and include a mechanism to provide irrefutable evidence.”
- **Why important:**
Establishes **accountability** in both directions — for issuers and users. Supports legal claims, forensic review, and governance transparency.

#### 🌍 **Principle 12: Interjurisdictional Resilience**
- **CSSPS IP23:**
> “An SSI system should be accessible to all, regardless of their ethnic origin, gender, socioeconomic status, or language.”
- **Why important:**
Promotes **universal design** — ensuring SSI doesn’t become a luxury or national silo. Supports cross-border rights and inclusion.

## IV. Where CSSPS Falls Short

### 🧠 No Cognitive or UX Protections
- No mention of:
- **Dark patterns**
- **Manipulative consent flows**
- **Behavioral design ethics**

→ Misses the modern risks of **digital coercion**, which will be addressed in the [Anti-Coercive Design](#) and [Cognitive Liberty](#) articles in this series.

### ⚖️ Ignores Power and Discrimination
- No systemic analysis of:
- **Disparate impact**
- **Schema bias**
- **Verifiable exclusion**

→ Suggest a future principle:
> “SSI systems must be assessed for structural bias, ensuring identity tools do not encode historical inequality or systemic exclusion.”

## V. Toward a Hybrid SSI Model

| Layer | Role | What It Provides |
|-------|------|------------------|
| **Principles** | Ethical Compass | Autonomy, equity, dignity, mental sovereignty |
| **Properties (CSSPS)** | Implementation Guide | Auditability, technical safeguards, legal compliance |

- **Why this matters:**
Bridging principle and property allows SSI to remain values-driven **while scaling into real-world deployments** — across wallets, issuers, and verifiers.

## VI. Reclaiming Principle 1: Existence

- **Why it matters most:**
Existence underpins all rights. Without it, one has no standing in a digital world. But if misinterpreted, it can also justify surveillance or over-identification.

- **Problem with CSSPS IP1:**
Treats existence as *technical visibility*, not legal or social personhood.

- **Revised version:**
> “Digital existence must be protected by default, not exposed by design. Systems must support pseudonymity, non-disclosure, and self-erasure — affirming identity without demanding visibility.”

## VII. Conclusion

- **CSSPS offers precision and power** — but must be guided by ethical vision.
- **Systems thinking is necessary** — but not sufficient.
- **SSI must remain people-centered** — resisting the reduction of identity to data, code, or compliance alone.

> _“The measure of a good SSI system isn’t just how compliant it is — but how well it respects and protects the people it serves.”_

## VIII. Appendix: CSSPS Summary Table — Mapping System Properties to SSI Principles

| CSSPS Property | Description | Aligns With Principle |
|----------------|-------------|------------------------|
| **IP1** | Existence via public encoding and biometric correlation | **Principle 1 (Revised)** — Existence must not require exposure |
| **IP2** | User sovereignty over identity, credentials, agents | **Principle 2** — Control |
| **IP3** | Users as primary source of identity and claims | **Principle 2** & **10** — Control + Protection |
| **IP4** | Use of open standards for identity data | **Principle 8** — Interoperability |
| **IP5** | Cost-free or low-cost access to identity systems | **Candidate** — Future equity principle |
| **IP6** | Avoid centralized control or registration | **Principle 2** & **6** — Control + Transparency |
| **IP7** | Cryptographic verification of credentials | **Principle 10** — Protection |
| **IP8** | Identity scalability, decomposition, and granularity | **Candidate** — Interoperability, Identity layering |
| **IP9** | Simplicity and accessibility of use | **Candidate** — Accessibility, Usability |
| **IP10** | Environmental, technical, economic sustainability | **Candidate** — Long-term viability principle |
| **IP11** | Access control: update, hide, delete identities | **Principle 5** — Access |
| **IP12** | Transparency of systems, algorithms, and proofs | **Principle 6** — Transparency |
| **IP13** | Persistence with erasure and revocation safeguards | **Principle 3** — Persistence (revised) |
| **IP14** | Portability of identities, wallets, and services | **Principle 7** — Portability |
| **IP15** | Interoperability with legacy and other systems | **Principle 8** — Interoperability |
| **IP16** | Consent: specific, revocable, and contextual | **Principle 4** — Consent |
| **IP17** | Data minimization using ZKPs and selective disclosure | **Principle 9** — Minimization |
| **IP18** | Protection of user rights during conflict | **Principle 10** — Protection |
| **IP19** | Force-resistant identity authentication | **Candidate** — Security & Sovereignty |
| **IP20** | Physical authentication of hardware/devices | **Candidate** — Security-by-design |
| **IP21** | Use of strong cryptography for confidentiality | **Principle 10** — Protection |
| **IP22** | Identity recovery from loss (wallet, keys, etc.) | **Principle 7 (Extended)** — Portability & Continuity |
| **IP23** | Availability of identity across platforms and demographics | **Proposed Principle 12** — Equity & Resilience |
| **IP24** | Secure communication protocols for ID data | **Principle 10** — Protection |
| **IP25** | Data integrity via digital signatures and hash functions | **Principle 10** — Protection |
| **IP26** | Role-based data authorization and access control | **Principle 5** — Access |
| **IP27** | System activity logs and compliance audits | **Proposed Principle 11** — Auditability |
| **IP28** | Non-repudiation mechanisms for obligations | **Proposed Principle 11** — Accountability |
| **IP29** | Validation and sanitization of identity data | **Candidate** — Accuracy, Clean Data Practices |
| **IP30** | Robust error handling and data corruption defense | **Candidate** — Resilience, Security |
| **IP31** | Key management and secure key sharing | **Principle 10** — Protection |
| **IP32** | Malware protection on identity-processing systems | **Principle 10** — Protection |
| **IP33** | Password security and user controls | **Candidate** — Credential hygiene & resilience |
| **IP34** | Secure system configuration and file handling | **Candidate** — Deployment integrity |
| **IP35** | Session management and inactivity safeguards | **Candidate** — Privacy & Session Control |
| **IP36** | Classification of data by security level | **Candidate** — Governance & Tiered Risk |
| **IP37** | Fair and lawful identity processing | **Principle 4** — Consent; also supports **Principle 12** — Equity |
| **IP38** | Purpose specification and limits on use | **Principle 9** — Minimization (expanded) |
| **IP39** | Use and disclosure limitations, with audit trails | **Principle 6** — Transparency & Accountability |
| **IP40** | Data quality, completeness, and correction rights | **Principle 5** — Access |
| **IP41** | User notification of data use and breaches | **Principle 6** — Transparency |
| **IP42** | Individual participation, challenge, and redress | **Principle 5** — Access + **Proposed Principle 13** — Due Process & Rights Assertion |

### Observations:

- At least **30+ properties directly align** with some of the original 10 principles, offering technical depth and measurable benchmarks.
- Several **gap areas** (UX coercion, cognitive rights, equity audits) remain **unaddressed**, supporting the case for your upcoming pieces on:
- *Anti-Coercive Design*
- *Cognitive Liberty*
- *Existence 2.0*
- *Principal Authority*

- CSSPS offers a **robust compliance substrate**, but must be **paired with ethical foresight** to ensure sovereignty is truly realized in practice.