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

Hi Jori,


  1.  The machine acting as a digital proxy for an individual can verify that the wallet works as it should (for example: the distribution is signed and verified; the standardized code always requires frontend user verification for anything sensitive; and it provides direct programmatic access only to encrypted values for seamless backup, etc.).

  *
Which standard proven bvy whom? How is verification done based on which standardized code who proves that this cod eused?

  1.   Signatures made with a key derived from a physical ID, uploaded verifiably in the wallet, can always be verified by anyone they are presented to via a jurisdiction-specific registry holding the verification material and PID relevant in the given jurisdiction.

  *
PID is no QES please differentiate

    "Courts/jurisdictions set the standard for what must be verifiable, but a globally recognized and supported blockchain                     keeps custody of verification material—so, for example: a public key and PID + an event log corresponding to a physical ID.

  *
Which blockchain is globally recognized based on which verification material using which standard, where is PID coming from? PID only makes evident that somebody acted not necessarily signed document?
  *
Internationally we have ISO 25126 and ISO TS 2353 defining a) security in DLT & b) needed auditing. Seems also internationally there`s no trust by default but only by proof (of auditor)
  *   In eIDAS we have qualified ledger but a ledger with " a public key and PID + an event log corresponding to a physical ID." is no QES

  1.  When contracts are signed, it is up to the liable party to take care of the contract, because they want to be able to show: “This other person signed the contract.”

  *
Exactly this we already have. But eIDAS focus on other subjects; Who is liable that certificate of QES and the QES itself created in trustworthy way BEFORE the contract signed

So your principles won`t help because do not focus on actual subject: trustworthy QES.


"Decentralization like this works because everyone is responsible for (and incentivized to fulfill) their own role for their own protection, and everything is mathematically verifiable end-to-end—so any relying party can verify what they specifically need to trust."


  *
EIDAS wortks exactly in this way. QTSP responsible for its trustservice, CAB for conformity assessment, SB for Supervison etc.  subscriber to follow agreement


"What I would like to understand is: what exactly is the mechanism that ensures the event log presented in court by a TSP is tamper-evident?"


  *
See Section 7,9 , 7.10 of ETSI EN 319 401


"In my suggestion, this would perhaps be a central, audited, global blockchain holding the verification material—a centralized trusted entity, with a distributed system holding replicas and creating consensus."


  *
A Blockchain or  in generral DLT does not contain secure key management nor identification of 2FA and many more subjects to create trustworthy QES.
  *
For Detials on DLT Architecture and governance  is see e.g. ISO 23257 & ISO TS 23635 which are referenced by IA on Section 11 eIDAS for qualified ledger. That´s why CEN TS 18264 request use of QTSP on QES in case QES needed
  *



And the blockchain is supported by anyone who wants to contribute to the general trustworthiness of verification.

  *
What makes a blockchain trustworthy? Who ensures that the DLT works correctly? Who is everyone and what makes everyone trustworthy?

Tell me if I’m wrong, but in EUDI/eIDAS the legal safety of individuals depends on the good will of the TSPs—because how do you audit or prove a total system swap, or a total history rewrite, especially when they hold both the signatures and the verification material?

  *
Your are wrong as trust copmes from proof of the QES e.g. by any validation software which is independent for QTSP issuing certifcate for QES - means proof if QES valid or not does not depend on QTSP issuing the certifdate but the signature validation rules which are defined independently in ETSI EN 319 102 resp. ETSI TS 172-4
  *
If you use blockchzhain only you depend on the blockchain network without independent proof as the QES proven outside the original PKI and in case preservation service used you even do not depend on any part on QTSP issuing original certificate
  *
As QTSP bound to its CAB and SB you do not depend on the QTSP but the QTSP to 3rd parties contrilling it. Means in case of cheating the QTSP fully liable. Who is liable in case of blockchain if not QTSP for ledger used?

Details how QES works see https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ElekSignatur/esig_pdf.pdf?__blob=publicationFile



