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

Yeah,

>  You still claim subjects without making evident how it should work with
a QSCD. Only subjects "I can" is bit too less.

There is a massive difference in our approaches and I think it is good.

I have been trying to say I need to take time to formalize an alternative
model that makes things evident.

But you keep throwing me legislation articles or technical specification
sections. That in the context you present them seem attempts of denying
physical reality with a definition or behaviour a law or specification
hopes implementers follow.

It is not like you are making it evident how the issues I point are
addressed:
Model used ChatGPT 5.2 Extended Thinking  + Web Search.
Convo: https://chatgpt.com/share/6992f174-3578-8009-9422-4edaa93ecaa9
----------------------------------------------------------------

Here’s how Steffen Schwalm’s claims shake out *against the invariants
you’re implicitly using* (authority decentralization + verifiability >
“paper compliance”), with the *tightest EU-text anchors* we can point at.
------------------------------
1) “Distributed” ≠ “consensus” (Steffen is basically right — but it dodges
your actual point)

Steffen’s pushback (“distributed systems don’t *require* consensus”) is
correct as a *definition game*. Martin Kleppmann’s material makes the same
separation: “distributed” just means multiple networked components
coordinating; it doesn’t imply any particular convergence or byzantine
fault tolerance property.

But your invariant isn’t “is it distributed?” — it’s closer to:

*If the verification-control-plane matters for citizens’ legal safety, no
single governance domain should be able to unilaterally rewrite / suppress
it without being cryptographically outvoted.*

That property *does* require some kind of *multi-party replication +
externally verifiable append-only-ness* (consensus, or
CRDT-with-witnessing, or transparency logging, etc.). A plain “distributed
publication system” doesn’t buy it.

So: Steffen wins the dictionary point; you still win the *security-property*
point.
------------------------------
2) “250 QTSP / 31 TL / n CAB” is not protocol decentralization (your
critique stands)

The eIDAS trust backbone is explicitly a *directory + signatures +
governance* control plane:

   -

   Member States publish *national trusted lists* in a machine-processable
   form.
   -

   The European Commission makes the “list of lists” information available
   (the EU-level aggregation/control plane).

That is not a CRDT network of 250 QTSPs “keeping each other honest.”
It’s *rooted
authority per jurisdiction + a meta-directory*.

So when Steffen says your earlier framing was wrong (“federated
PKI/governance system”), he’s mostly just quibbling over the word
*federated*. Functionally, it *is* “multi-root governance + published
signed metadata,” not “multi-writer replicated state with convergence
guarantees.”
The clean invariant framing

   -

   *Market distribution:* many providers exist (250-ish QTSPs).
   -

   *Authority decentralization:* who can define “qualified” status is still
   centralized per Member State + EU-level aggregation mechanisms.

Those are different axes.
------------------------------
3) Supervisory body powers: Steffen’s correction is too narrow (and
partially wrong)

Steffen claimed (paraphrasing) “SB can request extraordinary audit by CAB
after a breach; SB doesn’t audit itself.”

But the consolidated eIDAS text says:

   -

   Trust service providers must notify breaches *within 24 hours* after
   becoming aware.
   -

   CAB-based conformity assessment is periodic (and the report is sent
   quickly).
   -

   *And* the supervisory body *“may at any time audit or request a
   conformity assessment body”* to assess a QTSP.

So:

   -

   “Only after breach” is *too narrow*.
   -

   “SB does not audit” is *contradicted by the text* (“may at any time
   audit…”).

------------------------------
4) “Remote signing breaks EU law” — that conclusion doesn’t follow (but
your *structural* critique is valid) What the law *actually* asserts as the
security invariant

For advanced signatures, eIDAS requires signature creation under the
signatory’s *sole control* (Article 26).
Annex II requires signature-creation data be *reliably protected by the
legitimate signatory against use by others*.

That’s the “goal-shaped” wording you’re leaning on.
What the system uses to justify meeting it (remote or local)

The framework leans hard on *standards + certification + supervision +
liability*, not on giving every relying party (or citizen) a cryptographic
proof of what happened inside the QTSP.

