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

Amir

I think we are saying exactly the same thing.  The issuing of the VC that inks the DID to the authority record is the easy bit.  

It’s the verification of it after the credential passes through half a dozen heads and is nowhere near the original holder.  I’ll repeat again

Exporting business mints a DID.  Interacts with the local authority and proves control (eg challenge-response).  Authority issues a VC attesting to that relationship (we call it a DIA credential) with authority as issuer and business DID as subject.  
To help make this DIA discoverable, the business adds a link to it as a service end point in their DID document.  
Quite separately, the business issues a Commercial invoice with the business DID as issuer.  
Also, the exporting business receives a VC issued by a chamber of commerce where the business ID is in the credential subject.  The chamber of commerce themselves have another DIA issued by a national authority conferring authority to issue CoCs under the terms of an FTA.
The commercial invoice and certificate of origin now go on a multi party journey.  You can see a visualisation of the journey just for the commercial invoice in this issue https://opensource.unicc.org/un/unece/uncefact/spec-unvtd/-/issues/24.  No less than 12 parties involved.  
Somewhere far away from the issuers of the invoice, the CoO, and the DIA a party totally unknown to any of those issuers (ie the importing customs authority and a correspondent bank in a trade finance relationship - need to verify several things
Is the invoice valid (ie not tampered) - simple VC validation
Who issued the invoice ?  The issuer DID is not sufficient as it’s just a meaningless number to this verifier - so they follow the link (did document service end point) to get the authority issued DIA that attests to the legal identity of the invoice issuer
Is the CoO valid (ie not tampered and not revoked) - again simple VC validation
Is the CoO issued by a party that is authorised to do so?  There are 10,000’s of chambers of commerce around the world so the verifier cant be expected to maintain a white list.  So they follow the same “whois” method to find a DIA attesting that the chamber is authorised by the national regulator. 
Is the CoO and the Invoice about the same consignment?  Now have to look inside both credentials to find the consignment URi. 

So many trade cases are like this.  The verification is NOT of a single credential (that’s the trivial bit). The verification that matters is one that has to work across a set of verifiable linked data contained in multiple credentials.  

Please don't jump to conclusions when you respond to these emails.  I’m sure Sirraya one can do many things (this is not a product marketing email list by the way).  But these trade use cases all require verification of relationships across multiple credentials - the “verifiable linked data graph”.  

Steve Capell
UN/CEFACT Vice-Chair
steve.capell@gmail.com
+61 410437854



> On 16 Feb 2026, at 5:04 pm, Amir Hameed <amsaalegal@gmail.com> wrote:
> 
> Hi Steve,
> 
> From an implementation perspective, the linkage problem is largely solvable without introducing new primitives.
> 
> A DID is already a cryptographic construct derived from open, well-understood mathematics and protocols. Once generated, it can be registered or referenced within a government or organizational trust registry.
> 
> Verification then becomes straightforward:
> 
> • During issuance, the authority records a verifiable association with the DID
> 
> • When interaction is required, ownership is proven via challenge–response
> 
> • The holder demonstrates control of the private key
> 
> • The signed challenge is validated against the registry’s stored identifier
> 
> In our Sirraya One implementation, the government (or authority) maintains the authoritative registry reference, while the subject retains control of the DID and associated VCs/capabilities.
> 
> This preserves:
> 
> ✔ Subject-controlled identifiers
> 
> ✔ Authority-asserted relationships
> 
> ✔ Cryptographic verification of control
> 
> ✔ No dependency on verifier pre-authorization
> 
> Which aligns well with the data-centric trust model you described.
> 
> 
> 
> Regards,
> 
> 
> 
> On Mon, 16 Feb 2026 at 11:23 AM, Jori Lehtinen <lehtinenjori03@gmail.com <mailto:lehtinenjori03@gmail.com>> wrote:
>> > 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 <mailto: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 <mailto: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 <mailto:amsaalegal@gmail.com>>
>>>>> Gesendet: Montag, 16. Februar 2026 06:08
>>>>> Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
>>>>> Cc: Joe Andrieu <joe@legreq.com <mailto:joe@legreq.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr <mailto:fotiou@aueb.gr>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com <mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org <mailto: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,
>>>>> 
>>>>> 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 <mailto:joe@legreq.com>>
>>>>> Gesendet: Montag, 16. Februar 2026 05:45
>>>>> Bis: NIKOLAOS FOTIOY <fotiou@aueb.gr <mailto:fotiou@aueb.gr>>
>>>>> Cc: Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>>; Steffen Schwalm <Steffen.Schwalm@msg.group>; Filip Kolarik <filip26@gmail.com <mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org <mailto: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 <mailto: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 
>>>>> 
>>>>> 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 
>>>>> 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 <mailto:joe@legreq.com>
>>>>> +1(805)705-8651
>>>>> Legendary Requirements
>>>>> https://legreq.com <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>