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

Appreciate that, Steffen.

The remaining challenges feel less about whether and more about how:
governance, lifecycle, UX, and deployment at scale. That’s where meaningful
progress can be made.


On Mon, 16 Feb 2026 at 10:49 AM, Steffen Schwalm <Steffen.Schwalm@msg.group>
wrote:

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