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

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