You can see the regulatory teeth in:

   -

   24h breach notification, supervision, periodic assessments.

And you can see the *technical* scaffolding for remote signing in the
referenced standards ecosystem (activation protocols / remote QSCD
requirements), e.g.:

   -

   ETSI TS 119 431-1 (signature activation protocol / SAD flows).
   -

   CEN 419 241 family / remote-signing protection profiles.
   -

   Supporting guidance from ENISA on remote signatures.

So what’s the correct conclusion?

   -

   You *cannot* infer “implementations break EU law” merely from “remote
   signing has a logically imaginable malicious-QTSP threat model.”
   -

   You *can* correctly say: *remote signing makes “sole control” less
   directly verifiable by outsiders*, and the framework compensates
with *institutional
   assurance* (certification, audits, supervision, liability), not
   “zero-trust cryptographic impossibility.”

That’s a critique of the model’s *assurance philosophy*, not a proof of
noncompliance.
------------------------------
5) “QTSP can rewrite everything” vs “QTSP has no write access to
everything” (both are overstated — the real point is *where the trust
boundary is*)

You said: QTSP has write access to auditing material ⇒ can fabricate
history.
Steffen replied: standards prevent that (citing ETSI EN 319 401 / EN 319
411-1).

What those standards families aim to do (at a high level) is:

   -

   force *separation of duties*, controlled admin access,
   -

   require *audit/event logging with integrity protections*,
   -

   ensure evidence is inspectable in conformity assessment.

That makes “rewrite everything with zero chance of detection” a *harder*
claim to sustain.

But your deeper invariant still survives:

If the only *authoritative* evidence of “user intent occurred” lives inside
the same administrative domain that can trigger signing, then the relying
party (and the user) ultimately depend on *institutional truth* when
disputes happen.

That’s exactly why your “verifiable receipt / user-retained artifact” line
is such a strong move: it shifts the debate from vibes to *what does the
citizen retain that doesn’t require trusting the QTSP’s internal story*.
------------------------------
6) Nikos’s “we’re protecting the user, not verifiers” claim is
*true-but-incomplete*

The European Commission ENISA/ARF direction is explicitly
privacy-preserving in ways that intentionally reduce “wallet
fingerprinting.” Example: the ARF requirement that Wallet Unit Attestation
is presented only during issuance flows (PID/attestation provider), *not*
to relying parties.

So Nikos is right that some mechanisms are designed to protect users and
privacy even if that withholds signals from verifiers.

But your counterpoint (“the user is also a verifier sometimes”) is aligned
with the same architecture direction: users need to assess relying parties,
consent, review logs, etc. That’s a “user as an active trust boundary”
worldview, not “user as passive subject.”
------------------------------
7) The sharpest “invariant-compatible” reply you can give Steffen (without
overclaiming)

If you want to keep it brutally technical and non-emotional, the best pivot
is:

   1.

   *Concede* the definitional point: distributed ≠ consensus.
   2.

   *Restate* your invariant: you care about *authority decentralization +
   user-verifiable assurance*, not topology words.
   3.

   *Ask* for the artifact:

“In remote QES, what is the evaluated boundary that guarantees the QTSP
cannot mint/replay SAD without the user — and what verifiable artifact can
the user or relying party retain that proves that boundary was enforced for
this specific signature event?”

That question pins the debate to mechanisms, not “trust us, we’re audited.”
------------------------------
Bottom line verdict on Steffen’s claims

   -

   ✅ *Correct (but mostly semantic):* “distributed does not require
   consensus.”
   -

   ✅ *Correct:* trust lists + certificates + signature math are core pieces
   of the qualified validation story.
   -

   ❌ *Wrong / too narrow:* supervisory body powers are not “only after
   breach,” and SB *can* audit (text says “may at any time audit…”).
   -

   ⚠️ *Misframed:* “LOTL / EC can stop a national list” (maybe practically
   true via the control plane), but that actually *supports* your
   central-authority critique rather than refuting it.
   -

   ⚠️ *Not a refutation:* “if consensus algorithm flawed, replication won’t
   help” — true but symmetrical (if certification/audit regime flawed,
   governance won’t help either). It doesn’t defeat your “cryptographic
   verifiability beats institutional narration” invariant.

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

