The point is you would have a different key on different devices, each of which can access your account. This gives you a backup, in fact a better one, because if one is comprimised and locked out you can still use the others. The main challenge is automating this process so you can properly mirror your keyring across multiple devices, which I don't think there's a standard solution to. So it would be a manual process for each account, which kinda sucks.

> The point is you would have a different key on different devices, each of which can access your account.

How would you sign up a new service under this scheme?

Enroll with one device, swap the hardware key, and enroll with the other key?

What if two device are not in the same physical location?

At the moment, yes, that's the process, annoyingly. Ideally, you would sign up with one and then be able to automatically enroll the others, which is in principle possible if you don't use resident keys and instead each device has the public key of the other devices you want enrolled at the same time, but I don't think is currently supported by the standards.

There have been many proven approaches how to solve this.

For example "blessing" the enrollment of a device using another one, potentially across physical locations (i.e. similar to what discord and steam did at least for a time as far as I remember).

> How would you sign up a new service under this scheme?

the same way you do now, there is no difference

The usual solution for this is to have multiple keys. It's logically equivalent to having a backup key, but it's more secure because if you lose a key, you can use another key to disable the lost key.

> It's logically equivalent to having a backup key, but it's more secure because if you lose a key, you can use another key to disable the lost key.

That's slightly more convenient but I don't see how it is more secure. With one key that has backups if I lose that key I can use one of the backups to disable that key.

Multiple keys is slightly more convenient in that scenario because with multiple keys I just have to disable the key that was lost, and then make a new key for the device that held that key and install it. With one key on multiple devices I'll have to install the new key on all of them.

Convenience is a key aspect of security, but consider the scenario where you have to replace all your locks while you issue a new key... you have to keep the extant key valid for a longer period of time.

The problem is you don’t actually know these keys do or do not work until you need them to. This is not a trivial failure mode for many systems.

The same is true for physical keys for cars, houses, lockers, etc., which is why people have an intuition to test out keys to make sure that they work.

Most people aren't going to do that for the standby keys. And while they test out the real keys, they mostly don't go from working to not working because someone did a garbage collection/unused keys pass or failed to update some field or deleted something on a server.

Yup. Instead they stop working because of rust, corrosion, wear & tear, or heat distortion from improper storage...

There seems to be an obsession that if a digital key doesn't comprehensively solve all problems, it's terrible, despite the empirical evidence that people are fully capable of using physical keys despite their limitations.

you don't need to backup a shared secret to gain exactly what you get from backing up a shared secret, except more secure

you have a backup of a _different_ secret with a similar degree of "authority" (or if it's "copyable" with the only authority to be used for restoring 2FA once or similar)

then if you backup gets stolen you can just go into you account management API and disable/delete/flag it, in that case even if encryption is broken as long as you act fast enough the damage is trivially and conveniently contained (e.g. some password managers had insecure backup/storage in the past)

with the same key not only do you have to disable it, you first have to create a new key and then sync it to all your new devices and backups and then disable the old key, which isn't grate if you have more then one device or some of you devices are temporary out of reach (e.g. you one a business trip)

it's like reintroducing the "physical" problem of having to replace all locks when you loose your house key in a situation where you could have all the benefits one key per lock and a different door for each person (i.e. device) without any of the overhead/drawbacks this would normally introduce

The main issue I see happening here with a large list of keys is the lack of an automated way of making these backups: this would require a standard way for a backup system to use one set of secrets to authenticate another set of secrets, which AFAIK doesn't exist for webauthn (it must be initiated by the site, all of which will have different methods of doing so). Otherwise you would have to manually enroll multiple devices for each account, which is both painful and error-prone.

That's what the one time use backup keys are for

yes, that too

and then use it with a backed up secure cold secret storage

OR (if you can, only for technical versatile people not a general solution at all):

as strange as it seems even with all the fancy new technology as far as I can tell the most reliable solution for long term account recovery(1) is to get a very small number of long ungussable one time use recover keys you encrypt in a blob and print out base64 encoded as a qr code(s) or similar and then put into a save, maybe in a bank, maybe more then one print

This solution while AFIK more reliable then any fancy technical solution is imperfect as in:

1. it isn't viable for everyone (i.e. you need a reasonable accidental damage save place which is preferable not in your home)

2. it requires the user to do the right thing

3. has some initial one-time time cost

This means it's not viable to be used for every single service.

Through you don't need it for that either, instead you can use it e.g. for a slow fallback to access encrypted blob storage in which you stored a database with one time code for resetting you various services. Then every time you sign up new services you extend that storage using you hardware bound keys and if you ever loose access to all hardware bound keys (unlikely to ever happen if you just act with a bit of care) you can go through the annoying process of getting you papers, scanning them, decrypting then and getting your one time reset codes.

Through now that I have already gotten way off topic, what I want is neither passkeys or having separate keys enrolled with tens of services. I want to have widely used standard interface where I can use the identity provider *of my choice* with *any* service (which is also easy to integrate for services).

There is AFIK no technical reason this doesn't exist and if we had that there wouldn't be any need for discussions about passkeys and password etc. Because for most people there would only be one or two logins + 2FA.