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.
zzo38computer|6 months ago
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.
crote|7 months ago
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.
scarab92|7 months ago
Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.