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

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>
> *Gesendet:* Montag, 16. Februar 2026 09:59
> *An:* Amir Hameed <amsaalegal@gmail.com>
> *Cc:* Steffen Schwalm <Steffen.Schwalm@msg.group>; 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.
> 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) 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>
> *Gesendet:* Montag, 16. Februar 2026 09:38
> *Bis:* Steffen Schwalm <Steffen.Schwalm@msg.group>
>
> *Cc:* 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.
> 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>
> *Gesendet:* Montag, 16. Februar 2026 09:30
> *An:* Steffen Schwalm <Steffen.Schwalm@msg.group>
> *Cc:* 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.
> 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) 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>
> *Gesendet:* Montag, 16. Februar 2026 09:22
> *Bis:* NIKOLAOS FOTIOY <fotiou@aueb.gr>
> *Cc:* Joe Andrieu <joe@legreq.com>; Kyle Den Hartog <kyle@pryvit.tech>;
> Adrian Gropper <agropper@healthurl.com>; Manu Sporny <
> msporny@digitalbazaar.com>; Steffen Schwalm <Steffen.Schwalm@msg.group>;
> 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.
> 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) 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
>
>