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

Hey
Can anyone here help me with the context of this thread, i haven't heard of
SEDI before

Thank you

On Fri, 13 Feb 2026 at 08:13, Jori Lehtinen <lehtinenjori03@gmail.com>
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:
>>
>>    1. 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
>>    2. Tokens held in accounts treated as pointers to actual assets with
>>    asset identifiers and the fraction of ownership (e.g. number of
>>    shares/bonds)
>>    3. Assets with identifiers assigned and credentials that can be used
>>    to verify existence and/or obligation - reference in the accounts holding
>>    corresponding tokens
>>    4. Participants with identifiers and credentials that can be used to
>>    verify qualifications to participate in a trade
>>    (identity/financial/regulatory)
>>    5. 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*:
>>
>>    1.
>>
>>    *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.
>>    2.
>>
>>    *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).
>>    3.
>>
>>    *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:
>>
>>    1.
>>
>>    That the receipt was issued by a processor they trust.
>>    2.
>>
>>    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:
>>
>>    1.
>>
>>    *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").
>>    2.
>>
>>    *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.
>>    3.
>>
>>    *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
>> <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>
>>
>>
>>
>>
>>
>>
>>