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

Nope, see Sections 7.4 and 7.5 of ETSI EN 319 401., Section 4.2.1, 6.4.2, 6.4.5, 6.5.2, 6.5.5, 6.5.7, 6.8.4 of ETSI EN 319 411-1


________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com>
Gesendet: Montag, 16. Februar 2026 10:55
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com>; NIKOLAOS FOTIOY <fotiou@aueb.gr>; Joe Andrieu <joe@legreq.com>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com>; Manu Sporny <msporny@digitalbazaar.com>; 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.

Yeah you are right the definition of  QTSP in  ETSI EN 319 401 #sdction 7 and ETSI EN 319 411-1 does not have access. You are right what I said was wrong. Any individual with a capability to the very exact same physical hardware the QTSP uses has write access to everything.

ma 16.2.2026 klo 11.52 Steffen Schwalm (Steffen.Schwalm@msg.group) kirjoitti:
The QTSP has no write access to everything, sorry. See ETSI EN 319 401 #sdction 7 and ETSI EN 319 411-1


________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 10:50
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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.

The key thing here is the QTSP environment has write access to everything that is supposed to be used as auditing material.

This is an invariant you cannot deny, they would not be able to execute any operations if they could not execute all operations any similar hardware is capable of.

ma 16.2.2026 klo 11.48 Jori Lehtinen (lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>) kirjoitti:
Model used in the following two reports ChatGPT 5.2 Extended Thinking  + Web Search.
Full ChatGPT conversationcincluding messages prior to the two reports: https://chatgpt.com/share/69921d1f-c49c-8009-8df6-43267f8f818b

--------------------------------------------------------------------------------------------------

Below is a threat model you can paste into the thread. It’s written to stay neutral and to cite EU-recognized legal text + referenced standards (i.e., the stuff that actually matters “in the eyes of EU legislation”).

________________________________
Threat model: malicious (Q)TSP / insider in remote QES (remote QSCD / server signing)
Scope

We model a Qualified Electronic Signature (QES) created using a remote Qualified Signature Creation Device (remote QSCD) operated by a Qualified Trust Service Provider ((Q)TSP/QTSP), where signing is triggered via a web portal / remote API and protected (in theory) by strong user authentication and Signature Activation Data (SAD). Remote signing is explicitly contemplated by the eIDAS framework provided it achieves an equivalent security level and keeps signing “under the sole control of the signatory.”

Security property the framework is trying to guarantee

eIDAS ties legitimacy of advanced/qualified signing to a “sole control” concept:

  *   Advanced signature creation data must be usable by the signatory under their sole control (high confidence).

  *   QSCD requirements include that signature-creation data can be reliably protected against use by others.
Remote signing is allowed if those properties are preserved by the remote QSCD + procedures.

Assets

  1.  Signature-creation data (private key material, typically non-exportable inside the QSCD/HSM)

  2.  SAD / activation evidence used to authorize each signing operation (what proves “the user meant it”)

  3.  Audit logs / event history (portal logs, signing records, timestamps, etc.)

  4.  Qualified certificate + validation material (public key, chain, revocation status, trust anchors)

Trust boundaries (who must be trusted, vs what can be verified)

  *   A relying party can cryptographically verify “this signature matches this certificate.”

  *   But in remote signing, the relying party generally cannot cryptographically verify whether SAD was genuinely user-controlled vs. manufactured/abused inside the QTSP boundary; that becomes an assurance/compliance question.
This is exactly why the framework leans heavily on certification + supervision + liability controls.

________________________________
Adversary

Malicious QTSP, or an insider / compromised operator inside the QTSP environment, with the ability to:

  *   Run or modify the signing portal / authorization service,

  *   Call the signing interface that the remote QSCD/HSM exposes,

  *   Access or rewrite internal logs,

  *   Potentially issue/replace certificates (depending on how roles are deployed in that QTSP).

This is the “evil root operator” model—strong, but realistic to analyze because the whole remote model concentrates power.

________________________________
Attack A: “Sign without the human” (unauthorized use of the signing key)

