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

threat* not a treat 😵‍💫

ma 16.2.2026 klo 8.59 Jori Lehtinen (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) 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>
>>>>>
>>>>>