A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.
I also think client certificates is a better solution. However, it does not have to be single per-user.
For example, a service that you register an account on can issue a certificate to you; you could use it directly or you could use that certificate to issue another certificate to yourself, with a different key, and storing the private key of the original certificate on a separate computer that is not connected to the internet, making it less likely to compromise (if the certificate actually used is compromised, it could be revoked and you can issue a new one to yourself).
If the service defines an extension for the authorization granted by the certificate, then you could issue a certificate to yourself that has an extension to restrict the authorization, therefore allowing partial delegation of authorization. (Some operation would be authorized only if all of the certificates in the chain authorize that operation.)
The partial delegation of authorization can also be used to issue certificates to others, perhaps for a limited time (by setting the expiry date). For example, if one service can access another service to do some operation on your behalf, you can issue a certificate to the first service (this is one case where a client issues a certificate to a server), with the limited authorization that is required, and then that first service will use that certificate to authenticate with the second service, to do the operation.
A service that wants someone to be able to use their account from another service to log in to their own one can also do so (although usually this should not be required, since someone might not want the other service).
The private keys can optionally be passworded for additional security, and the server doesn't know nor care about this. (Passworded private keys is probably not useful for server certificates, but it is useful for client certificates.)
The use of mutual TLS authentication has other security benefit as well.
Having a single certificate makes it trivial to implement cross-website tracking. FIDO2 (and by extension Passkeys) prevent this by having a unique key for every (origin, username) combination.
Also, having a single cert shared across multiple hardware tokens is a security risk, as it becomes impossible to distinguish the tokens or revoke only a single one of them.
The vast majority of users treat their set of passkeys as a unit anyway, so there’s no scenario when a single token would need to be revoked in isolation. A breach of one passkey can only occur from breaching the password manager itself, in which case all passkeys are exposed, so there’s no security benefit to having per site passkeys.
Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
perhaps this a good moment for you to engage in some reflection and consider that perhaps some people have put more thought in to "how do we replace passwords" than you did in making a single hacker news comment?
you:
> A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.
reply:
> Having a single certificate makes it trivial to implement cross-website tracking.
you:
> Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
well, indeed! perhaps designing a system to support multiple certificates with synchronisation, so that we're not forcing ever user to be trackable by every single website, would be a good idea.
some sort of keys to enable one's passage in to a website?
this is a cancer on this website, and certainly one I'm also suffering from, despite being quite aware of it - real life things are usually pretty complicated and just because I know enough to make a random guess at a solution, it doesn't mean people who have put way thought in to the problem have done a bad job or missed by brilliant insight.
For example, a service that you register an account on can issue a certificate to you; you could use it directly or you could use that certificate to issue another certificate to yourself, with a different key, and storing the private key of the original certificate on a separate computer that is not connected to the internet, making it less likely to compromise (if the certificate actually used is compromised, it could be revoked and you can issue a new one to yourself).
If the service defines an extension for the authorization granted by the certificate, then you could issue a certificate to yourself that has an extension to restrict the authorization, therefore allowing partial delegation of authorization. (Some operation would be authorized only if all of the certificates in the chain authorize that operation.)
The partial delegation of authorization can also be used to issue certificates to others, perhaps for a limited time (by setting the expiry date). For example, if one service can access another service to do some operation on your behalf, you can issue a certificate to the first service (this is one case where a client issues a certificate to a server), with the limited authorization that is required, and then that first service will use that certificate to authenticate with the second service, to do the operation.
A service that wants someone to be able to use their account from another service to log in to their own one can also do so (although usually this should not be required, since someone might not want the other service).
The private keys can optionally be passworded for additional security, and the server doesn't know nor care about this. (Passworded private keys is probably not useful for server certificates, but it is useful for client certificates.)
The use of mutual TLS authentication has other security benefit as well.