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

Steffen,

As we move forward with the assumptions discussed, it may help to briefly
clarify two terms that seem to be operating implicitly in the thread.


1️⃣ “Regulated” vs Trust Established Outside Statutory Frameworks

When we refer to “regulated”, are we aligning on something like:

• Systems subject to statutory/legal frameworks (eIDAS, national trust
laws, etc.)
• Defined liability and assurance obligations
• Conformity assessment / supervisory structures

In contrast, would it be reasonable to describe the other category as:

“Environments where trust is established through technical mechanisms
rather than statutory frameworks”

This distinction may help separate:

Legal recognition / liability constructs
from
Cryptographic / protocol-level trust mechanisms

…without implying differences in architectural structure.


2️⃣ Physical vs Digital Resources

A second clarification concerns how we are treating resources in the model:

• Physical / legal resources
(e.g., natural persons, legal entities, official documents, hardware
devices)

• Digital resources
(e.g., identifiers, credentials, keys, registries)

Questions that seem relevant:

• Are digital identity artifacts considered representations of
physical/legal reality?
• Or autonomous digital constructs later bound to legal meaning via
attestation?

For example:

• DID → digital identifier / control anchor
• VC → digitally expressed claims
• Legal identity → jurisdictional recognition of attributes

Clarifying this boundary might help avoid conflating:

Existence of a subject
with
Recognition or attestation of attributes


Why this may be useful

Several points of friction appear to arise not from disagreement about
primitives, but from:

• Whether regulation alters architecture or overlays it
• Whether trust semantics are intrinsic or assigned
• Whether digital artifacts represent or instantiate identity constructs

A shared interpretation here may make the “details” discussion more precise.

Regards,
Amir


On Mon, 16 Feb 2026 at 8:55 PM, Jori Lehtinen <lehtinenjori03@gmail.com>
wrote:

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