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

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