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

♥️

Jori reagoi Gmailissa
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

ma 16. helmik. 2026 klo 16.07 Amir Hameed <amsaalegal@gmail.com> kirjoitti:

> 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>
>> *Gesendet:* Montag, 16. Februar 2026 14:37
>>
>> *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 ,
>>
>> 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>
>>
>>