Goal: produce a perfectly valid QES over arbitrary data without the signatory’s consent, by causing the remote QSCD to sign.

Mechanism (high-level):

  1.  The QTSP (or attacker inside it) submits signing requests to the remote QSCD/HSM interface.

  2.  The only intended “hard stop” is that the QSCD should require SAD (and whatever authentication ceremony produces it) for each signing operation. Remote signing standards explicitly define SAD-style activation.

  3.  If the attacker can bypass SAD enforcement or can mint/obtain SAD without the user (because the SAD issuance/validation is within the same compromised administrative domain), they can generate signatures that are:

     *   cryptographically valid,

     *   certificate-valid,

     *   and externally indistinguishable from legitimate signatures.

Why this matters legally/assurance-wise:
This attack—if possible—directly contradicts the “sole control” and “protected against use by others” requirements the regulation associates with advanced/QES and QSCDs.

What the framework uses to prevent/deter it (not “magic,” but the actual levers):

  *   QSCD certification / evaluation against recognized standards. The EU has an implementing decision that lists standards for QSCD security assessment (commonly referenced in practice around the CEN 419 241 family).

  *   Standardized activation protocols. The EU has an implementing regulation listing reference standards for remote QSCD services, including ETSI TS 119 431-1 (signature activation protocol).

  *   Policy/security requirements for server signing components. ETSI TS 119 432 is assessed in EU interoperability contexts (CAMSS), reflecting its relevance to regulated remote signing system design.

Residual risk (the key point):
Even if those standards are followed, the remote model still creates a structural dependency: outsiders verify the signature, but must trust that the QTSP-operated activation path really enforced user control. That’s fundamentally harder to make end-to-end cryptographically self-authenticating than a signer-controlled device model.

________________________________
Attack B: “Rewrite history” (log fabrication / selective disclosure)

Goal: make a false narrative of what happened (or didn’t happen) appear consistent and “audit-ready.”

Mechanism:

  1.  Attacker generates unauthorized signatures (Attack A) and/or selectively signs only some events.

  2.  Attacker rewrites portal logs / signing transaction records to match the story they want (or to remove evidence).

  3.  If challenged, they present internally consistent records.

Why detection is hard:
Because the signature validates, disputes collapse onto process evidence (“was SAD actually user-controlled at that moment?”), which is largely inside the QTSP boundary.

What the framework does about it (again: governance tools):

  *   Mandatory breach notification obligations (including within 24 hours after awareness for significant impact), which is intended to force disclosure when integrity is compromised.

  *   Recurring audits (at least every 24 months) by a conformity assessment body, plus supervisory powers to intervene.

These controls are meaningful, but they are not the same thing as a cryptographic impossibility of log rewriting.

________________________________
Attack C: “Validation-material control plane abuse” (trust/verification material)

This is about where verifiers get the data needed to validate signatures, and who can manipulate that ecosystem.

Where verification material is hosted in today’s eIDAS model

  *   Qualified certificates (public key + identity bindings) are issued by a CA/QTSP and are typically carried with the signature container and/or retrievable via CA infrastructure.

  *   Revocation status is provided via CA endpoints (CRLs/OCSP), also within the trust-service ecosystem.

  *   Trust anchors for “qualified status” are distributed via Trusted Lists (TL) per Member State and the EU “List of the Lists” (LOTL) mechanism, standardized for machine processing.

So: the crypto verification is “mathematical,” but the authorization of who counts as qualified is a directory/governance control plane.

________________________________
Why this threat model is relevant to the “trusted software list” debate

Even if the wallet ecosystem tries to protect users via certified wallet software, the EUDI ARF simultaneously contains privacy rules that avoid revealing wallet-unit attestation to relying parties (e.g., WUA only shown to PID/attestation providers during issuance, not to relying parties).
So relying parties often won’t get a strong software-attestation handle anyway—and your core concern stays: remote signing safety depends on what happens in a domain the user and verifier can’t directly measure.

________________________________
Minimal, standards-aligned statement of the concern

