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

Yes exactly!

So a VC gets issued to a DID (a mere identifier that can be used to
identify documents containing a verification method for the private
material only the controller has) with claims that fulfill the requirement
of:
-  https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910
<https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910>
(Art. 3(3))

With an issuer that fulfills the requirement of:
-  https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910
(Art. 7(a))








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

> I know but need to be bound to Identity ;-9
>
> Identity is not part of DID. An identifier is not necessarily an Identity
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 15:43
> *An:* Steffen Schwalm <Steffen.Schwalm@msg.group>
> *Cc:* Amir Hameed <amsaalegal@gmail.com>; Filip Kolarik <filip26@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.
> VC and DID can be used to present any information backed by any entity
> verifiably.
>
> For reference see:
> - https://www.w3.org/TR/did-use-cases/#publicAuthorityCredentials
> - https://www.w3.org/TR/vc-use-cases/#legal-identity
>
> ma 16. helmik. 2026 klo 16.22 Steffen Schwalm <Steffen.Schwalm@msg.group>
> kirjoitti:
>
> 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>
> *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>; 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:
>
>