Compared to my suggestion, where trust is always mathematically verifiable to those that rely on it, and it serves individuals first, allowing real competition and innovation by treating legally binding signatures as an open primitive that anyone can build on.


  *
In eIDAS trust is not only mathematically verifialbe but also thorugh certifdate chain and legally provable through legislations
  *
If anyone can build signature without any requirements proven by somebody we end up in no trust but faith

BEst
Steffen



________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com>
Gesendet: Sonntag, 15. Februar 2026 13:28
Bis: Manu Sporny <msporny@digitalbazaar.com>
Cc: NIKOLAOS FOTIOY <fotiou@aueb.gr>; Filip Kolarik <filip26@gmail.com>; public-credentials <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.

EU folks,

I wanted to simplify why I dislike the idea of requiring audited, certified crypto hardware authorized by a commission and listed on a “list of lists”.

There are obvious reasons—like how inconvenient it is for me as someone trying to provide solutions in this field—but there are also real concerns:

Here’s the deal:

While these practices can indeed be very secure—and can ensure proper operational management, incident handling, etc.—what I cannot verify does not add trust to a transaction.

I can verify that a request came from a certified origin by looking up verification material from a list of lists, and given that those origins have strict legal requirements, that indicates plausible trust. But it does not verify that the actions creating the trust were actually performed.

Compare this to my example, where the relying party—the one that needs trust—can always verify the things their trust relies on:

  *   The machine acting as a digital proxy for an individual can verify that the wallet works as it should (for example: the distribution is signed and verified; the standardized code always requires frontend user verification for anything sensitive; and it provides direct programmatic access only to encrypted values for seamless backup, etc.).

  *   Signatures made with a key derived from a physical ID, uploaded verifiably in the wallet, can always be verified by anyone they are presented to via a jurisdiction-specific registry holding the verification material and PID relevant in the given jurisdiction.

  *   Courts/jurisdictions set the standard for what must be verifiable, but a globally recognized and supported blockchain keeps custody of verification material—so, for example: a public key and PID + an event log corresponding to a physical ID.

  *   When contracts are signed, it is up to the liable party to take care of the contract, because they want to be able to show: “This other person signed the contract.”

These principles are interoperable for any data and could operate on global technical standards, with jurisdiction-specific nuance on what must be verifiable for something to be legally binding.

Decentralization like this works because everyone is responsible for (and incentivized to fulfill) their own role for their own protection, and everything is mathematically verifiable end-to-end—so any relying party can verify what they specifically need to trust.

Now, there is probably/hopefully a tamper-evident history/log on the TSP and other “list of lists” members that they must be able to present in court. But they are still a single point of failure, making the system less reliable for an individual’s legal safety. What I would like to understand is: what exactly is the mechanism that ensures the event log presented in court by a TSP is tamper-evident?

In my suggestion, this would perhaps be a central, audited, global blockchain holding the verification material—a centralized trusted entity, with a distributed system holding replicas and creating consensus.

Then you have a decentralized, fully distributed set of actors holding the signatures that matter for their own legal safety.

And the blockchain is supported by anyone who wants to contribute to the general trustworthiness of verification.

Tell me if I’m wrong, but in EUDI/eIDAS the legal safety of individuals depends on the good will of the TSPs—because how do you audit or prove a total system swap, or a total history rewrite, especially when they hold both the signatures and the verification material?

This is exactly why some of us consider many of those grand statements and audit groups, etc., to be security theater.

Because some of us understand: TRUST FROM WHAT YOU CANNOT VERIFY IS NOT TRUST — IT IS CONVINCING (VIA A THEATER DISPLAYING: LOOK HOW MUCH WE ARE DOING).

I’m not trying to demonize the legislation or say the EU is bad, but you have to admit that the trust is, at best, plausible—and that it serves the legal system and well-funded private-sector actors first.

Compared to my suggestion, where trust is always mathematically verifiable to those that rely on it, and it serves individuals first, allowing real competition and innovation by treating legally binding signatures as an open primitive that anyone can build on.

It is also far more cost-effective, etc. The list of pros a system like that has is massive.

Regards,
Jori