Remote QES can be compliant on paper because it is anchored in certification + supervision + liability, but a “malicious QTSP” threat model highlights a structural limit: a valid signature cannot, by itself, prove the signatory’s activation/intent if the activation ceremony is administered inside the same domain that can sign and rewrite logs. The framework mitigates via audited controls and standardized activation protocols, not by giving verifiers an end-to-end cryptographic proof of user-controlled activation.

________________________________

If you want to sharpen the knife further (without becoming unfair), the next move is to phrase a single crisp question back to Steffen/Nikos:

“Which specific evaluated boundary guarantees that SAD cannot be generated or replayed by the QTSP itself, and what is the verifiable artifact a relying party (or the user) can retain to prove that boundary was enforced for a given signature?”

That question forces the discussion onto mechanisms and artifacts, not vibes.
------------------------------------------------------------------------------------------------------------
Report: Why “low-assurance” client allowlists + remote signing can undercut eIDAS/EUDI’s stated goals
1) Scope and claim being tested

This report examines a specific tension in the EU’s trust stack:

  *   Policy goal (high level): legally reliable, cross-border digital trust that is user-centric and secure.

  *   Implementation pattern (practical): (a) trusted software / certification / allowlists and (b) remote signing via QTSP-operated infrastructure, defended as “protecting the user”.

The core question: If the system’s threat model includes client impersonation and insider misuse, do “lists + audits + certification” provide the kind of assurance the legislation is trying to achieve—or do they create a dangerous illusion of assurance?

________________________________
2) What eIDAS actually demands (the invariants that matter)
A. “Sole control” is not optional

eIDAS defines an advanced electronic signature as one created using signature-creation data that the signatory can use “under his sole control.”

Likewise, the QSCD requirements in Annex II include that signature-creation data can be reliably protected by the legitimate signatory against use by others.

These are not “nice-to-haves”; they’re the mechanical trust claims that justify legal effect.

B. Remote signing is explicitly contemplated—but it must still satisfy “sole control”

The consolidated eIDAS text explicitly talks about remote qualified signature creation and the need to ensure the signatory remains in sole control, even when things happen “remotely.”

That matters because it sets up the exact failure mode you’re arguing about:

Remote signing is permitted, but it creates a sharp question: how does anyone (including the user) validate “sole control” in a way that isn’t just “trust the provider + the auditors”?

________________________________
3) What the EU stack uses as assurance mechanisms (and where “low assurance” sneaks in)
A. Governance assurance: supervision, incident notification, periodic assessment

The model relies heavily on:

  *   Security obligations on QTSPs (risk management, incident handling, etc.), and notification duties for breaches.

  *   Conformity assessment and “qualified” status backed by standards and auditing.

This is real assurance—but it’s organizational / procedural assurance.

B. Standards acknowledgement: the system is “standards-based,” including remote-signing standards

The Commission’s implementing rules enumerate technical standards that are recognized for qualified services, including standards that cover remote QSCD / remote signature creation device management services and related protocols.

This is key to your argument: the EU doesn’t merely tolerate remote signing; it standardizes around it.

C. Wallet privacy design (relevant because it shows the user is treated as an active trust boundary)

The EUDI ARF high-level requirements include mechanisms to reduce correlation—e.g., per-relying-party presentation behaviors for PIDs/attestations/WUAs.

This supports your framing that the user is part of the verification perimeter, not just a passive subject.

________________________________
4) Threat model focused on the disputed risk
Assets

  1.  A legally-effective signature (QES / AdES) tied to an identity and a transaction.

  2.  Evidence of user intent/consent for that signature event.

  3.  The long-term verifiability story (what can be shown later to auditors/courts/users).

Adversaries (the uncomfortable but necessary ones)

  *   Client impersonators (software that looks like an “approved” client).

  *   Compromised wallet device / malware (steals session context, coerces signing).

  *   QTSP insider / compromised operator plane (can trigger signing operations using legitimate infrastructure).

  *   Governance failure (slow detection, incomplete logs, audit gaps).

Attack class you’re pointing at (high level, non-operational)

