Ideally they would run some kind of CA and users would generate keys local to the device with some kind of alternate authentication when setting up the device initially.
Generating keys is cheap and the fact that your key could be tracked across services is a problem you'd want to avoid upfront. This is already an issue with things like SSH where you can finger-print devices when they present their public keys.
When signing up the user could be given the option to enable alternate authentication via FIDO2, Password, or Passwordless (email). Otherwise authenticating another device works by approving a new device from an existing one.
> Ideally they would run some kind of CA and users would generate keys local to the device with some kind of alternate authentication when setting up the device initially.
This presents a bit of a chicken and egg problem for how to secure the initial signup. Most services now use "control of email address" which has its own issues.
> Generating keys is cheap and the fact that your key could be tracked across services is a problem you'd want to avoid upfront. This is already an issue with things like SSH where you can finger-print devices when they present their public keys.
There are concerns about tracking, but that can be done without a private key. There are pros and cons for both singular and multiple keys one of the pros for a single keypair being your keypair does identify you as you. That's bad for tracking but it's good for more trustworthy authentication. Ideally, for some uses you could as a person get a signed personal cert and it'd be as good as government ID.
> When signing up the user could be given the option to enable alternate authentication via FIDO2, Password, or Passwordless (email). Otherwise authenticating another device works by approving a new device from an existing one.
A good first step for reused or unique-per-service or even unique-per-service-and-device keypairs would be to allow a user authenticated by password or whatever to upload a public cert (possibly via web form) and enable access to the account (or portions of the account) going forward only to sessions initiated with that client cert and key.
S/MIME handles some issues of key propagation pretty simply in that a sender, A, signing a message is sufficient for the recipient, B, to then send encrypted email to B. The initial S/MIME installation of the user's own S/MIME certificate is still more involved. However, it might be as simple with web apps and other apps that use a web or web-like remote API to have an option to auto-trust certs going forward that are used to log in to the account by other means (like password and Yubikey).
Generating keys is cheap and the fact that your key could be tracked across services is a problem you'd want to avoid upfront. This is already an issue with things like SSH where you can finger-print devices when they present their public keys.
When signing up the user could be given the option to enable alternate authentication via FIDO2, Password, or Passwordless (email). Otherwise authenticating another device works by approving a new device from an existing one.