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

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>
> *Gesendet:* Montag, 16. Februar 2026 10:50
> *Bis:* 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.
> 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
>
>