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

And my point still stands about the laws requirements not being a hard stop
for logical behaviour, a specification is not a hard stop for behaviour
logically possible either. If the text does not address physical reality
correctly then the specification based on false realities.

ma 16.2.2026 klo 10.48 Amir Hameed (amsaalegal@gmail.com) kirjoitti:

> Hi Steve,
>
> Thanks for the detailed breakdown. I want to clarify that my mention of
> Sirraya One was purely illustrative — to explain the mechanism of proving
> DID ownership via challenge-response and registry linkage. It was never
> intended as a product pitch, nor does it require anyone to vet or adopt our
> implementation. The goal was to show that simple, cryptographically
> grounded approaches can work in practice, even at scale.
>
> I also want to emphasize a broader point: the world is not limited to EU,
> US, or UN-centric approaches. India alone represents billions of internet
> users in highly diverse conditions, and our implementations are tested
> under real-world constraints — high scale, fragmented connectivity, and
> heterogeneous devices. Lessons from these environments often differ from
> theoretical or lab-driven models.
>
> Finally, while trade cases like the ones you describe are more complex,
> the fundamental principle holds: trust can be embedded in the cryptographic
> links between DID, VCs, and registries. Multi-party verification is an
> extension of the same mechanism, not a separate conceptual challenge.
>
> I’m happy to continue discussing use cases and mechanisms, but my
> intention here is to focus on practical, field-tested approaches, not
> organizational validation or alignment.
>
>
> Regards,
>
> Amir
>
>
> On Mon, 16 Feb 2026 at 2:13 PM, Steffen Schwalm <Steffen.Schwalm@msg.group>
> wrote:
>
>> CEN EN 419 241 is no law but the technical specification according to
>> which the QSCD is build and implemented
>>
>> Means you still lack of valid explanation alongside the standard how your
>> proposed attack should work
>>
>> Best
>> Steffen
>>
>>
>> ------------------------------
>> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
>> *Gesendet:* Montag, 16. Februar 2026 09:38
>> *Bis:* Steffen Schwalm <Steffen.Schwalm@msg.group>
>>
>> *Cc:* 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.
>> Law's requirements ARE NOT A LOGICAL STOP OF BEHAVIOUR.
>>
>> LAW IS NOT A COMPONENT FOR TECHNICAL THREATH MODELLING.
>>
>> But I think I have shown enough. Anyone can do with it what they want.
>> Next I will work on a solution that actually fulfills the goals the EU
>> Legislation has👍
>>
>> ma 16.2.2026 klo 10.35 Steffen Schwalm (Steffen.Schwalm@msg.group)
>> kirjoitti:
>>
>> They can`t extract the keys without notice. See CEN EN 419241
>> ------------------------------
>> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
>> *Gesendet:* Montag, 16. Februar 2026 09:30
>> *An:* Steffen Schwalm <Steffen.Schwalm@msg.group>
>> *Cc:* 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.
>> They can's extract the keys used for signing material. There is the
>> signature only upon certain data presented. But that is software layer.
>> They can use other software to interact with the hardware.
>>
>> ma 16.2.2026 klo 10.27 Jori Lehtinen (lehtinenjori03@gmail.com)
>> kirjoitti:
>>
>> I actually spent last night reading about it, how it works and what
>> components there are there is nothing stopping the (Q)TSP from using the
>> hardware in their custody...
>>
>> ma 16.2.2026 klo 10.26 Steffen Schwalm (Steffen.Schwalm@msg.group)
>> kirjoitti:
>>
>> Jori,
>>
>> May you please alongside the CEN EN 419 241 how EUDI "llowing a remote
>> signing flow that allows a potentially malicious actor within the (Q)TSP
>> use the privateKey representing you (not extract... use) to sign and
>> fabricate any history they want that would remain verifiable in court,
>> while making the local QSCD (Qualified Signature Creation Device) require a
>> weird certificate"
>>
>> The QSCD contains verifiable hard- and software bound not only to keys
>> you control.
>>
>> It would make it much easier to discuss if you could show where exactly
>> in QSCD you see the issue.
>>
>> Thx
>>
>>
>> ------------------------------
>> *Von:* Jori Lehtinen <lehtinenjori03@gmail.com>
>> *Gesendet:* Montag, 16. Februar 2026 09:22
>> *Bis:* NIKOLAOS FOTIOY <fotiou@aueb.gr>
>> *Cc:* Joe Andrieu <joe@legreq.com>; 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.
>> Nikos,
>>
>> Does the EUDI protect the user by allowing a remote signing flow that
>> allows a potentially malicious actor within the (Q)TSP use the privateKey
>> representing you (not extract... use) to sign and fabricate any history
>> they want that would remain verifiable in court, while making the local
>> QSCD (Qualified Signature Creation Device) require a weird
>> certificate instead of verifiable software behaviour with information only
>> bound to a item you control by default that probably won't have a
>> convinient API widely available (HUGE ASSUMPTION ON THE AVAILABILITY)
>> resulting in remote signing being the default, and what is worse is that
>> you as an individual cannot contribute to the durability of items required
>> to verify your claims.
>>
>>
>> --------------------------------------------------------------------------------------------------
>>
>> Model GPT 5.2 Extended Thinking + Web Search
>> AI Refined answer below and source here:
>> https://chatgpt.com/share/6992d17b-8af4-8009-abad-c4b6d66e5909
>> <https://chatgpt.com/share/6992d17b-8af4-8009-abad-c4b6d66e5909>
>>
>> What you are also missing is that you as a user are in the role of a
>> verifier.
>>
>> Help me strenghten this response with references to the EU legislation: >
>> > 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 ---> Nikos, Does the EUDI
>> protect the user by allowing a remote signing flow that allows a
>> potentially malicious actor within the (Q)TSP use the privateKey
>> representing you (not extract... use) to sign and fabricate any history
>> they want that would remain verifiable in court, while making the local
>> QSCD (Qualified Signature Creation Device) require a weird certificate
>> instead of verifiable software behaviour with information only bound to a
>> item you control by default that probably won't have a convinient API
>> widely available (HUGE ASSUMPTION ON THE AVAILABILITY) resulting in remote
>> signing being the default, and what is worse is that you as an individual
>> cannot contribute to the durability of items required to verify your
>> claims. What you are also missing is that you as a user are in the role of
>> a verifier. Regards, Jori
>> Stopped thinking
>> To elaborate. What you are also missing is that in systems that respect
>> the you the user also give you the role of a verifier when there are things
>> you need to trust.
>> Thought for 2m 25s
>>
>> Here’s a tighter, more “EU-text-backed” version you can send. I kept your
>> core argument and anchored the contentious parts to the actual *eIDAS /
>> eIDAS2* wording, plus the EUDI ARF requirement you cited.
>> ------------------------------
>>
>> Nikos,
>>
>> I agree with you on the *goal* (protecting the user), but I think you’re
>> mixing two different security questions:
>>
>>    1.
>>
>>    *Protecting the user from malicious software / phishing / spoofed
>>    wallets*
>>    2.
>>
>>    *Protecting other parties (and the user-as-a-party) from claims that
>>    are “legally true” even if the signing environment was compromised or
>>    misused*
>>
>> The European Digital Identity Wallet framework is explicitly
>> user-centric: it is meant to provide secure access to services “*while
>> having full control over their data*,” and the wallet must let the user
>> request/obtain/store/present data “*under the sole control of the user*.”
>> It also bakes in anti-tracking requirements (no transaction
>> tracking/linking/correlation unless explicitly authorised by the user).
>>
>> So yes: *lists/certification are a reasonable tool for user protection* in
>> that model (the EU even mandates publication of a list of *certified* EUDI
>> Wallets).
>> And the ARF goes further in privacy terms: it says a Wallet Unit must
>> release a WUA only to a PID Provider or Attestation Provider—*not to a
>> Relying Party or any other entity*.
>>
>> But none of that answers the *other* question: *what protects against
>> misuse of signing capability—especially in remote signing models—when the
>> verifier (and the user) cannot independently validate how the key was used?*
>>
>> eIDAS is extremely clear about the invariant it wants: advanced
>> signatures must be created using signature-creation data that the signatory
>> can use “*under his sole control*.”
>> And Annex II requires that signature-creation data “*can be reliably
>> protected by the legitimate signatory against use by others*.”
>>
>> Now the important bit: the amended eIDAS text explicitly contemplates
>> *remote* qualified signature creation devices and services. It states
>> that generating/managing signature-creation data (and even duplicating it
>> for backup) is carried out *on behalf of the signatory* and *by a
>> qualified trust service provider* providing a qualified service for
>> managing a *remote* QSCD.
>> That is a legal/assurance model that fundamentally depends on the QTSP’s
>> controls being correct—because neither the relying party nor the signatory
>> can typically *cryptographically* verify the QTSP’s internal enforcement
>> in the way they can verify a signature.
>>
>> Yes, the regulation piles on supervision (audits at least every 24
>> months, supervisory powers, breach notification “*no later than 24 hours*,”
>> etc.).
>> But that’s *compliance assurance*, not *cryptographic verifiability*.
>>
>> Finally, the part I think you’re missing:
>>
>> *In systems that “respect the user,” the user is not only
>> protected—they’re also put in the role of a verifier whenever something
>> must be trusted.* The eIDAS2 wallet text actually reflects that: Member
>> States must provide validation mechanisms that allow *users* to verify
>> the authenticity/validity of relying parties, and the wallet must provide
>> logs/dashboards so the user can see who they interacted with.
>>
>> So when we talk about “trusted software lists,” we should be precise:
>> they can help protect the *user* from bad clients—but they do not
>> magically make the client “trustworthy,” and they do not resolve the
>> verifier/user-verifier problem in remote signing trust models.
>>
>> Regards,
>> Jori
>>
>> ------------------------------------------------------------------------------------------------------
>>
>> There is no end-to-end verifiable way ensure the integrity of a remote
>> signing service. Audits don't help when they can write the history.
>>
>> Upon reading the AI refined answer. I think it is obvious the *current
>> implementations break EU LAW!!*
>>
>> The you cannot trust the client principle applies here!
>>
>> The individuals device is there server relying on trusted behaviour from
>> a "client" for wich there is no technically valid way to ever truly
>> guarantee, as demonstrated by the CURL discussion.
>>
>> Regards,
>> Jori
>>
>>
>> ma 16.2.2026 klo 9.42 NIKOLAOS FOTIOY (fotiou@aueb.gr) kirjoitti:
>>
>>
>> >
>> > 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
>>
>>