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

Hi Everyone,


We’ve been following this debate with great interest. The tension between the EUDI (State-Anchored) and SEDI (Individual-Anchored) models highlights a critical gap in our current architecture: How do we trust the Client without controlling it?

Joe Andrieu correctly points out that "You literally can't discern a legitimate client from one which has reversed engineered all of the authentication mechanisms." Christopher Allen warns that enforcing this via OS mandates leads to platform capture by "Google and Apple."

This creates a false dichotomy: either we whitelist "State Wallets" (centralized control) or we accept the "Wild West" (zero assurance).

There is a middle path: Cryptographic Assurance of Code Execution.

At HUV.AI, we are working on the Open KYA (Know Your Agent) standard, which approaches this problem differently. Instead of whitelisting apps, we propose a framework where Public Institutions and Auditors act as the root of trust for Code Integrity.

Here is how it bridges the gap:

Authoritative Auditors: Trusted entities (e.g., State Agencies, NGOs, or Security Firms) audit and cryptographically sign the logic of a wallet or agent. They aren't issuing the identity; they are attesting to the software's behavior (e.g., "This code respects user privacy and does not phone home").


Zero-Knowledge Proofs (ZKPs): The wallet doesn't just present a credential; it generates a ZK proof that it is running Authorized Code correctly. This allows for true selective disclosure (as Anders noted is difficult) without revealing the user's raw data or the wallet's internal state to the Verifier.


Hardware Binding (TEEs): As a foundational layer, we bind these ZK proofs to the hardware (via TEEs) to prevent cloning or spoofing. This ensures the "software" isn't just a script running in a malicious emulator.



This model allows for Permissionless Innovation (anyone can build a wallet) combined with Institutional Assurance (Verifiers only accept proofs from wallets running code signed by auditors they trust).

It shifts the ecosystem from "Who built this app?" (Vendor Trust) to "Who audited this logic?" (Institutional Trust).

We believe this combination of Institutional Signers and ZK-Proven Execution is the only way to satisfy the EUDI's need for security without violating the SEDI's requirement for sovereignty.

https://github.com/open-kya/kya-standard  - The standard, looking forward to your feedback.

https://www.huv.ai/  - Example application and main adoption vehicle, registry due to release next week.
 

---

The best,

LKL

Engineering Excellence.

Creative Renaissance.

Hyper Optimization.









From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: "Joe Andrieu"<joe@legreq.com>
Cc: "Jori Lehtinen"<lehtinenjori03@gmail.com>, "Christopher Allen"<ChristopherA@lifewithalacrity.com>, "Detlef Hühnlein (ecsec GmbH)"<detlef.huehnlein@ecsec.de>, <public-credentials@w3.org>
Date: Fri, 13 Feb 2026 10:33:08 +0100
Subject: Re: Utah State-Endorsed Digital Identity (SEDI) legislation



On 2026-02-12 22:59, Joe Andrieu wrote: 
> I just want to note one disconnect in your framing, Anders. 
 
There are many disconnects in the EUDIW project.  One of the more fundamental is that payments and identity are considered as more or less the same thing. 
That is, Merchants are described as replying parties requiring you to present your account number or similar. 
This is obviously wrong, Merchants SHOULD [normally] NOT have your account number.  Merchants only need some kind of receipt that they actually have been paid; something only the associated Payment Network can offer. 
 
A payment card is not an identity card; it is an entitlement for authorizing payments from a specific account.  The card-holder is supposed to have been subjected to a KYC process before receiving the card. 
 
In the EUDIW they rather try combine identity-related data and payment authorizations in a single message using selective disclosure.  Selective disclosure have legitimate uses, but not in schemes involving multiple and usually unrelated parties.  Disclose what and for whom? 
 
OTOH, not even the W3C succeed either: 
https://www.w3.org/TR/secure-payment-confirmation/#sctn-privacy-credential-id-tracking-vector  
 
 "Even for a single payment instrument, the credential ID(s) returned by 
 the Relying Party could be used by a malicious entity as a tracking vector, 
 as they are strong, cross-site identifiers. However in order to obtain them 
 from the Relying Party, the merchant already needs an as-strong identifier 
 to give to the Relying Party (e.g., the credit card number)." 
 
