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

Steffen ,

Why not can we discuss? Can you give me one use case where it doesn’t hold?

Regards

On Mon, 16 Feb 2026 at 7:05 PM, Steffen Schwalm <Steffen.Schwalm@msg.group>
wrote:

> Amir,
>
> I guess we have disagreement in "When the fundamental building blocks —
> DID + VC + Registry — already provide the necessary guarantees of
> integrity, provenance, and scalability, introducing additional
> administrative layers risks adding friction without adding capability.."
>
> My answer would be: No, DID+VC+REgistry alone are not sufficient
>
> Best
> Steffen
>
>
> ------------------------------
> *Von:* Amir Hameed <amsaalegal@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 14:31
> *Bis:* Steffen Schwalm <Steffen.Schwalm@msg.group>
> *Cc:* Filip Kolarik <filip26@gmail.com>; Jori Lehtinen <
> lehtinenjori03@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>;
> 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.
>
> Steve,
>
> I’m glad we’ve reached alignment. If we agree that the apparent
> “complexities” of multi-party trade are simply recursive applications of
> the same underlying cryptographic relationships, then the path forward
> becomes much clearer
>
> My core point is straightforward: we should resist the temptation to
> over-engineer the standards. When the fundamental building blocks — DID +
> VC + Registry — already provide the necessary guarantees of integrity,
> provenance, and scalability, introducing additional administrative layers
> risks adding friction without adding capability.
>
> The remaining challenge is less conceptual and more operational. Our focus
> should be on ensuring that the Verifiable Linked Data Graph remains as
> lean, composable, and decentralized as the mathematics that underpins it.
> Systems designed with this discipline are far more likely to achieve
> real-world adoption across diverse trade environments.
>
> I’d be happy to share observations from field deployments that may help
> keep the UN/CEFACT models closely anchored to what proves robust at scale.
>
> Looking forward to seeing these ideas continue to mature into practice.
>
>
> Regards,
>
> Amir
>
>
> On Mon, 16 Feb 2026 at 6:52 PM, Steffen Schwalm <Steffen.Schwalm@msg.group>
> wrote:
>
> Hi Filip,
>
> It already works as we can see with eIDAS 1 in Europe and the fact that
> half of the world reuse ETSI Standards reg. Signatures, seals, trustlists
> etc. It will workd with eiDAS 2 as well as we observe similar on eIDAS 2
> related standards.
>
> The formal process means: Members of SDO decide - not regulators ;-)
>
> Best
> Steffen
> ------------------------------
> *Von:* Filip Kolarik <filip26@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 14:19
>
> *An:* Steffen Schwalm <Steffen.Schwalm@msg.group>
> *Cc:* Jori Lehtinen <lehtinenjori03@gmail.com>; 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>;
> 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.
> Thanks, Steffen,
>
> It’s clear that we are far too far apart. The legislation is part of the
> problem, the EU simply wants to control everything and will achieve
> nothing. I understand that you don’t agree with this, but for now, I
> suppose that’s the only thing we can agree on.
>
> The EU approach will fail again, not because there is no collaboration
> between the EU and W3C, but because the kind of formal process you favor
> produces nothing truly useful. Instead, it results in pointless
> restrictions while limiting organic evolution and outside contribution. The
> “formal process,” as you call it, is just another way of saying: we decide,
> you follow. And claims about protecting citizens often feel like a
> smokescreen to hide the unpleasant truth; ultimately damaging the EU itself
> and weakening its impact in the broader global ecosystem.
>
>
> On Mon, Feb 16, 2026 at 2:09 PM Steffen Schwalm <Steffen.Schwalm@msg.group>
> wrote:
>
> Filip,
>
> The issue is that W3C focus worldwide which not necessarily meet European
> specifics driven by European regulation. We have similar discussions in ISO
> but fully understand even China or Korea or Japan etc. that they sometimes
> define their own standards to meet regional legal and/or market
> requirements.
>
> As ETSI and CEN open for any company/individual there´s no process in the
> dark either - only more formal one. Personally I love the formal processes
> because they ensure equality for everybody but understand that they might
> be hated by other ones.
>
> I guess a closer collaboration between W3C and European SDO would benefit
> both communities.
>
> Best
> Steffen
> ------------------------------
> *Von:* Filip Kolarik <filip26@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 13:59
> *An:* Steffen Schwalm <Steffen.Schwalm@msg.group>
> *Cc:* Jori Lehtinen <lehtinenjori03@gmail.com>; 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>;
> 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.
> I think this thread is way off topic. It’s great to see such vibrant
> discussion about the EU vs. SEDI approach. One thing to note is that we are
> discussing this openly on a W3C forum, while all W3C specifications live
> openly on GitHub, where anyone can raise an issue or formally object, even
> without membership. There is nothing quite comparable to this in the EU
> process, and after all, W3C is an international consortium; it’s not a
> US-only standardization body.
>
> I’ve never understood the EU’s obsession with creating a copy of something
> just to have its “own” European version. It's always worse than the
> original and only emphasizes that there may be something fundamentally
> broken within the EU that prevents European individuals and companies from
> bringing something new and succeeding with it, rather than being forced to
> simply swallow and use what is produced in the dark in the EU.
>
> Best regards,
> Filip
> https://www.linkedin.com/in/filipkolarik/
>
> On Mon, Feb 16, 2026 at 1:22 PM Steffen Schwalm <Steffen.Schwalm@msg.group>
> wrote:
>
> Recommend to look in the actual governance for the facts
>
> https://portal.etsi.org/Resources/ETSI-Directives
>
> https://boss.cen.eu/reference-material/refdocs/pages/
>
> https://www.w3.org/membership/
>
> If you can`t vote there`s no influence with impact possbile by design ;-)
>
> You can comment and send mail go mailinglist but you can`t take part in
> decision whether it´s recognized in standard or not. What`s commenting
> without decision making?
>
> So fully agree that more facts needed to proof your claims on QTSP -
> especially alongside the relevant mentioned standards
>
> Best
> Steffen
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 12:53
> *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.
> I find artificial intelligence to be a useful work horse to find
> information to support facts and realities I intuitively know to be trough
> via my natural intelligence:
> ----------------------
>
> Overall, Steffen’s paragraph is *mostly true in spirit* (I’d rate it ~
> *0.7/1.0* on factual accuracy * even when I lean in his favor*), but it
> *overstates* a couple of things and *blurs* some important distinctions
> about *what “participation” means* and *what “open” means*.
>
> Here’s the claim-by-claim truth check.
> 1) “W3C requests membership of organization for formal participation in
> standardization”
>
> *Mostly true (with a key caveat).*
>
>    -
>
>    W3C membership is *organizational*, and W3C explicitly says it *does
>    not have individual membership*.
>    -
>
>    But individuals can still participate *formally* in
>    Recommendation-track groups as *Invited Experts* (with approval), so
>    it’s not “membership or nothing.”
>
> ✅ *Steffen-favoring interpretation:* W3C’s *default* formal standards
> work is organization-centric, yes.
> 2) “Comment without voting rights is basically meaningless”
>
> *Not a factual claim; as a descriptive claim it’s mostly false.*
>
> W3C has multiple channels where non-members (or non-member-affiliated
> individuals) can influence outcomes:
>
>    -
>
>    *Community Groups* are open and *free* for anyone, and they frequently
>    incubate work that later moves into the “formal” track.
>    -
>
>    Many W3C Working Groups run substantial technical work in public issue
>    trackers and explicitly invite public input (even when meeting
>    participation is limited).
>
> So: you might not get a vote, but *your technical input can absolutely
> matter* (especially if you bring tests, interoperable implementations,
> threat models, or sharp issue filings).
>
> ✅ *Steffen-favoring interpretation:* if he means “you don’t get formal
> decision rights,” then sure. But “meaningless” is vibes, not reality.
> 3) “ETSI requests membership of organization similar to W3C … membership
> fee required”
>
> *Mostly true.*
>
>    -
>
>    ETSI has *membership dues/contributions* (so “fee required” is broadly
>    correct for membership).
>    -
>
>    ETSI membership is generally framed around *legal entities* committing
>    to ETSI rules/directives (the academic summary states this explicitly).
>    -
>
>    ETSI presents itself as “open and inclusive,” but that’s about the
>    environment/participation model—not “any random person can just vote in the
>    room without joining.”
>
> ✅ *Steffen-favoring interpretation:* yes, both are membership-based for
> *formal* participation in the core standards machinery.
> 4) “EN are on public review … sometimes TS”
>
> *Plausible, but not established by the sources I pulled in this run.*
>
> I’m not comfortable stamping this “true” without pointing to ETSI’s own
> procedure text (e.g., ETSI Directives stages like public enquiry /
> commenting), and I didn’t capture that primary procedural document in the
> sources above.
>
> ✅ *Steffen-favoring interpretation:* likely broadly correct in many
> workflows, but *needs a clean ETSI process citation* to be nailed down.
> 5) “So basically both work similar … both are open SDO … since every
> organization can become member”
>
> *Partly true, but “open” is doing a lot of work here.*
>
>    -
>
>    W3C: “Organizations may join… processes designed for organizational
>    participation.” Also explicitly: no individual membership class.
>    -
>
>    W3C: also has truly open lanes (Community Groups free; Business Groups
>    have fees for non-members).
>    -
>
>    ETSI: membership is fee-based; and ETSI also enables “direct
>    participation” compared to CEN/CENELEC’s national-body delegation model.
>
> So yes: both are “open” in the sense that *a wide range of organizations
> can join*. But they’re *not open in the same way* as a purely
> open-membership, no-fee, individual-driven process.
>
> ✅ *Steffen-favoring interpretation:* “open” as in *joinable by many orgs* and
> *outputs publicly visible*—fair.
> 6) “For individuals, CEN-CENELEC & ISO might be better… via National SDO”
>
> *Half-true (CEN/CENELEC part is supported; ISO part not verified here).*
>
>    -
>
>    CEN / CENELEC are described (accurately) as being structured around *national
>    standards bodies as members*, which typically means individual
>    participation is mediated through your country’s national body.
>    -
>
>    ISO is *very likely similar* (national member bodies), but I didn’t
>    pull an ISO primary source in this run, so I won’t certify that part as
>    “checked.”
>
> ✅ *Steffen-favoring interpretation:* directionally right—individuals
> often engage standards via national committees rather than paying into an
> org-membership consortium.
> 7) “All SDO work on consensus and controlled by an independent governance
> body… difference to DIF, OIDF”
>
> *Overbroad.*
>
>    -
>
>    “Consensus” is common, but *not universal* and not uniform (many
>    bodies have formal voting stages, appeals, weighted votes, etc.).
>    -
>
>    “Independent governance body” varies a lot by org structure.
>
> And saying that’s the “main difference” vs DIF / OIDF is more *argument* than
> *fact*—those groups also have governance and decision processes; they’re
> just different kinds of institutions (often more
> industry-consortium/product-profile oriented).
>
> ✅ *Steffen-favoring interpretation:* he’s gesturing at the real
> difference between “recognized SDO/ESO-style standardization” vs “industry
> alliance profiles,” but the wording is too absolute.
> ------------------------------
> Net verdict (Steffen-favoring)
>
> Steffen’s core comparison—*W3C and ETSI are both membership-based for
> formal standards decision-making, with public visibility and some public
> input channels*—is basically correct.
>
> The two biggest factual/structural corrections are:
>
>    1.
>
>    “No vote = meaningless” is *not true* in practice (especially at W3C).
>    2.
>
>    “All SDOs work on consensus” is *too sweeping* to be treated as
>    factual.
>
> And one “needs citation” point:
>
>    -
>
>    ETSI “public review” details for EN/TS should be backed with ETSI’s
>    own process text before you treat it as settled.
>
> If you want to sharpen this into a reply that’s hard to dodge, the killer
> move is to *separate*:
>
>    -
>
>    *Access to deliberation/decision rights* (membership/invited
>    expert/etc.)
>    -
>
>    *Ability to influence outcomes* (public issues, CGs, public drafts,
>    liaison input)
>
> That distinction stops the conversation from sliding into “open vs closed”
> as a single fuzzy blob, and forces everyone back onto concrete mechanics.
> ----------------------
> source: https://chatgpt.com/share/6992f174-3578-8009-9422-4edaa93ecaa9
> ----------------------
>
> It is unproductive to utilize word semantics for misrepresenting reality.
>
> Can I hop on a ETSI mailing list and conversate with members that have
> voting power... NO
>
> I consider myself being able to participate in this debate a perfect
> example on what makes W3C NOT "work similar".
>
>
> I'm guilty of utilizing word semantics too, but try to admit when ever I'm
> caught or caught myself in the act.
>
> I admit that nothing I have presented yet provide an as comprehensive
> self-evident framework on how things should compared to what is described
> in the references you have shared regardless of the absolute correctness of
> the reference you have shared, they currently present an actual viable
> solution I have not presented in an evident way.
>
> I hope we can agree on the facts presented in the debate up to this point.
> And I will continue working on proper presentation material.
>
> Best,
> Jori
>
>
>
> ma 16.2.2026 klo 13.24 Steffen Schwalm (Steffen.Schwalm@msg.group)
> kirjoitti:
>
> Let´s trust on NI = natural intelligence
>
>
>    - W3C requests membership of organization for formal participation in
>    standardization
>    - Comment without voting rights is basically meaningless in my opinion
>       - Means formal standardization similar to ETSI witin a closed group
>       (members with voting rights)
>       - Membership fee for organizations required
>       - ETSI requests membership of organization similar to W3C
>    - EN are on public review, sometimes depending on process also TS
>       - Formal standardization in closed group as well
>       - Membership fee for organizations required
>
>
> So basically both work similar. As documents depending on governance
> published for comments or publicly available both are open SDO - especially
> since every organization can become member
>
> In case of individuals CEN-CENELEC & ISO might be better as any individual
> can be member via the National SDO and not bound to membership of an
> organization.
>
> All SDO work on consensus and controlled by an independent governance
> body. This is main difference to organizations like DIF, OIDF etc.
>
>
>
>
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 12:09
> *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.
> > >  ETSI is no legislation but SDO similar to W3C
>
> > I do not disagree with that statement on any level.
>
> I do not disagree that it is an  Standards Development Organization that
> outputs technical specifications.
>
> But there is difference I think is worth pointing out in the context of
> the debate:
>
> AI GENERATED:
>
> *W3C model (open-collaboration culture)*
>
>    -
>
>    Public mailing lists, drafts, and discussions are often readable
>    without membership.
>    -
>
>    Anyone can comment on specs.
>    -
>
>    Community Groups can be joined freely.
>    -
>
>    Formal voting requires membership, but influence can be built from
>    outside.
>
> *ETSI model (formal standards institute)*
>
>    -
>
>    Participation in technical work is primarily for *members* (companies,
>    orgs, some individuals).
>    -
>
>    Working Groups and Technical Committees are mostly restricted.
>    -
>
>    Many documents are public, but *draft discussions and decision-making
>    are not*.
>    -
>
>    Membership fees are required for active participation.
>
> So structurally:
>
> W3C = open standards laboratory
> ETSI = regulated standards legislature
>
> Both produce specs, but their governance philosophy is different. ETSI
> exists inside a compliance-driven ecosystem (EU regulation, telecom,
> conformity assessment), so it’s intentionally more controlled. W3C grew out
> of web culture, which values rough consensus and public debate.
>
> -------
> source: https://chatgpt.com/c/6992ee9d-4018-838a-80c8-15a29f9a0793
> -------
>
> ma 16.2.2026 klo 12.39 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:
>
> >  ETSI is no legislation but SDO similar to W3C
>
> I do not disagree with that statement on any level.
>
> ma 16.2.2026 klo 12.38 Steffen Schwalm (Steffen.Schwalm@msg.group)
> kirjoitti:
>
> ETSI is no legislation but SDO similar to W3C
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 11:36
> *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.
> > I reference to the standards determining QTSP issuing certificates in
> Europe - so technical requirements, not law. Any discussion should go
> alongside those standards to meet eiDAS
>
>
> Please quote me next time 😀:
>
> >  But you keep throwing me legislation articles or technical
> specification sections
>
> ma 16.2.2026 klo 12.34 Steffen Schwalm (Steffen.Schwalm@msg.group)
> kirjoitti:
>
> Jori
>
> I reference to the standards determining QTSP issuing certificates in
> Europe - so technical requirements, not law. Any discussion should go
> alongside those standards to meet eiDAS
>
> Best
> Steffen
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 11:32
> *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 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*
>
>