Reality check (with a wink): eIDAS is not “zero trust,” it’s “regulated
trust.” Cryptography is the math of mistrust; regulation is the sociology
of mistrust. The tension you’re surfacing is exactly where those two
philosophies glare at each other across the room.
---------------------------------------

*> Reality check (with a wink): eIDAS is not “zero trust,” it’s “regulated
trust.”*
This exactly issue everybody on this list is making...


ma 16.2.2026 klo 12.17 Steffen Schwalm (Steffen.Schwalm@msg.group)
kirjoitti:

> How you want to gues the right data without hacking whole QTSP infra?
>
> "If either the data transmitted from a user device and encrypted is not
> decrypted only at the hardware / firmware level" There are no data
> transferred to your mobile.
>
> "I can spoof or replay or hijack the SAD even in theory." how you plan to
> do this within the QSCD flawing which of the requirements I menioned and
> how?
>
> Even in decentralized model:
>
>
>    - How you protect the keys in which environment, which hardware
>    protected how?
>    - How you ensure that your mobile is protected? Using which kind of
>    hardware protection? How you plan to meet requirements from CEN EN 419 241
>    as this is requirements for QES acc. EIDAS Annex III
>
>
> So again without being impolite Jori: You still claim subjects without
> making evident how it should work with a QSCD. Only subjects "I can" is bit
> too less.
>
>
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 11:08
> *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.
> Does the physical hardware structure specifically prevent usage unless
> data plausably only the user would know with *tls on the hardware level*?
> And if I guess right data and send it does the signature go trough?
>
> If either the data transmitted from a user device and encrypted is not
> decrypted only at the hardware / firmware level
>
> or
>
> I can spoof or replay or hijack the SAD even in theory.
>
> Then the assurance for *sole-control *is weak, and not logically ever
> true.
>
> There are gaps in the decentralized model, but they are scoped to an
> individuals mistake of losing a physical item.
>
> Again I do not care if this exists as long as other models with
> higher-assurance are accepted.
>
> ma 16.2.2026 klo 12.00 Steffen Schwalm (Steffen.Schwalm@msg.group)
> kirjoitti:
>
> Nope, see Sections 7.4 and 7.5 of ETSI EN 319 401., Section 4.2.1, 6.4.2,
> 6.4.5, 6.5.2, 6.5.5, 6.5.7, 6.8.4 of ETSI EN 319 411-1
>
>
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 10:55
> *An:* Steffen Schwalm <Steffen.Schwalm@msg.group>
> *Cc:* Amir Hameed <amsaalegal@gmail.com>; NIKOLAOS FOTIOY <fotiou@aueb.gr>;
> Joe Andrieu <joe@legreq.com>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian
> Gropper <agropper@healthurl.com>; Manu Sporny <msporny@digitalbazaar.com>;
> Filip Kolarik <filip26@gmail.com>; public-credentials <
> public-credentials@w3.org>
> *Betreff:* Re: Utah State-Endorsed Digital Identity (SEDI) legislation
>
>
> *Caution:* This email originated from outside of the organization.
> Despite an upstream security check of attachments and links by Microsoft
> Defender for Office, a residual risk always remains. Only open attachments
> and links from known and trusted senders.
> Yeah you are right the definition of  QTSP in  ETSI EN 319 401 #sdction 7
> and ETSI EN 319 411-1 does not have access. You are right what I said was
> wrong. Any individual with a capability to the very exact same physical
> hardware the QTSP uses has write access to everything.
>
> ma 16.2.2026 klo 11.52 Steffen Schwalm (Steffen.Schwalm@msg.group)
> kirjoitti:
>
> The QTSP has no write access to everything, sorry. See ETSI EN 319 401
> #sdction 7 and ETSI EN 319 411-1
>
>
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *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
>
>