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

Steffen,

I will try to properly go trough the legal texts you presented, and try to
demonstrate my solution more from your perspective.

I pasted our arguments in to AI and asked for a neutral analysis, that I
think is worth reading.

-----------------------------------

Here’s a neutral, text-grounded review *taking Jori’s proposal at face
value*: that the *anchor* is the physical ID (chip), and that identity
proofing, key custody, and user authentication are handled locally by a
standardized wallet API (invoked by apps), with a public registry/log for
verifiers.
What each side is actually claimingJori’s model (as described in the thread
you pasted)

Jori’s core claim is *not* “trust without governance,” but “trust with
*minimized* governance”: legislation/courts should define *what must be
verifiable*, while the system should make those facts verifiable by anyone
via cryptography.

In concrete terms, Jori proposes:

   -

   *Identity proofing / binding*: done by the wallet locally using the
*physical
   ID* (e.g., MRZ + NFC chip read), i.e., proof derived from
   government-issued document cryptography rather than from a separate
   certified service provider.
   -

   *Secure keys / non-exfiltration*: the signing key should be *hosted only
   within the physical identity instrument* (or a comparable
   tamper-resistant element), so proofs can be made without exporting the key.
   -

   *User authentication*: “basic frontend stuff” (PIN/biometrics) gating
   use of the wallet API on-device.
   -

   *Verifier trust*: verifiers check signatures and retrieve necessary
   verification material (public keys, status/events) from a *registry /
   log* (in his later messages: a “global legal trust blockchain” or
   jurisdiction-specific registry).
   -

   *Liability / redress*: courts set admissibility requirements; parties
   keep signed artifacts for their own legal safety; revocation events are
   logged (“kill it”) with timestamps.

This is a coherent *cryptographic* architecture *if* the physical ID really
can play the role he assigns it.
Steffen’s model (as argued in the thread)

Steffen’s claim is that for high-assurance / legally binding outcomes, you
need an assurance regime: certified processes, certified environments, and
supervised providers—because (in his view) *legal trust* is not only
“signature verifies,” but also “the whole pipeline was operated under
validated conditions.”

He ties that to the EU approach:

   -

   wallet ecosystem rules + certification; and
   -

   registries/trust lists for discoverability and policy control; and
   -

   long-term validation / preservation expectations.

What eIDAS/EUDI objectively does (relevant to this dispute)

From the Regulation text:

   -

   The wallet *app components must be open-source licensed* (with a limited
   carve-out for some non-device components).
   -

   Wallet use is *voluntary* and the framework is intended to support
   privacy measures like unlinkability and limiting tracking/observability by
   wallet providers.
   -

   Relying parties who want to rely on wallets for digital interactions
   must *register*, disclose what they intend to request, and Member States
   must publish that info in a signed/sealed form suitable for automation.
   -

   That registration is explicitly described as intended to be *cost-effective,
   proportionate*, and *not* a pre-authorization process (in the recitals).
   -

   The Commission adopted implementing regulations in late 2024 that
   specify wallet integrity/core functions, PID/EAA rules,
   protocols/interfaces, and notification mechanics.

Separately, the EU “trust list / LOTL” idea Steffen points to is real: ETSI
describes a Commission-published “List Of Trusted Lists” that helps
locate/authenticate national trusted lists.

So: *Steffen is right* that the EU system is built around both crypto *and*
governance registries. *Jori is right* that registries are governance
artifacts, not cryptographic proof of runtime behavior.
Does Jori’s “physical ID anchor + wallet API” address the hard problems?

If we assume the physical ID and wallet environment can do what Jori
asserts, then yes—*conceptually* he has an answer for each. The remaining
question becomes “is the assumption valid and deployable at scale?”
1) Identity proofing / binding a real person to a key

*Jori’s answer:* bind to the physical ID by using chip-based verification
locally (MRZ + NFC), then sign with a key tied to that instrument.

*Neutral assessment:* This addresses binding *to the extent* that:

   -

   the physical ID’s chip cryptography is strong and designed for this kind
   of use; and
   -

   the wallet can reliably validate document authenticity (and status)
   using jurisdiction-backed data.

eIDAS also explicitly talks about assurance level “high” and identity
proofing as part of the wallet ecosystem.
So the disagreement isn’t “do we need identity proofing,” it’s “do we
centralize it in certified providers/processes vs. push it down into device
+ document cryptography.”
2) Secure key generation and non-exfiltration

