Article · May 2026

01 — The original frustration

Ezkey started from a very personal technical frustration.

I come from a backend background. When I looked at modern strong authentication, I could see why passkeys and related approaches matter. They are built on serious cryptographic foundations, and they clearly point toward a future that depends less on passwords.

What I struggled with was not the cryptography. It was the surrounding ecosystem: browser mediation, UI ceremony, protocol layers, and an integration model that never felt natural to the way I reason about systems.

02 — Why stronger authentication still mattered

I do not reject strong cryptographic authentication. I believe it is one of the right ways to reduce long-term dependence on passwords.

What I wanted was not to reproduce every layer of formal assurance found elsewhere. What I wanted was a different path to a meaningful level of protection: stronger than passwords, stronger than classic TOTP-style code generators, and more natural from a backend point of view.

03 — Why I looked for a backend-first alternative

From my perspective, there seemed to be room for a system designed from the backend outward rather than from the browser inward.

That meant trusted APIs, durable server-side state, explicit cryptographic verification, and a mobile application acting as a secure participant in the chain. In that model, the backend is not a passive receiver of user interaction. It becomes an active verifier and the durable source of truth across enrollment and authentication flows.

That search for a backend-first answer is the real origin of Ezkey.

04 — What Ezkey is trying to do

Ezkey is my attempt to explore whether stronger authentication can be built around a different center of gravity: backend control, explicit trust boundaries, cryptographic continuity, and practical APIs that developers can reason about.

This is why the protocol emphasizes linked phases such as bind / verify and pending / respond. The goal is not cosmetic simplicity. The goal is coherence: one flow, one chain, one backend-owned story of state and verification.

Another way to describe the project is this: Ezkey is looking for a middle ground. It is not satisfied with passwords and commodity OTP flows, but it also does not try to reproduce the full ceremony, assurance model, and implementation depth of the WebAuthn ecosystem.

To be precise, I am not claiming that this complexity is universally experienced the same way. I am describing a complexity that felt real to me. Ezkey is my attempt to explore something that, in my view, is hopefully simpler to reason about and operate from a backend perspective.

05 — What Ezkey is not claiming

Ezkey is not a FIDO2 implementation, not a WebAuthn layer, and not a simplified passkey variant. It does not claim standards equivalence by association.

The project should be understood as a parallel path, not as a shortcut or a compatibility wrapper. Its purpose is narrower and more opinionated: to offer a coherent alternative for teams that want a stronger authentication posture with direct backend control, clear trust boundaries, and operational visibility.

It also does not claim a full formal trust model. Ezkey does not validate complete certificate chains in the way a mature platform security stack might. Planned certificate pinning is intentionally simplified and project-specific, not a claim of full-blown pinning in the strictest sense. Device-side signals such as StrongBox availability may be reported and cryptographically carried by the protocol, but they are not elevated into a full certification-backed attestation chain.

06 — Where I draw the line on complexity

This is an important part of the project DNA: I am drawing a line in the sand on complexity.

Some security mechanisms bring real value but also bring a level of ceremony, verification infrastructure, platform dependency, and implementation burden that I am not currently choosing to absorb into Ezkey. That boundary is not presented as universal truth. It is my boundary, shaped by judgment, trade-offs, learning, and my own perception of where the complexity stops feeling worth it.

In practice, that means Ezkey is opinionated not only about architecture, but also about how much security complexity it is willing to carry. Some of those choices may evolve over time. Some may remain intentionally simpler than what a standards-maximal system would do.

07 — Security ambition, without overclaiming

Ezkey is still a security project. It aims to be materially better than passwords and materially better than classic TOTP-style authenticators for certain backend-oriented use cases.

But it should not be read as a claim of formal completeness. It is a pragmatic and experimental middle voice: stronger than the low end, and, in my view, hopefully simpler than the high-ceremony end, while still potentially useful for some enterprise contexts and clearly not matching every security requirement or assurance expectation.

That nuance matters, because there was no market study that forced this exact position into existence. Ezkey is an opinionated project built from perceived need, technical conviction, and my own sense of where the trade-offs become worthwhile.

08 — Why the project is AI-first

Ezkey is also an AI-first project.

At the beginning, I explored fast and imperfectly. Later, I paused to take the codebase back in hand, restructure it, and raise the quality bar before continuing. Since then, a large part of the work has been driven through planning, review, critique, refactoring direction, and disciplined iteration with AI.

Over roughly a year, this produced an unusually large volume of work plans, architectural adjustments, and structured improvements. The point is not that AI replaced seriousness. The point is that AI made a larger and more ambitious learning and building loop possible.

09 — Why this project is serious anyway

Ezkey is experimental, but it is not casual.

I invested real time and attention into the architecture, the protocol design, the APIs, the mobile application, the operator surfaces, and the documentation. The project became a place to test ideas seriously: security boundaries, lifecycle design, UI pragmatism, self-hosting, API clarity, and the practical use of AI as a force multiplier.

It is self-funded, self-directed, and intentionally constrained by the standards I wanted to apply to a greenfield project done with care.

Part of that seriousness is being explicit about limits. I have meaningful backend and systems experience, but I am not presenting myself as the final authority on security engineering. Ezkey reflects informed choices, not omniscience, and many of its trade-offs are explicitly colored by my own judgment rather than by consensus or market validation.

10 — What kind of project Ezkey really is

Ezkey is an opinionated project. It comes from a specific developer perspective. It is based on a perceived gap, not on a proven mass-market demand. It is experimental, but not unserious. It is AI-first, but not indifferent to quality.

In that sense, Ezkey is also a synthesis project. It gave me a greenfield space to apply accumulated convictions about backend systems, security, APIs, operational clarity, and software design in a way that would have been difficult to attempt alone in another era.

Back to Articles & Notes

Read in French