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