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

Jori,

Your breakdown of actors is architecturally clean, but it overlooks a fundamental reality of modern finance: Settlement is a State problem, not a Credential problem.

The merchant doesn't actually need a "Receipt VC" from the user. They need to verify the State of the Ledger (whether public or bank-internal). We are currently in danger of over-engineering a redundant "Identity layer" to prove facts that the settlement layer already knows.

The real challenge isn't the "Proof of Purchase" -- it's the Lifecycle of the Transaction (Charge-backs, Disputes, and Liability).

In a high-assurance ecosystem, we don't need the merchant to know the user's identity; we need the Processor to trust the Integrity of the Authorization Logic. This is where the current W3C/EUDI debate fails(?). We are fighting over "Blessed Wallets" when we should be focusing on Audited Execution:

State over Credentials: The Merchant verifies payment by checking the settlement state. The "Receipt" is a byproduct of the ledger, not a VC that needs to be carried by the user.


Logic over Identity: To handle risk (like charge-backs), the Processor needs assurance that the transaction was authorized by a client running Audited Logic (e.g., a "Smart Account" or Agent bound by specific institutional policies).


The Open KYA Angle: We solve this by having Public Auditors sign the logic of the signer, not the identity of the user. The Agent proves via ZK-Attestation that it is executing an audited logic package.



This provides the Merchant with settlement finality and the Processor with a "Duty of Loyalty" guarantee (that the agent is acting in the user's best interest) without requiring the user to ever disclose their identity or use a state-mandated "walled garden" wallet.

In our humble amateur opinion; if we keep trying to solve settlement with Identity VCs, we are just adding latency and complexity to a problem that blockchains and banking APIs solved years ago.



---

The best,

LKL

Engineering Excellence.

Creative Renaissance.

Hyper Optimization.









From: Jori Lehtinen <lehtinenjori03@gmail.com>
To: "Lars Kæraa Lücke"<lkl@cph.ai>
Cc: "Anders Rundgren"<anders.rundgren.net@gmail.com>, "Joe Andrieu"<joe@legreq.com>, "Christopher Allen"<ChristopherA@lifewithalacrity.com>, "Detlef Hühnlein"<detlef.huehnlein@ecsec.de>, "public-credentials"<public-credentials@w3.org>
Date: Fri, 13 Feb 2026 11:44:36 +0100
Subject: Re: Utah State-Endorsed Digital Identity (SEDI) legislation



A large class of these problems dissolve once we apply basic systems thinking and separation of concerns.

In a typical payment flow, there are at least three distinct actors:

The individual (buyer)


The processor (payment network / bank)


The merchant (service provider)



Each has a different authority boundary. Conflating them is where architectural mistakes begin.

The individual controls their identity and payment capability in their wallet. For example, a tokenized card represented as a Verifiable Credential (VC) issued by the processor. That credential authorizes payments. It is not identity.

The processor verifies the payment authorization and issues a receipt credential, a proof that payment has been completed. That receipt is the only thing the merchant should require.

The merchant verifies:

That the receipt was issued by a processor they trust.


That the presenter of the receipt is the rightful subject of that receipt.



At no point does the merchant need the card number or payment instrument identifier. They need proof of payment, not entitlement to charge.

In many cases, even a persistent personal identity may not be required. An ephemeral DID tied to a specific order could represent control over that order. The same mechanism works for delivery confirmation, locker pickup, subscription access, etc. Control over the order or subscription is cryptographically provable without disclosing more than necessary.

If we decompose the system to primitives first, clarity emerges:

Verifiable Identifiers


Verifiable Claims


Wallets / Storages / Holders


Transport channels



Then we consider actors:

Merchant


Processor


Customer



Then we minimize disclosure:

Card token → disclosed only to processor


Order details → disclosed only to merchant


Receipt → disclosed to merchant as proof of payment


Delivery authorization → disclosed only to delivery handler



Each authority sees only what it must.

Decentralization is about treating each computer as an actor in a distributed system where everything get's verified cryptographically.

Selective disclosure is easier to understand as minimum viable disclosure required for some process including multiple parties to work.

Regards,
Jori Lehtinen



pe 13.2.2026 klo 12.27 Lars Kæraa Lücke ( mailto:lkl@cph.ai ) kirjoitti:







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 http://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 < mailto:anders.rundgren.net@gmail.com >
To: "Joe Andrieu"< mailto:joe@legreq.com >
Cc: "Jori Lehtinen"< mailto:lehtinenjori03@gmail.com >, "Christopher Allen"< mailto:ChristopherA@lifewithalacrity.com >, "Detlef Hühnlein (ecsec GmbH)"< mailto:detlef.huehnlein@ecsec.de >, < mailto: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 >     http://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>