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

"f 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."

Thanks for confirming my claims. When it comes to keys the device or keys must be trusted through certification.

Best
Steffen
________________________________
Von: Jori Lehtinen <lehtinenjori03@gmail.com>
Gesendet: Sonntag, 15. Februar 2026 16:05
An: Steffen Schwalm <Steffen.Schwalm@msg.group>
Cc: Manu Sporny <msporny@digitalbazaar.com>; NIKOLAOS FOTIOY <fotiou@aueb.gr>; 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.

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 claiming
Jori’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