[woodruffw]

As far as I can tell, there's no nonce (for replays) or counter (for stolen keys) in this scheme, both of which are fundamental to the security model that WebAuthn provides. There's also no formal sliding window for server times or key timeliness constraints.

In many regards, this scheme is no better than a strong password in terms of guarantees provided. In terms of UX, it's strictly worse than a password (and those are already pretty bad!) It's not a second factor at all, and thus isn't really an "alternative" to WebAuthn.

[staticassertion]

Yes, this looks like it's just a worse version of passwords.

[md_]

It’s worse. It encourages the use of the same strong “password” on every website?

[0xdeadb00f]

I don't believe it does. The author is in this thread and keeps indisting the idea is to use a different ed25519 keypair for every site.

[Xylakant]

The idea may be, but then users will need to manage a key pair per site - and there’s less support for safely managing key pairs than there’s for passwords. How many people will actually do that, if the system doesn’t enforce it and how can the system enforce such a constraint?

[md_]

I think if I'm being generous, the proposal is to eventually have a credential management ecosystem (with cross-device key syncing, and keys per origin) similar to WebAuthn.

However, if you do this, you rapidly start to discover some of the reasons behind WebAuthn's design choices. For example, to prevent phishing/replay/linkage, the "authenticator" (the thing managing the keys) has to know the origin/RP. And to allow hardware and software authenticators, you need some protocol like CTAP to abstract that out. And because some RPs want to require hardware-backed or biometric authenticators, you need an authenticator type. Etc, etc, etc.

If WebAuthn is hard to use, it's because we haven't build the right libraries and abstractions yet, and that indeed sucks. (Though I think we mostly have, and it's not that hard to use.)

But the criticism here of complexity--contrasted with the simplicity of a trivially broken, horribly unusable "proof of concept"--is a bit like someone who says "I can make a working demo of a car without power steering, antilock breaks, an entertainment unit, an ECU, a catalytic converter, or headlights--just four wheels and a two-stroke engine! Clearly all that complexity isn't needed!"