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

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 ETSI EN 319 411-1
>
>
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 10:55
> *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 are right the definition of  QTSP in  ETSI EN 319 401 #sdction 7
> and ETSI EN 319 411-1 does not have access. You are right what I said was
> wrong. Any individual with a capability to the very exact same physical
> hardware the QTSP uses has write access to everything.
>
> ma 16.2.2026 klo 11.52 Steffen Schwalm (Steffen.Schwalm@msg.group)
> kirjoitti:
>
> The QTSP has no write access to everything, sorry. See ETSI EN 319 401
> #sdction 7 and ETSI EN 319 411-1
>
>
> ------------------------------
> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
> *Gesendet:* Montag, 16. Februar 2026 10:50
> *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.
> The key thing here is the QTSP environment has write access to everything
> that is supposed to be used as auditing material.
>
> This is an invariant you cannot deny, they would not be able to execute
> any operations if they could not execute all operations any similar
> hardware is capable of.
>
> ma 16.2.2026 klo 11.48 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:
>
> Model used in the following two reports ChatGPT 5.2 Extended Thinking  +
> Web Search.
> Full ChatGPT conversationcincluding messages prior to the two reports:
> https://chatgpt.com/share/69921d1f-c49c-8009-8df6-43267f8f818b
>
> --------------------------------------------------------------------------------------------------
>
> Below is a threat model you can paste into the thread. It’s written to
> stay *neutral* and to cite *EU-recognized legal text + referenced
> standards* (i.e., the stuff that actually matters “in the eyes of EU
> legislation”).
> ------------------------------
> Threat model: malicious (Q)TSP / insider in remote QES (remote QSCD /
> server signing) Scope
>
> We model a *Qualified Electronic Signature (QES)* created using a *remote
> Qualified Signature Creation Device (remote QSCD)* operated by a *
> Qualified Trust Service Provider ((Q)TSP/QTSP)*, where signing is
> triggered via a web portal / remote API and protected (in theory) by strong
> user authentication and *Signature Activation Data (SAD)*. Remote signing
> is explicitly contemplated by the eIDAS framework provided it achieves an
> equivalent security level and keeps signing “under the sole control of the
> signatory.”
> Security property the framework is trying to guarantee
>
> eIDAS ties legitimacy of advanced/qualified signing to a “sole control”
> concept:
>
>    -
>
>    Advanced signature creation data must be usable by the signatory *under
>    their sole control* (high confidence).
>    -
>
>    QSCD requirements include that signature-creation data can be *reliably
>    protected against use by others*.
>    Remote signing is allowed *if* those properties are preserved by the
>    remote QSCD + procedures.
>
> Assets
>
>    1.
>
>    *Signature-creation data* (private key material, typically
>    non-exportable inside the QSCD/HSM)
>    2.
>
>    *SAD / activation evidence* used to authorize each signing operation
>    (what proves “the user meant it”)
>    3.
>
>    *Audit logs / event history* (portal logs, signing records,
>    timestamps, etc.)
>    4.
>
>    *Qualified certificate + validation material* (public key, chain,
>    revocation status, trust anchors)
>
> Trust boundaries (who must be trusted, vs what can be verified)
>
>    -
>
>    A relying party can cryptographically verify “this signature matches
>    this certificate.”
>    -
>
>    But in remote signing, the relying party generally *cannot
>    cryptographically verify* whether *SAD was genuinely user-controlled* vs.
>    manufactured/abused inside the QTSP boundary; that becomes an
>    *assurance/compliance* question.
>    This is exactly why the framework leans heavily on certification +
>    supervision + liability controls.
>
> ------------------------------
> Adversary
>
> *Malicious QTSP*, or an insider / compromised operator inside the QTSP
> environment, with the ability to:
>
>    -
>
>    Run or modify the signing portal / authorization service,
>    -
>
>    Call the signing interface that the remote QSCD/HSM exposes,
>    -
>
>    Access or rewrite internal logs,
>    -
>
>    Potentially issue/replace certificates (depending on how roles are
>    deployed in that QTSP).
>
> This is the “evil root operator” model—strong, but realistic to analyze
> because the whole remote model concentrates power.
> ------------------------------
> Attack A: “Sign without the human” (unauthorized use of the signing key)
>
> *Goal:* produce a perfectly valid QES over arbitrary data *without the
> signatory’s consent*, by causing the remote QSCD to sign.
>
> *Mechanism (high-level):*
>
>    1.
>
>    The QTSP (or attacker inside it) submits signing requests to the
>    remote QSCD/HSM interface.
>    2.
>
>    The only intended “hard stop” is that the QSCD should require *SAD* (and
>    whatever authentication ceremony produces it) for each signing operation.
>    Remote signing standards explicitly define SAD-style activation.
>    3.
>
>    If the attacker can *bypass* SAD enforcement *or* can *mint/obtain SAD* without
>    the user (because the SAD issuance/validation is within the same
>    compromised administrative domain), they can generate signatures that are:
>    -
>
>       cryptographically valid,
>       -
>
>       certificate-valid,
>       -
>
>       and externally indistinguishable from legitimate signatures.
>
> *Why this matters legally/assurance-wise:*
> This attack—if possible—directly contradicts the “sole control” and
> “protected against use by others” requirements the regulation associates
> with advanced/QES and QSCDs.
>
> *What the framework uses to prevent/deter it (not “magic,” but the actual
> levers):*
>
>    -
>
>    *QSCD certification / evaluation against recognized standards.* The EU
>    has an implementing decision that lists standards for QSCD security
>    assessment (commonly referenced in practice around the CEN 419 241 family).
>    -
>
>    *Standardized activation protocols.* The EU has an implementing
>    regulation listing reference standards for remote QSCD services, including *ETSI
>    TS 119 431-1* (signature activation protocol).
>    -
>
>    *Policy/security requirements for server signing components.* ETSI TS
>    119 432 is assessed in EU interoperability contexts (CAMSS), reflecting its
>    relevance to regulated remote signing system design.
>
> *Residual risk (the key point):*
> Even if those standards are followed, the remote model still creates a
> structural dependency: outsiders verify the signature, but must *trust* that
> the QTSP-operated activation path really enforced user control. That’s
> fundamentally harder to make *end-to-end cryptographically
> self-authenticating* than a signer-controlled device model.
> ------------------------------
> Attack B: “Rewrite history” (log fabrication / selective disclosure)
>
> *Goal:* make a false narrative of what happened (or didn’t happen) appear
> consistent and “audit-ready.”
>
> *Mechanism:*
>
>    1.
>
>    Attacker generates unauthorized signatures (Attack A) and/or
>    selectively signs only some events.
>    2.
>
>    Attacker rewrites portal logs / signing transaction records to match
>    the story they want (or to remove evidence).
>    3.
>
>    If challenged, they present internally consistent records.
>
> *Why detection is hard:*
> Because the *signature* validates, disputes collapse onto *process
> evidence* (“was SAD actually user-controlled at that moment?”), which is
> largely inside the QTSP boundary.
>
> *What the framework does about it (again: governance tools):*
>
>    -
>
>    Mandatory breach notification obligations (including within *24 hours* after
>    awareness for significant impact), which is intended to force disclosure
>    when integrity is compromised.
>    -
>
>    Recurring audits (at least *every 24 months*) by a conformity
>    assessment body, plus supervisory powers to intervene.
>
> These controls are meaningful, but they are not the same thing as a
> cryptographic impossibility of log rewriting.
> ------------------------------
> Attack C: “Validation-material control plane abuse” (trust/verification
> material)
>
> This is about where verifiers get the data needed to validate signatures,
> and who can manipulate that ecosystem.
> Where verification material is hosted in today’s eIDAS model
>
>    -
>
>    *Qualified certificates* (public key + identity bindings) are issued
>    by a CA/QTSP and are typically carried with the signature container and/or
>    retrievable via CA infrastructure.
>    -
>
>    *Revocation status* is provided via CA endpoints (CRLs/OCSP), also
>    within the trust-service ecosystem.
>    -
>
>    *Trust anchors for “qualified status”* are distributed via *Trusted
>    Lists (TL)* per Member State and the EU “List of the Lists” (LOTL)
>    mechanism, standardized for machine processing.
>
> So: the crypto verification is “mathematical,” but the *authorization of
> who counts as qualified* is a directory/governance control plane.
> ------------------------------
> Why this threat model is relevant to the “trusted software list” debate
>
> Even if the wallet ecosystem tries to protect users via certified wallet
> software, the EUDI ARF simultaneously contains privacy rules that avoid
> revealing wallet-unit attestation to relying parties (e.g., WUA only shown
> to PID/attestation providers during issuance, not to relying parties).
> So relying parties often won’t get a strong software-attestation handle
> anyway—and your core concern stays: remote signing safety depends on what
> happens in a domain the user and verifier can’t directly measure.
> ------------------------------
> Minimal, standards-aligned statement of the concern
>
> Remote QES can be compliant *on paper* because it is anchored in *certification
> + supervision + liability*, but a “malicious QTSP” threat model
> highlights a structural limit: *a valid signature cannot, by itself,
> prove the signatory’s activation/intent if the activation ceremony is
> administered inside the same domain that can sign and rewrite logs*. The
> framework mitigates via audited controls and standardized activation
> protocols, not by giving verifiers an end-to-end cryptographic proof of
> user-controlled activation.
> ------------------------------
>
> If you want to sharpen the knife further (without becoming unfair), the
> next move is to phrase a single crisp question back to Steffen/Nikos:
>
> *“Which specific evaluated boundary guarantees that SAD cannot be
> generated or replayed by the QTSP itself, and what is the verifiable
> artifact a relying party (or the user) can retain to prove that boundary
> was enforced for a given signature?”*
> That question forces the discussion onto *mechanisms and artifacts*, not
> vibes.
>
> ------------------------------------------------------------------------------------------------------------
> Report: Why “low-assurance” client allowlists + remote signing can
> undercut eIDAS/EUDI’s stated goals 1) Scope and claim being tested
>
> This report examines a specific tension in the EU’s trust stack:
>
>    -
>
>    *Policy goal (high level):* legally reliable, cross-border digital
>    trust that is *user-centric* and *secure*.
>    -
>
>    *Implementation pattern (practical):* (a) *trusted software /
>    certification / allowlists* and (b) *remote signing via QTSP-operated
>    infrastructure*, defended as “protecting the user”.
>
> The core question: * If the system’s threat model includes client
> impersonation and insider misuse, do “lists + audits + certification”
> provide the kind of assurance the legislation is trying to achieve—or do
> they create a dangerous illusion of assurance?*
> ------------------------------
> 2) What eIDAS actually demands (the invariants that matter) A. “Sole
> control” is not optional
>
> eIDAS defines an *advanced electronic signature* as one created using
> signature-creation data that the signatory can use *“under his sole
> control.”*
>
> Likewise, the QSCD requirements in *Annex II* include that
> signature-creation data *can be reliably protected by the legitimate
> signatory against use by others.*
>
> These are not “nice-to-haves”; they’re the *mechanical* trust claims that
> justify legal effect.
> B. Remote signing is explicitly contemplated—*but it must still satisfy
> “sole control”*
>
> The consolidated eIDAS text explicitly talks about *remote* qualified
> signature creation and the need to ensure the signatory remains in sole
> control, even when things happen “remotely.”
>
> That matters because it sets up the exact failure mode you’re arguing
> about:
>
> Remote signing is * permitted*, but it creates a sharp question: *how
> does anyone (including the user) validate “sole control” in a way that
> isn’t just “trust the provider + the auditors”?*
>
> ------------------------------
> 3) What the EU stack uses as assurance mechanisms (and where “low
> assurance” sneaks in) A. Governance assurance: supervision, incident
> notification, periodic assessment
>
> The model relies heavily on:
>
>    -
>
>    *Security obligations on QTSPs* (risk management, incident handling,
>    etc.), and *notification duties* for breaches.
>    -
>
>    *Conformity assessment* and “qualified” status backed by standards and
>    auditing.
>
> This is real assurance—*but it’s organizational / procedural assurance*.
> B. Standards acknowledgement: the system is “standards-based,” including
> remote-signing standards
>
> The Commission’s implementing rules enumerate technical standards that are
> recognized for qualified services, including standards that cover *remote
> QSCD / remote signature creation device management services* and related
> protocols.
>
> This is key to your argument: *the EU doesn’t merely tolerate remote
> signing; it standardizes around it.*
> C. Wallet privacy design (relevant because it shows the user is treated as
> an active trust boundary)
>
> The EUDI ARF high-level requirements include mechanisms to reduce
> correlation—e.g., per-relying-party presentation behaviors for
> PIDs/attestations/WUAs.
>
> This supports your framing that the *user is part of the verification
> perimeter*, not just a passive subject.
> ------------------------------
> 4) Threat model focused on the disputed risk Assets
>
>    1.
>
>    *A legally-effective signature* (QES / AdES) tied to an identity and a
>    transaction.
>    2.
>
>    *Evidence of user intent/consent* for that signature event.
>    3.
>
>    *The long-term verifiability story* (what can be shown later to
>    auditors/courts/users).
>
> Adversaries (the uncomfortable but necessary ones)
>
>    -
>
>    *Client impersonators* (software that looks like an “approved” client).
>    -
>
>    *Compromised wallet device / malware* (steals session context, coerces
>    signing).
>    -
>
>    *QTSP insider / compromised operator plane* (can trigger signing
>    operations using legitimate infrastructure).
>    -
>
>    *Governance failure* (slow detection, incomplete logs, audit gaps).
>
> Attack class you’re pointing at (high level, non-operational)
>
> Remote signing can fail *without key extraction*:
>
>    -
>
>    The private key stays inside certified hardware, *but the system still
>    performs signatures whenever the service’s software path authorizes it*
>    .
>    -
>
>    If an insider or compromise can cause the service to authorize “one
>    more signing event,” you get a signature that is *cryptographically
>    valid* and *legally meaningful*—even if the user never intended it.
>
> That is precisely the kind of failure that “you can’t trust the client”
> warns about, except here the “client” might be:
>
>    -
>
>    the wallet runtime asking for a remote signature,
>    -
>
>    or the internal service component asserting that the user authorized
>    the signing.
>
> ------------------------------
> 5) The contradiction: where “lists + audits” don’t meet the legislative
> *goal-shaped* security claim
>
> Here’s the clean logical separation:
> (1) The legislation’s invariant is *cryptographic*: “sole control”
>
> eIDAS defines “sole control” as part of what makes an advanced signature
> advanced.
> Annex II requires protection against use by others.
>
> Those read like *technical* guarantees, not merely “we investigated and
> think it’s fine.”
> (2) The remote-signing reality makes “sole control” mostly
> *non-verifiable* to external parties
>
> A relying party can verify a signature mathematically.
> But it generally *cannot verify* (from the signature alone) that:
>
>    -
>
>    the user saw the document,
>    -
>
>    the user approved *that* exact payload,
>    -
>
>    the signature activation event wasn’t coerced or fabricated upstream.
>
> <
>
>