That way the server only has your public key (and everyone can have it anyway).
That way the server only has your public key (and everyone can have it anyway).
It probably won't ever change unless one of the browser vendors that is also an vendor of popular online services decides that it would be good to enable it in its own services, and picks up the cost of upgrading its own UX to support that (creating pressure on other browser vendors, while also lowering the barrier for other online services.)
The problem is that all of the browser vendors that could do it are pushing their own, online authentications schemes, and have no interest in client-based authentication.
But yes, having small memorizable passwords is much more convenient.
"The site is asking you to sign up. What secure login key would you like to use?
* Personal
* Office
* Contracting"
You are person 'A' and you have the private key (and maybe password used to unlock the key) to prove this fact.
You don't need different private keys for each and the remote end just has a public key that says the account belongs to person 'A' and that key is public.
The only usage case would be if someone wanted multiple accounts at the same site, and that would be rare indeed.
The only other real concern, site hacks/collaboration leaking where you're a member of by public key, wouldn't be alleviated by merely a handful of keys anyways: you'd need unique keypairs for each to be truly secure.