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

@Joris: Where is defined that distributed system needs consensus (beside a DLT)?


ChatGPT is great but obviouly wrong:

"Steffen’s bullets are describing a federated PKI/governance system"

Nope as the QTSP do no share federated PKI


"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."


  *
Nope, SB may request extraordinary audit by CAB after security breach acc, Art. 24
  *
SB does not do audit itself



"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."


  *
Who proves based on which standards accredited by whom and supervised by whom that the CRDT network works correctly?
  *
That`s why we defined even for DLT security & auditing standards in ISO resp. CEN-CENELEC


"-  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."

This is only one part. EIDAS defines legally and technically what QTSP is and based on which standards (so also the ones against which the QTSP certified). The TrustList is only one part defining how the trust framework technically works. Means trust proven via TrustList + certificates + mathematically in case of QES

"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."

Wrong as provable via LOTL and EC may stop national list in case of failure. Protocol in case of consensus won`t help - if whole consensus algorithm flawed no DLT will check this and no replication will help ;-)


"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."

You mix up trusted issuer registry in the sense of EBSI with List of registered RP acc. Art. 5b. The Trusted issuer registry in EBSI would work on ledger with replication but proven security in case of qualified ledger. Only issue: ETSI TS 119 612 would need slight changes.

So seems if we use ChatGPT it makes sense to feed it with correct information to get correct view on eiDAS ;-) Because distributed database is distributed system but without consensus mechanism...

Best
Steffen






________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com>
Gesendet: Montag, 16. Februar 2026 08:09
Bis: Amir Hameed <amsaalegal@gmail.com>
Cc: Steffen Schwalm <Steffen.Schwalm@msg.group>; 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.

threat* not a treat 😵‍💫

ma 16.2.2026 klo 8.59 Jori Lehtinen (lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>) kirjoitti:
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<mailto: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<mailto: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<mailto: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<mailto:amsaalegal@gmail.com>>
Gesendet: Montag, 16. Februar 2026 06:08
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:joe@legreq.com>>
Gesendet: Montag, 16. Februar 2026 05:45
Bis: NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>
Cc: Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Steffen Schwalm <Steffen.Schwalm@msg.group>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto: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


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

curl_ff98 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<mailto:joe@legreq.com>
+1(805)705-8651
________________________________
Legendary Requirements
https://legreq.com



[https://outlook.office.com/mail/?nativeVersion=1.2026.203.300]<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>