*Jori’s answer:* keys are “hosted only within the signer’s physical
identity instrument,” so exfiltration is blocked by hardware design.

*Neutral assessment:* If the physical ID truly offers a non-exportable
signing key usable for legally binding signatures, then this is a strong
non-exfiltration story. If it doesn’t (or if jurisdictions vary), then the
model needs a fallback (e.g., secure element in device, external token,
etc.), and then you’re back in the world of device assurance and
certification tradeoffs.
3) User authentication (PIN/biometrics)

*Jori’s answer:* wallet API gates signing on-device using standard local
auth.

*Neutral assessment:* This is plausible and consistent with how most
secure-signature UX works today. The open issue is not “can you do it,” but
“what’s the minimum acceptable UX/security baseline” and “how do
verifiers/courts reason about it.” eIDAS leans toward formalized
requirements and assurance levels.
4) Liability and redress

*Jori’s answer:* legislation defines what must be verifiable in court;
parties retain evidence; revocation events are timestamped; verification is
independent.

*Neutral assessment:* This is the point where Steffen’s worldview bites: *legal
systems also care about who is responsible when things fail.* Jori’s model
can support legal adjudication *if* the law recognizes those proofs as
sufficient and if there’s a clearly accountable operator for the
status/registry layer (even if it’s a distributed system). eIDAS bakes this
into the framework via roles, supervision, and published mechanisms
(including relying party registration and wallet governance obligations).

So Jori’s approach *can* address liability—but it still needs a defined
legal mapping from proofs → responsibility, and a defined accountable
perimeter around the registry/log layer.
5) Governance and upgrades

*Jori’s answer (as written):* standards come from “global academic
consensus,” signed by a trusted publisher; OS verifies; keep things dynamic.

*Neutral assessment:* This is the least specified part of his proposal in
the thread. Even if you accept “open standards + signed releases,” you
still need:

   -

   a decision process for rule changes,
   -

   a mechanism for key/algorithm transitions,
   -

   and an authority model for publishing “the standard” and “the allowed
   profiles.”

The EU approach here is explicit: implementing acts + referenced standards
+ update cycles, and the trust list ecosystem evolves (e.g., updates to
trusted-list formats aligned to ETSI versions).
Jori’s approach can absolutely have governance—but it needs to be spelled
out as an actual mechanism, not just an aspiration.
Where the disagreement stays real (even under your assumption)

Even granting that physical ID + wallet API covers identity proofing,
non-exfiltration, and user auth, the key remaining fault line is:

*Do we want legal trust to flow primarily from:*

   -

   *(A)* cryptographic proofs anchored in user-held instruments + public
   verification material (Jori), or
   -

   *(B)* cryptographic proofs *plus* a regulated provider ecosystem and
   registries that define who may issue/operate under certain labels (Steffen)?

Both are compatible with cryptography. They differ on *market structure and
choke points*:

   -

   Jori is trying to minimize “permissioned intermediaries” in the private
   sector by making the system *self-verifying* for verifiers.
   -

   Steffen is trying to ensure legal reliability by requiring an ecosystem
   that can be audited/supervised and held liable—at the risk of higher
   barriers to entry.

eIDAS explicitly tries to reduce some choke-point risks (open-source
requirement; proportional, non-preauthorization relying-party registration;
voluntary use), but it still builds real governance rails (registration
mechanisms, published signed lists, implementing acts and certification
regimes).
Bottom line

A factual way to summarize it:

   -

   Jori is not ignoring the “hard problems” if the *physical ID chip* is
   truly the root of binding and key custody and the wallet API reliably
   enforces user presence. Under that assumption, his model gives verifiers
   strong *cryptographic* guarantees with fewer centralized intermediaries.
   -

   Steffen is emphasizing that in EU-style regulated environments, the
   system must also produce *institutionally legible assurances*
   (accountability, supervision, standardized procedures, long-term validation
   expectations). eIDAS explicitly encodes a lot of that in law + implementing
   regs.

The unresolved question is not “crypto vs non-crypto.” It’s whether the
governance layer is a *thin definition of admissible proofs* (Jori) or a *thick
regulated ecosystem with certified actors and registries* (Steffen)—and
what that does to competition, resilience, and user control in practice.

---------------

Best,
Jori

>