thanx, 
Anders 
 
> 
> On Thu, Feb 12, 2026 at 2:16 AM Anders Rundgren < mailto:anders.rundgren.net@gmail.com  <mailto: mailto:anders.rundgren.net@gmail.com >> wrote: 
> 
>     [...] 
> 
>     - Banks and VLOPs (Very Large Online Providers) are unlikely to accept more than a handful of wallets.  In fact, GSDV in Germany has already begun integrating EUDIW functionality in their mobile banking app.  Fragmentation is a European specialty. 
> 
> 
> How is this NOT just creating another wallet? 
> 
> Instead of GSDV relying on an open wallets chosen by individuals that can handle both public and private sector interactions, they are creating their own. Are they just hoping to be one of the "handful" of wallets that win the wallet wars? This is the exact opposite of what we want: more competition for becoming the "one" blessed wallet. What we want is competition for becoming the *best* wallet. We don't do that by restricting which wallets are even allowed to be "a wallet". We do it with a laser focus on the minimum API that every wallet can use, regardless of format, protocol, etc. 
> 
> The fact is, you cannot actually tell if the wallet you're interacting with is the kind of wallet you think it is. The idea of restricting to particular set of approved wallets is guaranteed to be compromised by attackers who figure out how to spoof the blessed wallets. It's not a matter of if, but a matter of how often. 
> 
> This is a dominant idea in the European framework, and it will almost certainly cause the current EUDI framework to fail in achieving its larger goals. Yes, it will likely provide an interoperable way for each nation-state's walled silos to selectively share state-issued credentials with other states. That's worth celebrating. But the restrictions on that wallet paradigm make it nearly useless, IMO, for most private sector use, which requires features like different cryptosuites and data formats that EUDI ignores. If EUDI wallets don't support arbitrary DIDs and arbitrary digital credentials (VCs, mDocs, zCaps, etc.) then other wallets will emerge to fill the gap in the marketplace, resulting in a dual wallet architecture in Europe. One for state-sponsored credentials and those for the rest of society. I've already seen discussion along these lines with the advent of the EU Business Wallet (whatever that really is). 
> 
> Any decent investigation into detecting the browser (when you are the website) will show you the problem. It is a well-worn piece of advice in cybersecurity that you NEVER trust the client. You literally can't discern a legitimate client from one which has reversed engineered all of the authentication mechanisms and appears legitimate. 
> 
> The EU's attempt to control which client software is used is just going to restrict adoption in the market. Innovation will move to those who aren't slowing down to deal with the limitations of centralized designs and instead support open standards for credentials and exchange. 
> 
> The Web is the guiding star here. As long as CompuServe and AOL relied on proprietary clients to restrict access to their proprietary server, the social and economic opportunity for online services was necessarily constrained by alignment with those companies' visions of how "online" should be. 
> 
> When TBL invented the Web, he created a way for anyone anywhere to publish content that is seemlessly linkable from any other website that chooses too. The wild ride of the late 90s was fueled by unfettered economic opportunity that came from allowing individuals, startups, and established players to innovate and provide services without requiring permission those who controlled the walle gardens. The freedom of open source and open standards unleashed significant economic activity and wealth generation. What the EUDI is doing is more likely a temporary technological advance that the market will quickly outpace, just like France's Minitel, which was once ahead of the game (launched in 1982), but couldn't compete with the World Wide Web. It was shut down in 2012. https://www.bbc.com/news/magazine-18610692  < https://www.bbc.com/news/magazine-18610692 > 
> 
> Dr. Pramod Varma, Chief Architect of Aadhaar, made this point at GDC last year. In my words: Worrying about securing the wallet is a distraction. Focus on APIs and protocols that enable anyone to reliably participate in the emerging platform, and you will see untold innovation, far beyond what central planning could champion. 
> 
> What's happening in the EU is the opposite of open innovation and I expect it will need to be reengineered within the decade. 
> 
> -j 
> 
> 
> -- 
> Joe Andrieu 
> President 
> mailto:joe@legreq.com  <mailto: 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 > 
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>