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

Back to square one it seems...

> Which standard proven bvy whom? How is verification done based on which
standardized code who proves that this cod eused?
Standards emerged from global academic consensus, singed by a trusted
publisher, verified by the operating system executing the wallet code as a
proxy for the individual.

> PID is no QES please differentiate

Of course personally identifiable information is not a qualified electronic
signature.
The issue is that you ignore physical reality by being too focused on what
is stated in the law currently we can change the law any time you cannot
change physical reality.
I'm arguing physical reality you are arguing text in a book.

The inputs, key lengths, and algorithms defined for QES are the same
regardless of which device they are on the trust comes from math as in it
would take a eternity to guess a 256 bit key for example, but the trust
also comes from presented information, as in the PID on a physicalID is
paired with relevant verifiably  (eg. hash comparison) verification
material in the state of the entity hosting the verification material.

INVARIANT: LOCATION IS A ILLUSION IN DIGITAL SYSTEMS!!!!!! THE CODE
VERIFYING OR DOING STUFF IN GENERAL IS NOT LOCATION AWARE!!!!!! I CAN SPOOF
LOCATION INFORMATION AT ANYTIME!!!!  AND IT IS EASY TO SPOOF IT IS A VERY
FINITE VALUE AND KNOWN WIDELY KNOWN VALUE!!!! A CRYPTOKEY IS THE ONLY THING
THAT IS HARD TO SPOOF!!!!

>  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?

There is not one, but it is a better idea to built that than what you are
currently building.

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

Blockchain is trust worthy because your every node verifies and correct the
state before gossiping it forward including the node you control.

Can someone help me teach these guys how cryptography works arrrrghh 😁

This is exactly why it is dangerous for the legislation to define too much.

Legislation should just define what needs to be verifiable in court.

Not the conditions how we get there! Because the verifiability is a
scientific invariant! Legislation shouldn't move to that domain at all!!


su 15.2.2026 klo 15.26 Steffen Schwalm (Steffen.Schwalm@msg.group)
kirjoitti:

> 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
>