Remote signing can fail without key extraction:

  *   The private key stays inside certified hardware, but the system still performs signatures whenever the service’s software path authorizes it.

  *   If an insider or compromise can cause the service to authorize “one more signing event,” you get a signature that is cryptographically valid and legally meaningful—even if the user never intended it.

That is precisely the kind of failure that “you can’t trust the client” warns about, except here the “client” might be:

  *   the wallet runtime asking for a remote signature,

  *   or the internal service component asserting that the user authorized the signing.

________________________________
5) The contradiction: where “lists + audits” don’t meet the legislative goal-shaped security claim

Here’s the clean logical separation:

(1) The legislation’s invariant is cryptographic: “sole control”

eIDAS defines “sole control” as part of what makes an advanced signature advanced.
Annex II requires protection against use by others.

Those read like technical guarantees, not merely “we investigated and think it’s fine.”

(2) The remote-signing reality makes “sole control” mostly non-verifiable to external parties

A relying party can verify a signature mathematically.
But it generally cannot verify (from the signature alone) that:

  *   the user saw the document,

  *   the user approved that exact payload,

  *   the signature activation event wasn’t coerced or fabricated upstream.

So “sole control” becomes:

  *   a compliance claim (“the provider’s process enforces it”), backed by certification and audits,
not

  *   an end-to-end verifiable property (provable by artifacts the user and relying party can independently validate).

That’s the crux: the law’s trust claim is technical, but the proof is largely institutional.

(3) Trusted-software lists are a category error if used as a security boundary

Allowlisting “approved” wallets/browsers can reduce accidental harm and raise baseline hygiene.
But as a security boundary, it fails against impersonation and modification—because “approved client behavior” is not a physical law, it’s a hope with a certificate stapled to it.

In other words: allowlists help with “keep honest people honest” problems; they do not stop a determined adversary, and they can increase systemic risk by producing a false sense of security (“if it’s on the list, it must be safe”).

(4) This undermines the user-centric story in the exact place it matters most: legal intent

The EU wants citizens to safely rely on digital trust mechanisms at population scale.
If remote signing + allowlisting results in signatures that are:

  *   cryptographically valid,

  *   institutionally certified,

  *   but not independently attributable to user intent in a way the user can later defend without trusting the provider’s internal story,

then the system is drifting away from the spirit of “sole control” even if it remains inside the letter of standards-based compliance.

That’s how you get “secure on paper, spooky in court.”

________________________________
6) What would make it align better (without banning remote signing outright)

These are design patterns that convert “institutional assurance” into verifiable assurance:

  1.  User-held authorization artifact for every remote signature
The user should receive a receipt they can store independently: a signed record binding:

     *   what was signed (hash),

     *   when,

     *   under what policy,

     *   using what credential,

     *   and ideally a user-controlled confirmation factor.

  2.  User-controlled, non-exportable second factor that is outside the QTSP plane
Example shape: the QTSP can’t trigger signing unless a user-controlled authenticator approves a transaction-bound challenge.
This shifts “sole control” from “trust us” toward “prove it.”

  3.  Transparency / append-only logging that the user can independently monitor
If the only audit trail lives inside the same organization that can misbehave, your audit trail is a bedtime story.

  4.  Narrow remote signing to cases where it is demonstrably necessary
Treat remote signing as an exception path with stronger, user-verifiable artifacts—not the default path.

________________________________
7) Bottom line (the argument you can safely make in the thread)

  *   eIDAS defines advanced signatures using a technical invariant: signature creation under the signatory’s sole control.

  *   The framework explicitly supports remote signing, but that makes “sole control” hard to validate end-to-end without relying on institutional controls.

  *   The recognized assurance stack leans heavily on standards + certification + audits, including for remote QSCD management services.

  *   Those mechanisms can be good governance, but they are not cryptographic hard stops—and therefore can conflict with the goal-shaped promise that the user truly remains in control, especially against insider/compromise threat classes.

  *   The EUDI ARF’s privacy requirements reinforce that the user is an active trust boundary—so treating the user as not a verifier is inconsistent with the overall architecture direction.

