Re: [Possible phishing attempt] Re: Utah State-Endorsed Digital Identity (SEDI) legislation

Hi Jori,

I agree about signatures. Verifiability depends on signatures.

Each transaction has to be signed by both parties and a verifiable notary (to prevent double spend) as these accounts are portable and self contained. Hash linking is more to do with the ordering and maintaining history than verifiability of ownership.

This proposal is in reaction to increasing fragmentation in digital assets space both in terms of number of Blockchain networks and non-interchangeable tokens in the form of stablecoins representing the same underlying asset such as USD.

Blockchain interoperability is not going to have an easy solution and moves the entire verification and settlement execution off chain. So, the reason for using Blockchains disappears and latency due to global consensus and network specific finality requirements makes them even less attractive.

As most transactions happen between two parties, the process of verification and settlement should ideally involve just the parties - no global consensus needed.

Sent from [Proton Mail](https://proton.me/mail/home) for iOS.

-------- Original Message --------
On Friday, 02/13/26 at 15:05 Jori Lehtinen - lehtinenjori03 at gmail.com <lehtinenjori03_at_gmail_com_zaypd@simplelogin.co> wrote:

> Thanks Venu, that makes a lot more sense now, and it’s what I would consider nearly ideal for your described use case as well.
>
> One thing I’ve realized, though, is that hashes have very little value from a trust standpoint.
>
> Signatures have much more value, because you can first get a signed payload from the other peer saying:
>
> “Hey! Use this to verify messages from me.”
>
> Then you do the same for them.
>
> Both parties keep a causal chain of signed entries wich all include a content digest and are verifiably anchored to an entity.
>
> In comparison, hashes provide a digest and causality, but can be emulated by anyone at anytime.
>
> Signatures add provable intent from someone.
>
> Wich makes the causal history actually mean anything.
>
> Another example :
>
> Signature gives a UNIX timestamp real meaning, as in what someone auhtorized at this time.
>
> Here the UNIX can be used as anchor for what someone intenteds to happen when others UNIX time is the same.
>
> In a hash on the otherhand wich can be generated without a secret value, is no trust.
>
> Think Browser CSP for example a browser running only scripts that match hashes brings security only because the hashes came from headers verifiably singed by the server.
>
> Regards,
>
> Jori
>
> pe 13.2.2026 klo 10.31 ip. Venu R <w3c@misc.reddyhome.us> kirjoitti:
>
>> Hi Jori,
>>
>> What I said in my message is more about markets where assets are traded by consent of two peers.
>>
>> When I say a ledger my intention is to have a portable micro ledger representing the hash linked list of all transactions and ownership state of one account (owned by one entity). My intent is that this should be infrastructure independent (Blockchain/personal devices/corporate networks/brokerages, etc.) similar to KERI or DID:cel but with value exchange transactions.
>>
>> Having such a ledger with an assigned identifier (DID) and certified ownership facilitates establishing the right to trade when trade is being agreed to and execute settlement with verifiable finality (which is critical in any financial transaction).
>>
>> A charge back in this case is a reversal of a transaction that already occurred. Order here is a transaction that happened between two accounts (micro ledgers) and its participants are recorded.
>>
>> A reversal of the transaction should involve moving the value (tokens or another form of value) back. Of course who can reverse the transaction (in some cases, it may be just a refund without accompanying return) has to be established and be verifiable.
>>
>> Hopefully, I addressed your comments.
>>
>> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
>>
>> On Friday, February 13th, 2026 at 10:11 AM, Jori Lehtinen - lehtinenjori03 at gmail.com <lehtinenjori03_at_gmail_com_zaypd@simplelogin.co> wrote:
>>
>>> Hi Venu,
>>>
>>> I agree with everything else you are saying except,
>>>
>>>> Value ownership is represented in a ledger state and certified.
>>>
>>> In theory, value ownership can be represented fully ignorant of location.
>>>
>>> Consider yourself a relying party, a client is demanding a chargeback. First, you care about whether this user actually has anything to do with a given order. At a minimum, you need a signature from a private key corresponding to the public key you have for that orders identifier.
>>>
>>> Then you might see the status details of the order and have stored a claim issued by the payment provider saying payment was received, you can verify with the provider’s public key, you might have cached, resyncing with the provider opportunistically.
>>>
>>> Now you know this order was made by the client and proceed to process the chargeback. If it is according to your policy, you sign a request for the provider to do it and get a signed proof that the provider has initiated the chargeback in return.
>>>
>>> No ledger / blockchain or any centralized factor is necessarily needed, just consensus on roles and verifiability of those roles.
>>>
>>> As long as the correct cryptographical values are presented by the right entities, regardless of machine or location, they are trustworthy.
>>>
>>> Every actor keeps custody of capabilities that matter for their own liabilities, and other trust only when those capabilities are presented verifiably.
>>>
>>> All these principles are data agnostic and work in every setting.
>>>
>>> Add these with standardized Resource Description Framework / Schemas, and you have fully decentralized verifiable interoperability on anything.
>>>
>>> THIS IS MY MAIN POINT: Every actor keeps custody of capabilities that matter for their own liabilities / responsibilities, and other trust only when those capabilities are presented verifiably.
>>>
>>> pe 13.2.2026 klo 16.23 Venu R (w3c@misc.reddyhome.us) kirjoitti:
>>>
>>>> I have been involved in both identity and assets for multiple years and one of my areas of interest is in arriving at a decentralized value exchange framework. My most recent thinking is along these lines:
>>>>
>>>> Decentralized markets that can support value ownership at the edge and peer to peer value exchange would need the following components:
>>>>
>>>> - Portable accounts (ledger of verifiable transactions) with verifiable identifiers that can hold pointers to assets (tokens) - should be possible to store in personal devices, Blockchains or brokerages
>>>> - Tokens held in accounts treated as pointers to actual assets with asset identifiers and the fraction of ownership (e.g. number of shares/bonds)
>>>> - Assets with identifiers assigned and credentials that can be used to verify existence and/or obligation - reference in the accounts holding corresponding tokens
>>>> - Participants with identifiers and credentials that can be used to verify qualifications to participate in a trade (identity/financial/regulatory)
>>>> - Verifiably authentic issuers that can:
>>>>
>>>> - issue appropriate credentials,
>>>> - certify associations between various parts of the system (ownership of accounts, tokens referencing an asset and the fraction of ownership, for example),
>>>> - verify and certify regulatory requirements of transactions and
>>>> - certify settlement transactions and balances (moving tokens across accounts).
>>>>
>>>> As Lars said, credentials are to prove eligibility to do something (participate in a transaction, asset's existence and/or someone's obligation).
>>>>
>>>> Value ownership is represented in a ledger state and certified.
>>>>
>>>> Sent with [Proton Mail](https://proton.me/mail/home) secure email.
>>>>
>>>> On Friday, February 13th, 2026 at 5:35 AM, Lars Kæraa Lücke - lkl at cph.ai <lkl_at_cph_ai_ryaqra@simplelogin.co> wrote:
>>>>
>>>>> This email failed anti-phishing checks when it was received by SimpleLogin, be careful with its content. More info on [anti-phishing measure](https://simplelogin.io/docs/getting-started/anti-phishing/)
>>>>>
>>>>> 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 (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 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](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 <anders.rundgren.net@gmail.com <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
>>>>>>>>> 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](http://www.avg.com/email-signature)> Virus-free.www.avg.com <[http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail](http://www.avg.com/email-signature)>
>>>>>>>>>
>>>>>>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>