The technical principles Revisiting SSI meeting was held on May 20. It focused on the five technical principles included in the redlines for the updated SSI principles.

Participants: Christopher Allen (Blockchain Commons), Otto Mora (Ethereum Foundation), Lisa Dusseault (Data Transfer Initiative), Wilmer Daza (My OnePlace), Gerald Glickman (financial-services identity/risk), Paul Fuxjäger (University of Vienna), André Ferreira, Kemal

Media & Slides

Video:
[ transcript ]

Summary is AI generated.

Starting with the Technical Principles

Christopher chose the five technical principles (Persistence, Portability, Interoperability, Minimalization, Transparency) as the meeting’s focus because they are “the most operationalizable”.

He framed two tensions the technical principles must navigate:

  • The “whitewashing” problem. Companies use SSI vocabulary without meeting the substance (“they aren’t really self-sovereign, they just sort of use some of the language”). Technical principles let buyers and regulators draw a line.
  • The “checklist trap.” “An identity system that claims persistence but fragments the person, or portability that doesn’t survive lock-in, or interoperability that collapses into monoculture, and minimalization that excludes inferred data, or transparency of code without transparency of incentives” — all defeat the spirit while passing the operational test.

One real concern with the wider set of principles is that in practice only the operational principles get enforced. The other principles not discussed at this meeting need a mechanism to be enforced into the operational ones or they vanish.

The CSSPS Framework as Operational Backbone

Christopher recommended Charnon Pattiyanon and Toshiaki Aoki’s 2022 IEEE Access paper, “Compliance SSI System Property Set to Laws, Regulations, and Technical Standards,” and especially its supplemental ZIP file containing Consistency Analysis and Property Improvement.xlsx. The paper distills the original SSI principles, other principle variants, and security/privacy frameworks into 42 operational properties.

One observation from Christopher’s reading: a number of items in the CSSPS analysis were classified as “not operational.” Three patterns:

  • Some are systemic — laws, regulations, organizational arrangements — that can become checkboxes if there’s a mechanism that meets the requirement.
  • Some are balancing problems — too much of one principle creates problems in another.
  • Some are fundamentally ethical or human-rights-based and resist operationalization — particularly anything that protects dignity as we move more online.

Otto noted the W3C DID group has parallel discussions where DID method selection becomes the practical operationalization.

