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

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