Re: Utah State-Endorsed Digital Identity (SEDI) legislation

Steffen,

>  3) there`s no centralized but distributed system as we have > 250 QTSP,
31 TL, n CAB

It is a distributed system, but it does not have any
authority-decentralization properties.

There is no active consensus; you simply have separate nodes operating
under different governance regimes.

The only thing that connects them is the List of Lists.

If you want to use the term “ Multiple independent nodes can exchange state
and converge toward a consistent view without requiring a single
always-online coordinator. ”


Another thing to consider is that a distributed system can also be
centralized. A database is often a distributed system.

If you want to use the word “decentralized,” it should at least satisfy the
invariant:
“ No single authority can unilaterally prevent a compliant participant from
joining, operating, or exiting the system.”

Others can refine both invariants; I am not claiming neither as the
official saturated meaning, but as required definitions for this
conversation to be useful.

What makes a decentralized distributed system so good for hosting the
verification material, and why we want it is:

Real individuals legal safety depends on it.

The durability guarantee of the hosted material is massive when there is
multiple replicas actively syncing state.

Anyone can join and contribute to the integrity of the network.

These properties are not currently met in the legislation, and are a treat
to individuals legal safety.


You can see the sources, including legislation references,  directly from
here  :
https://chatgpt.com/share/6992b9de-3130-8009-b068-fd5200440e29

Or without legislation links below:

Chat GPT 5.2 Thinking Extended + WebSearch

Prompt 1:

  EUDI, EIDA, find technical details regarding this claim: Joe, Trusted
issuer registry show somebody is allowed to issue something and trustworthy
because in the registry Controls on trusted issuer work in parallel e.g. -
requirements to inform about security breaches within 24 hours Possibility
for SB to start investigation or new conformity assessment by CAB
Conformity assessment based on provable international standards Clear
liability for QTSP 2) Means nothing dangerous in arguments of Nikos, its
pretty much similar to root stores from browsers but in hands of
trustworthy authorities 3) theres no centralized but distributed system as
we have > 250 QTSP, 31 TL, n CAB So recommend that we discuss alongside the
actual regulation and eiDAS technical framework. Best Steffen *Are the 250
trust service providers, is it a conflict-free replicated network making
sure the state is not corrupted or centralized node per governance area  *

Response 1:

Steffen’s bullets are describing a *federated PKI/governance system*, not a
“conflict-free replicated” (CRDT-style) network.
What the “250 QTSP / 31 TL / n CAB” setup actually is

*1) The trust “backbone” is the Trusted Lists + LOTL, not the QTSPs
gossiping state.*
Under eIDAS, each country has a *Trusted List Scheme Operator* that
publishes a *national Trusted List* (TL) of the qualified
providers/services for that jurisdiction. Then the European Commission
publishes the *EU List Of Trusted Lists (LOTL)* that points to those
national lists (and helps authenticate them). ETSI’s Trusted List spec
explicitly describes this “central list of links” model and that national
lists are *electronically signed* and verified via material referenced from
the LOTL.

You can see this operationally in the Commission’s DSS “Trusted Lists
Summary” page: it fetches *EU LOTL* and then shows the *country trusted
lists loaded* with a “№ TSP” count per country.

*2) “Distributed” here means “many independent providers,” not “distributed
consensus.”*
The fact that there are ~250-ish Qualified Trust Service Providers (QTSPs)
(the exact count fluctuates) just means many entities provide services
under the same legal framework. A snapshot example: one industry source
counted *247 QTSPs* (EU/EEA) as of Oct 2024, i.e., “on the order of ~250.”
That’s market distribution. It is *not* a replicated-state protocol where
QTSPs keep each other honest cryptographically.
What the control mechanisms really are (the “parallel controls” Steffen
mentions)

*A) Mandatory third-party audits (CAB) on a schedule*
The consolidated eIDAS text says QTSPs must be audited at least *every 24
months* by a *conformity assessment body (CAB)*, and the resulting report
must be sent to the supervisory body *within 3 working days*.

*B) Supervisory bodies can investigate / trigger extra audits*
The regulation also gives supervisory bodies authority to *audit* a
provider or request a CAB audit outside the regular cycle.

*C) Standards-based conformity assessment*
The audit is explicitly tied to regulatory requirements and (in the amended
text) references requirements aligned with cybersecurity obligations (e.g.,
linkage to NIS2 provisions in the consolidated text excerpted by EUR-Lex).
In practice, the TL technical format itself is standardized through ETSI TS
119 612 + EU implementing acts (e.g., Implementing Decision 2015/1505 for
TL technical specs).

*D) Liability has teeth (especially for “qualified”)*
Article 13 sets a liability regime where trust service providers are liable
for damage caused intentionally or negligently; and for *qualified*
providers, the burden shifts: they must prove they were *not* negligent.
So… is this a CRDT / “conflict-free replicated network” preventing
centralization?

No. It’s almost the opposite shape.

A *CRDT network* (or any replicated-consensus system) tries to make the *state
itself* converge correctly even if some nodes are faulty/malicious—by
protocol design.

eIDAS trust services don’t do that. They do this instead:

   -

   *Authoritative publication* of trust state (who is qualified) via *national
   trusted lists*, plus an EU *LOTL pointer list*.
   -

   *Cryptographic authenticity* of those lists (they are signed; software
   verifies signatures and consumes the XML).
   -

   *Governance + audits + liability* to deter and remediate bad behavior.

That means the trust model is *federated-but-still-centralized per
governance area*:

   -

   Each Member State’s TL scheme operator / supervisory body is effectively
   a *root authority for “who is qualified here.”*
   -

   The EU LOTL is a *meta-root* (a signed directory of those roots).

If a national authority makes a bad inclusion decision, there is *no
byzantine, multi-party consensus layer* among the 250 QTSPs that overrides
it. The remedy is governance (investigations, de-qualification, liability),
not protocol convergence.
“Similar to browser root stores” — yes, with one crucial difference

The analogy is fair in the sense that both are *curated trust-anchor sets*
consumed by relying-party software.

The key difference is: under eIDAS the trusted-list entry is bound
into a *legal
status + supervision + liability* regime, whereas browser root stores are
mostly policy/contractual ecosystems (with transparency and audits, but not
the same statutory construct). The “cryptographic” part is still basically
“verify signatures/cert chains using trust anchors,” not “replicate state
across many issuers.”
How this maps to EUDI “Trusted Issuer Registries”

The European Digital Identity Wallet Architecture & Reference Framework
(ARF) uses similar machinery: *registries* maintained by Member States
(e.g., registrars) that are *publicly available* and can be *machine
readable*, so wallets/verifiers can check “is this provider authorized to
issue X?”
Again: that’s directory-based authorization + governance, not CRDT
replication.
------------------------------

If you want to push back on Steffen’s “distributed so not centralized”
framing in a technically precise way: the clean line is that eIDAS is
*federated
directory + signed metadata + regulated providers*, not a *multi-writer
replicated state machine*. The decentralization is in *service provision*,
not in *state formation*.
---------

Prompt 2:

Help me get only and only the grammar right here, you can suggest
alternative invariants for the two concepts at the end of your message: It
is a distributed system, but not with any authority decentralization
properties. There is no active consensus even, you just have separate nodes
running on different governance regimes. The only thing that brings them
together is the List of Lists If you want to use the word distributed
system fill at least the invariant of: "active opportunistic communication
to merge updates" Others can extend on that invariant I'm not claiming it
as official. Another thing to consider is that a distributed system can
also be centralized. A single database is often a distributed system. If
you want to use the word decentralized fill at least the invariant of: "I
can sovereinly join and leave the network without consecounses as long as I
fufill certain requirements, if requirements are not fullfilled I get
ignored"

Response 2:

It is a distributed system, but it does not have any
authority-decentralization properties.

There is no active consensus; you simply have separate nodes operating
under different governance regimes.

The only thing that connects them is the List of Lists.

If you want to use the term “distributed system,” it should at least
satisfy the invariant:
“active, opportunistic communication to merge updates.”

Others can refine that invariant; I am not claiming it as official.

Another thing to consider is that a distributed system can also be
centralized. A single database is often distributed.

If you want to use the word “decentralized,” it should at least satisfy the
invariant:
“I can sovereignly join and leave the network without consequences as long
as I fulfill certain requirements; if the requirements are not fulfilled, I
am ignored.”
------------------------------

*Alternative invariant formulations (optional refinements):*

   -

   *Distributed system invariant:* “Multiple independent nodes can exchange
   state and converge toward a consistent view without requiring a single
   always-online coordinator.”
   -

   *Decentralized system invariant:* “No single authority can unilaterally
   prevent a compliant participant from joining, operating, or exiting the
   system.”



Regards,
Jori

ma 16.2.2026 klo 7.53 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:

> > Perhaps the productive path forward is:
>
> How do we co-evolve:
>
> • Technical architecture
>
> • Governance frameworks
>
> • Legal enforceability
>
> • Usability at population scale
>
> rather than treating sequencing as a blocker?
>
>
> It is exactly that!
>
> The bottleneck is not the technologists here so: presentation formats that
> involve legal text seem absolutely nessecary to get past the bottleneck at
> this point.
>
> Good takes tho Amir!
>
> Regards,
>
> Jori
>
>
>
> ma 16.2.2026 klo 7.44 ap. Amir Hameed <amsaalegal@gmail.com> kirjoitti:
>
>> Hi Jori,
>>
>> I think we’re largely aligned, and I’ve held a similar position
>> throughout.
>>
>> Legal formalization is clearly necessary for legal trust — that’s an
>> invariant in any system interacting with regulation, liability, and
>> institutional acceptance.
>>
>> Where I hesitate is the inverse argument:
>>
>> that a method is “non-viable” simply because it is not yet legally
>> formalized.
>>
>> Legal frameworks evolve. Architectures shouldn’t be dismissed solely
>> because formal recognition trails implementation — especially when those
>> same methods can be formalized once maturity, interoperability, and
>> assurance models stabilize.
>>
>> From a technical standpoint, there seems to be broad consensus:
>>
>> • Cryptographic verifiability
>>
>> • Privacy preservation
>>
>> • Lifecycle & revocation models
>>
>> • Interoperability
>>
>> • Security guarantees
>>
>> The friction appears when non-technical constructs risk being elevated
>> into hard technical requirements.
>>
>> Speaking from experience working in India — an environment with billions
>> of internet users, heterogeneous devices, intermittent connectivity, and
>> real inclusion constraints — identity engineering is less theoretical and
>> far more operational.
>>
>> We’re building and deploying systems under:
>>
>> • Scale pressures
>>
>> • Infrastructure variability
>>
>> • Usability constraints
>>
>> • Security and fraud realities
>>
>> In these “real trenches,” SSI-style models are not abstract ideals; they
>> are practical tools for improving resilience, reducing central points of
>> failure, and enabling privacy-preserving verification.
>>
>> Legal recognition is essential — but so is allowing technical progress to
>> inform what ultimately gets formalized.
>>
>> Perhaps the productive path forward is:
>>
>> How do we co-evolve:
>>
>> • Technical architecture
>>
>> • Governance frameworks
>>
>> • Legal enforceability
>>
>> • Usability at population scale
>>
>> rather than treating sequencing as a blocker?
>>
>>
>> Best regards,
>>
>> Amir Hameed Mir
>>
>>
>> On Mon, 16 Feb 2026 at 11:06 AM, Jori Lehtinen <lehtinenjori03@gmail.com>
>> wrote:
>>
>>> I also agree and have agreed all the time.
>>>
>>> The legal formalization is an obvious requirement for legal trust.
>>>
>>> An invariant!
>>>
>>> It is not helpful to say methods do not work because they are not
>>> legally formalized.
>>>
>>> When they can be legally formalized any time….
>>>
>>> Everyone already agrees about the technical requirements.
>>>
>>> We have been disagreeng about including parts that include no technical
>>> basis as requirements…
>>>
>>> I will now focus on formalizing what I think will yield the maximal:
>>>
>>> • Deployment speed
>>>
>>> • Governance design
>>>
>>> • Privacy guarantees
>>>
>>> • Recovery & lifecycle management
>>>
>>> • Real-world adoption
>>>
>>>
>>>
>>> ma 16.2.2026 klo 7.21 ap. Steffen Schwalm <Steffen.Schwalm@msg.group>
>>> kirjoitti:
>>>
>>>> "So perhaps the question is not SSI vs government systems, but:
>>>> How do we accelerate implementation while aligning decentralization,
>>>> usability, and regulatory trust?
>>>>
>>>> The meaningful debate is about:
>>>>
>>>> • Deployment speed
>>>>
>>>> • Governance design
>>>>
>>>> • Privacy guarantees
>>>>
>>>> • Recovery & lifecycle management
>>>>
>>>> • Real-world adoption
>>>>
>>>>
>>>> Trust, ultimately, is something we build into the system’s mechanics —
>>>> not something we merely assert."
>>>>
>>>>    - Exactly
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *Von:* Amir Hameed <amsaalegal@gmail.com>
>>>> *Gesendet:* Montag, 16. Februar 2026 06:08
>>>> *Bis:* Steffen Schwalm <Steffen.Schwalm@msg.group>
>>>> *Cc:* Joe Andrieu <joe@legreq.com>; NIKOLAOS FOTIOY <fotiou@aueb.gr>;
>>>> Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <
>>>> agropper@healthurl.com>; Manu Sporny <msporny@digitalbazaar.com>;
>>>> Filip Kolarik <filip26@gmail.com>; public-credentials <
>>>> public-credentials@w3.org>
>>>>
>>>> *Betreff:* Re: Utah State-Endorsed Digital Identity (SEDI) legislation
>>>>
>>>> *Caution:* This email originated from outside of the organization.
>>>> Despite an upstream security check of attachments and links by Microsoft
>>>> Defender for Office, a residual risk always remains. Only open attachments
>>>> and links from known and trusted senders.
>>>>
>>>> Hi all,
>>>>
>>>>
>>>> I’m not sure we’re framing the discussion in the most productive way.
>>>>
>>>>
>>>> Self-sovereign identity (SSI) is no longer purely conceptual — elements
>>>> of it already exist in our day-to-day digital interactions. The core shift
>>>> is not simply about what identity model we choose, but about user control,
>>>> privacy, and how trust is established.
>>>>
>>>>
>>>> A web-of-trust perspective reminds us that trust is not something we
>>>> can centrally declare or predefine. It emerges from verifiable
>>>> interactions, cryptographic proofs, and governance frameworks — rather than
>>>> being assumed by default.
>>>>
>>>>
>>>> Decentralized identifiers (DIDs), for example, allow identity to
>>>> function more like a network address anchored in cryptography instead of a
>>>> record anchored solely in an institution. This introduces properties such
>>>> as portability, reduced correlation, and resistance to single points of
>>>> control. These characteristics are not theoretical; they are already being
>>>> implemented and tested in real systems.
>>>>
>>>>
>>>> That said, government-led frameworks like EUDI or SEDI play an
>>>> important role in:
>>>>
>>>> • Legal recognition
>>>>
>>>> • Interoperability at scale
>>>>
>>>> • Liability and assurance models
>>>>
>>>> • Cross-border acceptance
>>>>
>>>>
>>>> So perhaps the question is not SSI vs government systems, but:
>>>>
>>>>
>>>> How do we accelerate implementation while aligning decentralization,
>>>> usability, and regulatory trust?
>>>>
>>>>
>>>> The meaningful debate is about:
>>>>
>>>> • Deployment speed
>>>>
>>>> • Governance design
>>>>
>>>> • Privacy guarantees
>>>>
>>>> • Recovery & lifecycle management
>>>>
>>>> • Real-world adoption
>>>>
>>>>
>>>> Trust, ultimately, is something we build into the system’s mechanics —
>>>> not something we merely assert.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Amir Hameed Mir
>>>>
>>>> Founder of Sirraya Labs
>>>>
>>>>
>>>> On Mon, 16 Feb 2026 at 10:26 AM, Steffen Schwalm
>>>> <Steffen.Schwalm@msg.group> wrote:
>>>>
>>>> Joe,
>>>>
>>>>
>>>>    1. Trusted issuer registry show somebody is allowed to issue
>>>>    something and trustworthy because in the registry
>>>>
>>>>
>>>>    - Controls on trusted issuer work in parallel e.g.
>>>>    - requirements to inform about security breaches within 24 hours
>>>>    Possibility for SB to start investigation or new conformity
>>>>    assessment by CAB
>>>>    - Conformity assessment based on provable international standards
>>>>    - Clear liability for QTSP
>>>>
>>>>
>>>> 2) Means nothing dangerous in arguments of  Nikos, it`s pretty much
>>>> similar to root stores from browsers but in hands of trustworthy authorities
>>>>
>>>> 3) there`s no centralized but distributed system as we have > 250 QTSP,
>>>> 31 TL, n CAB
>>>>
>>>> So recommend that we discuss alongside the actual regulation and eiDAS
>>>> technical framework.
>>>>
>>>> Best
>>>> Steffen
>>>>
>>>>
>>>> ------------------------------
>>>> *Von:* Joe Andrieu <joe@legreq.com>
>>>> *Gesendet:* Montag, 16. Februar 2026 05:45
>>>> *Bis:* NIKOLAOS FOTIOY <fotiou@aueb.gr>
>>>> *Cc:* Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <
>>>> agropper@healthurl.com>; Manu Sporny <msporny@digitalbazaar.com>;
>>>> Steffen Schwalm <Steffen.Schwalm@msg.group>; Filip Kolarik <
>>>> filip26@gmail.com>; public-credentials <public-credentials@w3.org>
>>>> *Betreff:* Re: Utah State-Endorsed Digital Identity (SEDI) legislation
>>>>
>>>> *Caution:* This email originated from outside of the organization.
>>>> Despite an upstream security check of attachments and links by Microsoft
>>>> Defender for Office, a residual risk always remains. Only open attachments
>>>> and links from known and trusted senders.
>>>> On Sun, Feb 15, 2026 at 1:15 PM NIKOLAOS FOTIOY <fotiou@aueb.gr> wrote:
>>>>
>>>> > “[browsers] don't have to "prove their code is secure” before
>>>> engaging with a website during a regulated activity”.
>>>>
>>>> This not true. Browsers have done this implicitly and many web sites
>>>> trust “well-known” browsers. If you try to access a web page with an
>>>> “unknown” or old browser you are denied access. Try for example "curl
>>>> https://www.aa.com/“.
>>>>
>>>>
>>>> This is a wonderful example of how we are talking past each other.  In
>>>> a previous email you also suggested *curl
>>>> https://www.us.emb-japan.go.jp/itpr_en/travel_and_visa.htm
>>>> <https://www.us.emb-japan.go.jp/itpr_en/travel_and_visa.htm> *
>>>>
>>>> And, in fact, a simple curl request to that URL fails. Fascinating.
>>>> That surprised me.
>>>>
>>>> However, if you install curl-impersonate, those two URLs open up like a
>>>> jack-in-the-box on the third turn of the crank.
>>>>
>>>> *curl_ff98 https://www.us.emb-japan.go.jp/itpr_en/travel_and_visa.html
>>>> <https://www.us.emb-japan.go.jp/itpr_en/travel_and_visa.html> *
>>>> *curl_ff98 https://www.aa.com <https://www.aa.com>*
>>>>
>>>> So, I acknowledge that you are correct. Apparently, both American
>>>> Airlines and the Japanese Embassy "maintain a list" of approved browsers. A
>>>> useless list, but the filtering is happening.
>>>>
>>>> Unfortunately, they lack a way to prevent impersonating browsers from
>>>> accessing content.
>>>>
>>>> The thing is, you *can* maintain a list of approved browsers, but it's
>>>> not actually going to stop bad actors. At most, it will keep naive actors
>>>> from taking advantage of your system.
>>>>
>>>> Making matters worse, every browser with a developer mode allows
>>>> current users nearly unlimited access to the browser. It's trivially
>>>> hackable. The idea of a secure client is simply unrealistic.
>>>>
>>>> The situation is much like the truism that "Locks don't keep thieves
>>>> out; locks keep honest people honest." The only thing that "approved" lists
>>>> achieve is preventing a bunch of potentially legitimate requests in
>>>> exchange for the false hope that you are preventing malicious activity. You
>>>> aren't actually preventing non-standard browsers from accessing your site.
>>>> You're only preventing non-criminals from accessing your services in their
>>>> preferred way. You think you're making things better, but you're actually
>>>> preventing innovation in the client's processing context. I know. I've been
>>>> fighting the Web's ineffective security-by-obfuscation for decades.
>>>>
>>>> More dangerous is the fact that your advocacy creates a false sense of
>>>> security, literally telling people something is secure when it is not.
>>>> Seriously, your email here is a dangerous recommendation. For anyone
>>>> reading, please DO NOT think that approved browser lists actually prevent
>>>> "unapproved" browser access.
>>>>
>>>> The truism that you can't trust the client is not just a web phenomenon
>>>> or my opinion; it's a deep cybersecurity principle. You might want to argue
>>>> with me, but I suggest you do some research before arguing against the
>>>> combined wisdom of 50+ years of cybersecurity experience.
>>>>
>>>> Seriously, search for "cybersecurity can't trust the client" and you'll
>>>> see a wealth of diverse opinions explaining in various terms why you
>>>> actually can't trust the client in cyberspace.
>>>>
>>>> And what we're seeing in the EUDI is the false belief that you can
>>>> somehow trust "certain" clients, leading to a security architecture that
>>>> centralizes power in the name of security without actually creating a more
>>>> secure system.
>>>>
>>>> You may not agree that the bad things that many of us fear are bad.
>>>> That's fine. Differences in values are fine reasons for differences in
>>>> policy. However, you cannot legitimately assert that depending on secure
>>>> clients is effective security. It isn't.
>>>>
>>>> Since the system is ineffective and many people see real harm in its
>>>> explicit centrality, several of us would love to see the EU shift away from
>>>> this harmful and inevitably insecure approach.
>>>>
>>>> -j
>>>>
>>>> --
>>>> Joe Andrieu
>>>> President
>>>> joe@legreq.com
>>>> +1(805)705-8651
>>>> ------------------------------
>>>> Legendary Requirements
>>>> https://legreq.com
>>>>
>>>>
>>>>
>>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>>> Virus-free.www.avg.com
>>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>>>
>>>>