That’s a coherent, EU-text-anchored critique: the system risks substituting “compliance assurance” for “verifiable assurance” right where the law’s trust claim is strongest.

(And yes, reality is annoying like that. Cryptography is the math of mistrust; regulation is the sociology of mistrust. When they disagree, someone eventually gets a very expensive lawyer.)

----------------------------------------------------------------------------------------

There is this term called zero-trust where trust is established only from what can be logically verified.

If the European Union is fine with systems architecture that has logical gaps where individual protections cannot be cryptographically verified then someone let me know and I wont push this issue any further.

I would still like to take time to craft and present a parallel model with better individual protection that could co-exists with the current models. But allow a better market for trust services and respect for individuals digital-sovereignty.

ma 16.2.2026 klo 11.01 Steffen Schwalm (Steffen.Schwalm@msg.group) kirjoitti:
The CEN EN is no law. So again Please explain your attack alongside the standard as you assume a behaviour which is not comprehensible knowing the standard

Thx
________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 09:59
An: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>
Cc: Steffen Schwalm <Steffen.Schwalm@msg.group>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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.

And my point still stands about the laws requirements not being a hard stop for logical behaviour, a specification is not a hard stop for behaviour logically possible either. If the text does not address physical reality correctly then the specification based on false realities.

ma 16.2.2026 klo 10.48 Amir Hameed (amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>) kirjoitti:

Hi Steve,

Thanks for the detailed breakdown. I want to clarify that my mention of Sirraya One was purely illustrative — to explain the mechanism of proving DID ownership via challenge-response and registry linkage. It was never intended as a product pitch, nor does it require anyone to vet or adopt our implementation. The goal was to show that simple, cryptographically grounded approaches can work in practice, even at scale.

I also want to emphasize a broader point: the world is not limited to EU, US, or UN-centric approaches. India alone represents billions of internet users in highly diverse conditions, and our implementations are tested under real-world constraints — high scale, fragmented connectivity, and heterogeneous devices. Lessons from these environments often differ from theoretical or lab-driven models.

Finally, while trade cases like the ones you describe are more complex, the fundamental principle holds: trust can be embedded in the cryptographic links between DID, VCs, and registries. Multi-party verification is an extension of the same mechanism, not a separate conceptual challenge.

I’m happy to continue discussing use cases and mechanisms, but my intention here is to focus on practical, field-tested approaches, not organizational validation or alignment.


Regards,

Amir


On Mon, 16 Feb 2026 at 2:13 PM, Steffen Schwalm <Steffen.Schwalm@msg.group> wrote:
CEN EN 419 241 is no law but the technical specification according to which the QSCD is build and implemented

Means you still lack of valid explanation alongside the standard how your proposed attack should work

Best
Steffen


________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 09:38
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>

Cc: NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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.

Law's requirements ARE NOT A LOGICAL STOP OF BEHAVIOUR.

LAW IS NOT A COMPONENT FOR TECHNICAL THREATH MODELLING.

But I think I have shown enough. Anyone can do with it what they want. Next I will work on a solution that actually fulfills the goals the EU Legislation has👍

