right, would be better for the site to encrypt a one-time-use password with the public key you've, then all you have to do is decrypt it and log in, proving you possess the private key

does this have a name? always seemed like the obvious way to do it but I've never implemented auth

edit: I guess this is similar to a challenge/sign/verify signature scheme like webauthen, but is it inferior in some way?

Yep, what you've described is pretty close to the scheme in WebAuthn. The main additions in WebAuthn are for protocol level security: there's an attestation nonce, a shared counter, and some other fiddly bits to make it harder/impossible to misuse.

This is exactly what I use for an emailless password reset. Instead of sending a reset token via email, it's just encrypted with public key and user can decrypt token for reset password. There for I don't require to collect email address for account. Of course this could also be used as login method. On the downside, for UX purposes decryption can run in browser by passing private key. I have mixed feelings about pasting PKs into browser.

SRP, PAKE, and OPAQUE. More generally, zero knowledge proofs (ZKP).

thanks !

PoP, Proof-of-Possession.

Yeah, there's no verification of a server's pubkey like ssh (which mostly is trust-on-first use), or a cert chain like tls. This seems like a cool proof-of-concept. There are also a bunch of security properties that it fails in.

It's the same for passwords.

The advantage is that your private key can't be leaked on a third party website.

Why would you use the same keypair for multiple sites?

What's stopping an idiot from doing so?

The fact that it's a bare-bones technical demonstration and an idiot would have no wherewithal or purpose to implement it.

But then what's it actually demonstrating? That public key cryptography can be used to...validate that someone has a private key?

I feel like I knew that already. ;)