Because you or someone needs to publish "<digital_signature>" in a way that cannot be forged, stolen, MiTM'd, or otherwise compromised. Basically the key generating that signature just becomes another password, far more difficult to use in practice, and sharing all the same disadvantages.

So no one implements it for site-local login. Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.

The way secure auth works for small sites is that a third party[1] authenticates you, who the website trusts more than mere users. And that's where all the complexity comes up. You need something secure stored on your known-secure device, a password alone won't do.

[1] In practice Google or Meta. Occasionally Apple or Microsoft. Everyone else is noise.

▲

drhagen 4 hours ago | parent | next [-]

> far more difficult to use in practice

I guess I am envisioning the user agent doing all of this. You go to a site and create click account, your browser shows a pop-up: "<website> is asking you create an EasyAuth account. Would you like to create an account on this site?" If you click yes, then the user agent does this in the background:

website: Sure you can have an account. Use this token <token> once and this ID <user_id> forever.

me: Ok, here's your token <token> for ID <user_id> and my public key is <public_key>. Signed, <digital_signature> to prove it works on my end.

Maybe generating a unique public key for each website is not substantially better than generating a password, but at least a signature cannot get stolen on the server side or in transit. You wouldn't have to change your public key if their database got slurped.

Passwords also aren't standardized, so they are pain to generate (special characters required or disallowed?). They don't reliably autofill into a website. You still have to go through a manual flow to login; user-agent doesn't just keep you logged in. I guess I would be fine if the user-agent knew how to authenticate me to every website.

Maybe this is what the passkey system was before it got designed-by-committee'd into oblivion. I am just always amazed by how complex authentication is when the user-agent should be able to handle this rather painlessly.

	▲	ajross 2 hours ago \| parent [-]
		> I guess I am envisioning the user agent doing all of this. That's literally what a passkey is, that the linked article argues against. It relies on the platform vendor of your device hardware to validate the full stack of software. You can't just do it in a browser because anything that reads the browsers data (or attaches a debugger, or runs the browser in an instrumented VM, etc...) can exfiltrate the key.

▲

alwillis 3 hours ago | parent | prev [-]

> Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.

While that is an option, I've been using passkeys on Amazon since 2023.