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

Steffen,
>  @Joris: Where is defined that distributed system needs consensus (beside
a DLT)?
https://youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB&si=0jsDqdMYaHYZZGfb
Of course we can change the definition of a distributed system any time we
want same as we can change the law anytime we want, but for a system to be
able to technically guarantee integrity there are some physical realities
you cannot avoid. So if the legislations goals are to guarantee an
individuals legal safety, we should use the best tech available to
guarantee that goal no?
Anything can be a distributed system it is more about what invariants we
want the system to guarantee.

> Nope as the QTSP do no share federated PKI
What is the List of Lists then?

>

   - Who proves based on which standards accredited by whom and supervised
   by whom that the CRDT network works correctly?
   - That`s why we defined even for DLT security & auditing standards in
   ISO resp. CEN-CENELEC


Anyone that runs the protocol proves it. And EU law can mandate the tech.
Saying there is auditing does not prove the audits always absolutely reveal
misdemeanor. A well defined protocol on the other hand does.

> Wrong as provable via LOTL and EC may stop national list in case of
failure. Protocol in case of consensus won`t help - if whole consensus
algorithm flawed no DLT will check this and no replication will help ;-)

This is you proving all the fears we have. There is no regard for
individuals rights or safety. You only care about state and legal system
authority. (THAT IS HOW IM INTERPRETING HOW YOU PRESENT THE LAW AND DENY
TECHNICAL FACTS I CANNOT BE A JUDGE)

Regards,
Jori



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

> Exactly Nikos!
> ------------------------------
> *Von:* NIKOLAOS FOTIOY <fotiou@aueb.gr>
> *Gesendet:* Montag, 16. Februar 2026 08:39
> *An:* Joe Andrieu <joe@legreq.com>
> *Cc:* Kyle Den Hartog <kyle@pryvit.tech>; Adrian Gropper <
> agropper@healthurl.com>; Manu Sporny <msporny@digitalbazaar.com>; Steffen
> Schwalm <Steffen.Schwalm@msg.group>; 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.
>
> >
> > More dangerous is the fact that your advocacy creates a false sense of
> security, literally telling people something is secure when it is not.
> Seriously, your email here is a dangerous recommendation. For anyone
> reading, please DO NOT think that approved browser lists actually prevent
> "unapproved" browser access.
> >
> > The truism that you can't trust the client is not just a web phenomenon
> or my opinion; it's a deep cybersecurity principle. You might want to argue
> with me, but I suggest you do some research before arguing against the
> combined wisdom of 50+ years of cybersecurity experience.
> >
> > Seriously, search for "cybersecurity can't trust the client" and you'll
> see a wealth of diverse opinions explaining in various terms why you
> actually can't trust the client in cyberspace.
> >
> >
>
> All boils down to who you want to protect. EUDI tries to protect the user.
> Lists of trusted software is fundamental when you are trying to protect the
> user.  Government officials are recommended to use the Signal App and not
> any app claiming to use the OTR protocol. The Tor project recommends users
> to use the Tor browser and explicitly states "Using Tor with other browsers
> is dangerous and not recommended”.
>
> The EUDI DOES NOT try to protect the verifiers. Verifiers do not learn
> which wallet the user is using and the EUDI ARF explicitly prohibits this
> (see in Annex 2 of ARF "A Wallet Unit SHALL present a WUA only to a PID
> Provider or Attestation Provider, as part of the issuance process of a PID
> or a key-bound attestation, and not to a Relying Party or any other
> entity.”)
>
> Best,
> Nikos
>
>
>