Persistence [#1]: From Forever to Contextual

The original principle (“identities should last forever, or at least as long as the user wishes”) came out of a specific 2016 concern: cancellation of identifiers. Christopher’s lived example: being an early Gmail user with one and a half terabytes of email he doesn’t control, all subject to Google’s discretion anchors the persistence requirement in account-loss as a real ongoing harm. He described the “smart friends list” of ex-Apple and ex-Google staff who informally fix four or five account-loss cases a year as back-channel work the rest of the world cannot access.

Otto’s suggestion (already in the redline): the infrastructure itself should not be dependent on a single issuer, vendor, jurisdiction, or consortium. This makes federated and consortium-run registries harder to “SSI-wash” because censorship by collusion becomes a visible failure mode rather than an invisible characteristic.

Wilmer’s reframing: persistence as a homogeneous property doesn’t survive contact with real relationships. Persistence is contextual: the persistence rights of an email used for work, an email used for family, and a social media account are not equivalent. Persistence rules should attach to contexts and the relationships within them, not to data in the abstract. Context-internal data sometimes needs to be automatically deleted (legal retention limits), sometimes user-controlled, sometimes institution-controlled, sometimes multi-party-governed.

André’s chat thread challenged the “forever” framing: even financial records and physical IDs (driver’s licenses) aren’t kept forever. Otto’s interpretation in the chat: “forever” likely applies to the user’s ability to use their chosen identifier, not the credentials themselves. The language in the principle doesn’t make this distinction clearly.

Portability [#2] and Interoperability [#3]: The Case to Merge

Lisa’s discussed The Data Transfer Initiative’s posture, distilled across three points:

  1. Identity is what you’ve contributed. Your photos on Instagram, posts on Mastodon, and knitting projects on Ravelry constitute your identity on those platforms. “Reputational context” doesn’t communicate this stakes for people who don’t already live in data-portability vocabulary.

  2. Companies should not run their own trust verification. Apple deciding who can print your baby photos, Google deciding who can view your calendar, Meta deciding which research projects get your data — these are anti-competitive choices dressed as security. DTI is pushing for a neutral third party to make trustworthiness determinations.

  3. Data access is data access. Separating personal export, data donation, and third-party API access into different channels enables platforms to make each individually unusable while claiming compliance. A single REST-style ask-pattern API with one authorization flow, used by whichever authorized party needs it, is what data portability actually requires.

She illustrated the practice with a 2026 Goodreads export attempt: “I can only petition Amazon to sometime in less than a month send me an export of a thousand books” — reverting to the mean of unusability. Her closing position: “we suggest that interoperability and portability are the same, otherwise it tends to be broken.”

Wilmer added a relational caveat: data isn’t created in isolation. The Instagram photos exist on the user’s phone and on the platform; the relationship between the institution and the user shapes what portability can mean. Building a platform where every kind of data flows in and out in every format is expensive, and the cost falls somewhere. The principle should acknowledge the relational nature.

Christopher tied portability back to his earlier object-capability comment: people violate bank ToS constantly because their family and work lives are intertwined and the banks don’t provide capability-style delegation. Mercury Bank (a US neobank) is one of the few examples doing this well — per-employee cards with scoped visibility, separate CPA access, and a recently added MCP server endpoint. “Will that be sufficient to protect grandma? I don’t know.”

Interoperability [#3]: Pluralistic Trust

Christopher introduced the redline’s framing: “pluralistic interoperability — many coexisting vocabularies, trust frameworks, networks, including the right to remain outside, bridged by open protocols rather than a unified standard.” Grace (DIF’s new executive director) contributed the linked phrasing: “the right of the individual to determine the authorities they believe in.”

Christopher anchored this in the history of TLS certificate authorities. SSL/TLS 1.0 originally let users choose CAs, including high-assurance CAs that physically verified business presence. By 2011-2012, consolidation had reduced the field to a few companies, and then browser vendors took over the trust decision entirely. “CAs became worthless, and it was pretty much up to the browser companies.” The same consolidation pattern is now visible in nation-issued and EUDI-style identity infrastructures.

Otto’s reading of pluralistic interoperability: “we’re going to have roots of trust from nations, roots of trust from private sector, and then we’re going to have these self-sovereign — and I guess human-based pure trust.” Christopher confirmed this as the intent, anchored by his ongoing work in peer-to-peer trust under adversarial circumstances (“I have people in Iran that I hope are using some of the technology I wrote for them a few years back right now”).

Minimalization [#4]: Correlation and Inference

Christopher reframed the original “disclosure should be minimized” principle around correlation resistance: even small voluntary disclosures get inferred into much larger profiles. Cookie blocking and other protections don’t prevent DNS-level fingerprinting and behavioral inference that places a user “no longer in my twenties” within seconds of a private session.

He surfaced a specific institutional failure: an IETF dispatch session (held about a year ago) tried to start standards work on data minimization. The response: “we don’t have companies that are demanding standards around how we do data minimization, so we’re not going to do it.” When Christopher pointed at the RFCs on human rights and privacy, the rejoinder was “those aren’t standards.” The IETF draft (draft-appelcline-hashed-elision) is on the table for Gerald to incorporate into his minimalization edit pass.

Gerald’s interest is policy-facing rather than principle-facing — the collection and storage requirements of the Bank Secrecy Act and customer identification programs are the law, and pointing at usable tools that meet the substance without collecting and storing the PII would change the conversation. He flagged the “circular causal loops of capabilities informing policy” as the structural reason the window has stayed closed.

Lisa’s intervention was the most consequential reframe: the principles are not about making things easy for companies. They are about what policy should promote. It is acceptable if the principle is at odds with current regulation. This shifts the document’s posture from advocacy-via-compatibility to advocacy-via-aspiration.

Transparency [#5]: Beyond Open Source

Christopher introduced his “Open Development” framing: open source is “level zero” — necessary but not sufficient. The further dimensions of transparency he names:

  • Inspectable / observable — you can actually see what’s happening.
  • Reproducible / testable.
  • Cooperative — bugs and feature requests are public, not on a private branch.
  • Shared roadmaps with named listeners.
  • Distributed and/or standardized.

Lisa: “open source and open standards are both good — surprisingly often in tension. Both are just tools for transparency.” She agreed open source has practical limits, including for her own team at DTI, who don’t yet do much beyond level zero.

Lisa’s reframe of the transparency principle: the foundation of transparency is governance. Open standards, open source, a wiki, monthly webinars — these are all forms of transparency, but they require visible governance underneath. Without that, transparency becomes a costume.

Christopher pointed at parallel work: an IIW discussion on pattern languages for governance; his own “A Spectrum of Consent” framework which ranges from pure unanimous consent through consensus-minus-one, plurality, right-to-fork, citizen assembly, distributed authority, executive authority, and dictatorship; and his participatory ecosystem definition.

Key Takeaways

  1. Portability and Interoperability should possibly be merged.
  2. The CSSPS framework (Pattiyanon and Aoki, 2022) is the recommended operationalization layer.
  3. A restructureas short principles, with operational bullets underneath each is on the table.
  4. Principles should not bend to current regulation.
  5. The “SSI-washed” problem cuts both ways.

Action Items

Immediate (this cycle)

  • Otto Mora: confirm with employer (Ethereum Foundation) that he can take an edit pass, then draft revised Persistence principle. Use CSSPS matrix; consider Wilmer’s context-relational framing and André’s challenge to “forever.”
  • Lisa Dusseault: draft revised Portability principle. Test the merge-with-Interoperability hypothesis in the draft; if separation is retained, name the difference precisely.
  • Gerald Glickman: draft revised Minimalization principle. Incorporate the draft-appelcline-hashed-elision IETF draft framing and the financial-services policy angle.
  • Christopher Allen: send the IETF minimalization draft link to Gerald.
  • Christopher Allen: send the governance / Nomic / Spectrum of Consent links around (the polisplay.md gist and the Spectrum of Consent article were shared in chat).
  • Christopher Allen: issue a formal calendar invite for the next community meeting (target: June 17).
  • Open volunteers needed: Interoperability and Transparency drafts. Cast a wider net — surface in next community post and on the Signal/email list, particularly if Sara Garcia can participate.

Near-term (post-drafts)

  • Reconcile drafts at the next community meeting. Test whether the “short principle + operational bullets” restructure works as a uniform pattern or only fits some principles.
  • Decide on the Portability/Interoperability merger based on Lisa’s draft and the group’s response.
  • Identify whether the four-tier structure (foundational / relational / operational / technical) needs a meta-layer to enforce non-operational principles into the operational layer, per Wilmer’s challenge.

Longer-term (Geneva and beyond)

  • Schedule a second cycle of community meetings for the five subjective/social principles (Existence, Control, Access, Consent, Protection).
  • Reach out to Pattiyanon and Aoki re: a possible CSSPS refresh aligned to the revised principles (Otto’s suggestion).
  • Determine GDC Geneva presentation format (presentation of revised draft, panel, or hybrid).

Resources Shared

Next Meeting

Target: June 17, 2026

Format: continue working through the technical principles with the first round of volunteer drafts on the table. Reconcile, decide on structural choices (merge or separate; short-principle-plus-bullets or paragraph form).

Didn’t attend? You can still participate

Here’s how to get involved:

  1. Watch the videos above or skim the transcripts to understand the context.
  2. Browse the lens briefs and find one that resonates.
  3. Join the conversation on GitHub Discussions.
  4. Connect with a working circle via the Signal group or email list.

See How to Join for more.