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

Amir, very nicely articulated. What you describe—how to put the basic
building blocks of SSI together so we can evolve from the "web of trust"
model to an Internet of Trust model—is the whole raison d'etre of the First
Person Project <https://www.firstperson.network/white-paper>. Your list of
bullet points reads literally like our charter.

As solutions like the First Person Network come online, I think we can
start to steer a middle ground between government ID systems (whether
EUDI-centric or SEDI-centric) and the millions of account-based ID systems
and federated ID system (e.g., OpenID) we have today. Both can become part
of a network of interoperable verifiable trust communities
<https://docs.google.com/document/d/1gqFqUAYy_huBbn6YakPBScotO15PA0nLq1_9uJkr6bY/edit?tab=t.0#heading=h.slargekc2r7v>
(VTCs).

And this approach can also empower us to deal with proof of agenthood for
AI agents, not just proof of personhood for people.

We'll be diving deep into this at the H2H Summit on Human Agency
<https://events.linuxfoundation.org/summit-on-human-agency/> in Napa next
Monday and the Linux Foundation Member Summit
<https://events.linuxfoundation.org/lf-member-summit/> the following
Tue/Wed. If any CCG members are coming to those events, I look forward very
much to talking w/you there.

=Drummond

On Sun, Feb 15, 2026 at 9:11 PM Amir Hameed <amsaalegal@gmail.com> wrote:

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