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

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