ma 16.2.2026 klo 10.35 Steffen Schwalm (Steffen.Schwalm@msg.group) kirjoitti:
They can`t extract the keys without notice. See CEN EN 419241
________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 09:30
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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.

They can's extract the keys used for signing material. There is the signature only upon certain data presented. But that is software layer. They can use other software to interact with the hardware.

ma 16.2.2026 klo 10.27 Jori Lehtinen (lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>) kirjoitti:
I actually spent last night reading about it, how it works and what components there are there is nothing stopping the (Q)TSP from using the hardware in their custody...

ma 16.2.2026 klo 10.26 Steffen Schwalm (Steffen.Schwalm@msg.group) kirjoitti:
Jori,

May you please alongside the CEN EN 419 241 how EUDI "llowing a remote signing flow that allows a potentially malicious actor within the (Q)TSP use the privateKey representing you (not extract... use) to sign and fabricate any history they want that would remain verifiable in court, while making the local QSCD (Qualified Signature Creation Device) require a weird certificate"

The QSCD contains verifiable hard- and software bound not only to keys you control.

It would make it much easier to discuss if you could show where exactly in QSCD you see the issue.

Thx


________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 09:22
Bis: NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>
Cc: Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Steffen Schwalm <Steffen.Schwalm@msg.group>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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.

Nikos,

Does the EUDI protect the user by allowing a remote signing flow that allows a potentially malicious actor within the (Q)TSP use the privateKey representing you (not extract... use) to sign and fabricate any history they want that would remain verifiable in court, while making the local QSCD (Qualified Signature Creation Device) require a weird certificate instead of verifiable software behaviour with information only bound to a item you control by default that probably won't have a convinient API widely available (HUGE ASSUMPTION ON THE AVAILABILITY) resulting in remote signing being the default, and what is worse is that you as an individual cannot contribute to the durability of items required to verify your claims.

--------------------------------------------------------------------------------------------------

Model GPT 5.2 Extended Thinking + Web Search
AI Refined answer below and source here: https://chatgpt.com/share/6992d17b-8af4-8009-abad-c4b6d66e5909 <https://chatgpt.com/share/6992d17b-8af4-8009-abad-c4b6d66e5909>

What you are also missing is that you as a user are in the role of a verifier.

Help me strenghten this response with references to the EU legislation: > > More dangerous is the fact that your advocacy creates a false sense of security, literally telling people something is secure when it is not. Seriously, your email here is a dangerous recommendation. For anyone reading, please DO NOT think that approved browser lists actually prevent "unapproved" browser access. > > The truism that you can't trust the client is not just a web phenomenon or my opinion; it's a deep cybersecurity principle. You might want to argue with me, but I suggest you do some research before arguing against the combined wisdom of 50+ years of cybersecurity experience. > > Seriously, search for "cybersecurity can't trust the client" and you'll see a wealth of diverse opinions explaining in various terms why you actually can't trust the client in cyberspace. > > All boils down to who you want to protect. EUDI tries to protect the user. Lists of trusted software is fundamental when you are trying to protect the user. Government officials are recommended to use the Signal App and not any app claiming to use the OTR protocol. The Tor project recommends users to use the Tor browser and explicitly states "Using Tor with other browsers is dangerous and not recommended”. The EUDI DOES NOT try to protect the verifiers. Verifiers do not learn which wallet the user is using and the EUDI ARF explicitly prohibits this (see in Annex 2 of ARF "A Wallet Unit SHALL present a WUA only to a PID Provider or Attestation Provider, as part of the issuance process of a PID or a key-bound attestation, and not to a Relying Party or any other entity.”) Best, Nikos ---> Nikos, Does the EUDI protect the user by allowing a remote signing flow that allows a potentially malicious actor within the (Q)TSP use the privateKey representing you (not extract... use) to sign and fabricate any history they want that would remain verifiable in court, while making the local QSCD (Qualified Signature Creation Device) require a weird certificate instead of verifiable software behaviour with information only bound to a item you control by default that probably won't have a convinient API widely available (HUGE ASSUMPTION ON THE AVAILABILITY) resulting in remote signing being the default, and what is worse is that you as an individual cannot contribute to the durability of items required to verify your claims. What you are also missing is that you as a user are in the role of a verifier. Regards, Jori
Stopped thinking
To elaborate. What you are also missing is that in systems that respect the you the user also give you the role of a verifier when there are things you need to trust.
Thought for 2m 25s

Here’s a tighter, more “EU-text-backed” version you can send. I kept your core argument and anchored the contentious parts to the actual eIDAS / eIDAS2 wording, plus the EUDI ARF requirement you cited.

________________________________

Nikos,

I agree with you on the goal (protecting the user), but I think you’re mixing two different security questions:

  1.  Protecting the user from malicious software / phishing / spoofed wallets

  2.  Protecting other parties (and the user-as-a-party) from claims that are “legally true” even if the signing environment was compromised or misused

The European Digital Identity Wallet framework is explicitly user-centric: it is meant to provide secure access to services “while having full control over their data,” and the wallet must let the user request/obtain/store/present data “under the sole control of the user.”
It also bakes in anti-tracking requirements (no transaction tracking/linking/correlation unless explicitly authorised by the user).

So yes: lists/certification are a reasonable tool for user protection in that model (the EU even mandates publication of a list of certified EUDI Wallets).
And the ARF goes further in privacy terms: it says a Wallet Unit must release a WUA only to a PID Provider or Attestation Provider—not to a Relying Party or any other entity.

But none of that answers the other question: what protects against misuse of signing capability—especially in remote signing models—when the verifier (and the user) cannot independently validate how the key was used?

eIDAS is extremely clear about the invariant it wants: advanced signatures must be created using signature-creation data that the signatory can use “under his sole control.”
And Annex II requires that signature-creation data “can be reliably protected by the legitimate signatory against use by others.”

Now the important bit: the amended eIDAS text explicitly contemplates remote qualified signature creation devices and services. It states that generating/managing signature-creation data (and even duplicating it for backup) is carried out on behalf of the signatory and by a qualified trust service provider providing a qualified service for managing a remote QSCD.
That is a legal/assurance model that fundamentally depends on the QTSP’s controls being correct—because neither the relying party nor the signatory can typically cryptographically verify the QTSP’s internal enforcement in the way they can verify a signature.

Yes, the regulation piles on supervision (audits at least every 24 months, supervisory powers, breach notification “no later than 24 hours,” etc.).
But that’s compliance assurance, not cryptographic verifiability.

Finally, the part I think you’re missing:

In systems that “respect the user,” the user is not only protected—they’re also put in the role of a verifier whenever something must be trusted. The eIDAS2 wallet text actually reflects that: Member States must provide validation mechanisms that allow users to verify the authenticity/validity of relying parties, and the wallet must provide logs/dashboards so the user can see who they interacted with.

So when we talk about “trusted software lists,” we should be precise: they can help protect the user from bad clients—but they do not magically make the client “trustworthy,” and they do not resolve the verifier/user-verifier problem in remote signing trust models.

Regards,
Jori
------------------------------------------------------------------------------------------------------

There is no end-to-end verifiable way ensure the integrity of a remote signing service. Audits don't help when they can write the history.

Upon reading the AI refined answer. I think it is obvious the current implementations break EU LAW!!

The you cannot trust the client principle applies here!

The individuals device is there server relying on trusted behaviour from a "client" for wich there is no technically valid way to ever truly guarantee, as demonstrated by the CURL discussion.

Regards,
Jori


ma 16.2.2026 klo 9.42 NIKOLAOS FOTIOY (fotiou@aueb.gr<mailto:fotiou@aueb.gr>) kirjoitti:

>
> More dangerous is the fact that your advocacy creates a false sense of security, literally telling people something is secure when it is not. Seriously, your email here is a dangerous recommendation. For anyone reading, please DO NOT think that approved browser lists actually prevent "unapproved" browser access.
>
> The truism that you can't trust the client is not just a web phenomenon or my opinion; it's a deep cybersecurity principle. You might want to argue with me, but I suggest you do some research before arguing against the combined wisdom of 50+ years of cybersecurity experience.
>
> Seriously, search for "cybersecurity can't trust the client" and you'll see a wealth of diverse opinions explaining in various terms why you actually can't trust the client in cyberspace.
>
>

All boils down to who you want to protect. EUDI tries to protect the user. Lists of trusted software is fundamental when you are trying to protect the user.  Government officials are recommended to use the Signal App and not any app claiming to use the OTR protocol. The Tor project recommends users to use the Tor browser and explicitly states "Using Tor with other browsers is dangerous and not recommended”.

The EUDI DOES NOT try to protect the verifiers. Verifiers do not learn which wallet the user is using and the EUDI ARF explicitly prohibits this (see in Annex 2 of ARF "A Wallet Unit SHALL present a WUA only to a PID Provider or Attestation Provider, as part of the issuance process of a PID or a key-bound attestation, and not to a Relying Party or any other entity.”)

Best,
Nikos