- From: Steffen Schwalm <Steffen.Schwalm@msg.group>
- Date: Mon, 16 Feb 2026 14:22:33 +0000
- To: Amir Hameed <amsaalegal@gmail.com>
- 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>
- Message-ID: <AM8P191MB12999E1F8A90399708E1FE85FA6CA@AM8P191MB1299.EURP191.PROD.OUTLOOK.COM>
Amir,
DID = Identifier no Identity - exactly this is missed, that why DID need to be bound to identity
*
A certificate which comes on top of your VC is not covered with DID - VC - Registry. As the Signature separate from the VC
"…instead of simply binding existing legal and assurance requirements onto the same primitives." which is impossible as described with DID - VC- Registry only
"The model is therefore legally agnostic but compliance-adaptable." nope because Identity & signature missed. A key pair (DID is basically nothing else) does not help.
So I guess we need to be bit more precise sp very roughly DID - Identity-VC-Signature-registry
Might work
________________________________
Von: Amir Hameed <amsaalegal@gmail.com>
Gesendet: Montag, 16. Februar 2026 15:06
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.
Steffen,
Compliance is a configuration choice, not an architectural primitive.
All the items you listed naturally map onto the same three building blocks:
• DID → Identifier / control / resolution
• VC → Attestation / claims / signature
• Registry → Trust anchor / status / discovery
Questions like:
– Which DID method?
– Which VC encoding (JWT, JSON-LD, JAdES, SD-JWT)?
– Which trust framework (eIDAS, ETSI, national PKI)?
…are selection decisions, not indicators that a new structural layer is required.
When I argue against “additional layers,” I’m referring to the recurring tendency to introduce:
• new governance abstractions
• new mediation workflows
• new graph models
…instead of simply binding existing legal and assurance requirements onto the same primitives.
For example:
• Under eIDAS → choose QSeal/QES-compatible signatures
• Under another jurisdiction → choose an equivalent assurance mechanism
Different labels, identical trust logic.
The underlying system remains:
Identifier → Attestation → Resolution
Everything else becomes:
Policy mapping / assurance profile / encoding preference
The model is therefore legally agnostic but compliance-adaptable.
We should be careful not to conflate:
“Choosing a standard”
with
“Needing more complexity.”
Selecting JAdES instead of another signature format does not alter the architecture any more than choosing TLS 1.3 alters the concept of encryption.
If we agree on the primitives, then standards function as interoperability and assurance profiles, not conceptual forks.
More importantly, perhaps the real opportunity here is alignment rather than positioning.
Most of us are ultimately optimizing for the same outcomes:
• Sovereignty
• Privacy
• Interoperability
• Practical deployability
• Human-centric access to digital systems
The tension often arises not from disagreement on goals, but from different risk models:
• Regulatory risk
• Deployment risk
• Adoption risk
• Liability framing
If we explicitly separate:
Architecture → Policy → Assurance → Jurisdiction
…we may find more common ground and reduce duplicated effort.
A balanced model should allow:
• Technical minimalism
• Regulatory compatibility
• Evolution without fragmentation
That seems like a shared interest across ecosystems.
Regards,
Amir
On Mon, 16 Feb 2026 at 7:16 PM, Steffen Schwalm <Steffen.Schwalm@msg.group> wrote:
Amir,
When I needs legally compliant evidence for origin of data in interoperable way.
*
Which DID method of the 238 registered do I use?
*
Which trust registry standardized where, approved by whom?
*
How is the legal entity identified which is originator of certain data?
*
How are signing key created, securely stored and managed?
*
How is VC created based on which format and signed with which signature in which format standardized where?
What I need for proof of origin: I need the one who signed the VC e.g. using a qseal/QES for the VC. DID+VC+Registry could be sufficient if (by very rough example of eIDAS)
*
DID method defined and standardized somewhere (e.g .CEN TS on Functional and interoperability requirement of DID" based on W3C DID SPec)
*
DID of trusted issuer stored in Trust Registry which is standardized somewhere (e.g. Trust Model EBSI even if EBSI is not in any formal SDO currently)
*
VC created using defined standard and data model (e.g. W3C VCDM executed as JWT/SD-JWT)
*
VC signed with QSeal acc. ETSI EN 319 411-1 as JAdES
Means I guess the answer if "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.." is true depends on the applicable application area and its legal and technical framework. We can´t say it´s true in any case.
Best
Steffen
________________________________
Von: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>
Gesendet: Montag, 16. Februar 2026 14:37
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; public-credentials <public-credentials@w3.org<mailto: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.
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<mailto:amsaalegal@gmail.com>>
Gesendet: Montag, 16. Februar 2026 14:31
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:filip26@gmail.com>>
Gesendet: Montag, 16. Februar 2026 14:19
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>; Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:filip26@gmail.com>>
Gesendet: Montag, 16. Februar 2026 13:59
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Jori Lehtinen <lehtinenjori03@gmail.com<mailto:lehtinenjori03@gmail.com>>; Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 12:53
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 12:09
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto: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<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 11:36
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 11:32
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 11:08
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 10:55
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto:lehtinenjori03@gmail.com>>
Gesendet: Montag, 16. Februar 2026 10:50
Bis: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>>; NIKOLAOS FOTIOY <fotiou@aueb.gr<mailto:fotiou@aueb.gr>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; Filip Kolarik <filip26@gmail.com<mailto:filip26@gmail.com>>; public-credentials <public-credentials@w3.org<mailto: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<mailto: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
Received on Monday, 16 February 2026 14:22:44 UTC