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

Steffen,


I agree it is important to distinguish between the mathematical anchor and
the legal persona.

Where I differ slightly is in the conclusion that Identity and Signature
are “missing” from the model.

My position is that they are not separate primitives, but emergent
properties of the VC layer.

To make this concrete, consider the lifecycle of a digital citizen:


1. The Sovereign Baseline (SSI)

An individual generates a key pair locally and derives a DID.

This establishes a cryptographic control point — a permissionless,
sovereign anchor.

At this stage, it proves key control, not legal status.


2. Recognition (KYC / Registration)

A government or authority performs KYC according to its jurisdictional
rules.

Crucially, it does not need to replace or “take custody” of the SSI anchor.

Instead, it attests to the existing DID.


3. Identity (VC Issuance)

The Verifiable Credential becomes the legally meaningful artifact.

It contains:

• Claims (the identity attributes)

• Issuer binding (the authority)

• Cryptographic proof (the signature)


In other words:

Identity = Claims inside the VC

Signature = Proof attached to the VC


4. Participation

Because the subject retains control of the private key, they are not merely
a database entry but an active cryptographic participant, able to present
proofs across contexts.


From this perspective:

• DID → Sovereign anchor (identifier & control)

• VC → Identity + Signature (attested claims & proof)

• Registry → Trust & status resolution


Identity and signature are therefore payload and proof within the VC, not
standalone architectural blocks.

If we accept that these primitives can carry varying assurance levels —
from lightweight interactions to high-assurance frameworks such as

eIDAS

— then the model remains:

• Technically minimalist

• Assurance-flexible

• Regulatory-compatible


I fully agree that additional layers may be required for specific
governance, liability, or sectoral use cases.

I am just saying:

The primitives are not merely promising — they are structurally sufficient.


Everything else becomes a matter of:

Policy mapping

Assurance profiling

Jurisdictional alignment


Does this answer your points. I believe we can advance collectively.


Regards,

Amir


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

> 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:
>
> 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 E
>
>