That would certainly be very convenient, but it would also retain/reintroduce several of the security weaknesses that passkeys are intended to mitigate.

The reality is that security is really, really hard. And it remains as true as ever that increased security comes at the cost of decreased convenience.

My personal attitude is that I make different security/convenience tradeoffs for different things. I do have and use hardware keys for very sensitive things. But they're rather inconvenient, so I don't use them for most authentication purposes. Does my account here on HN really need to have the best possible security? No, it doesn't.

So, in my opinion, both passkeys and the traditional username/password mechanism should be supported for most of the web. Which is likely how it's going to be for a long time.

I can see how remote enrollment makes it easier for a user to share a key in a way they shouldn't, but not all that much easier.

What other weaknesses will be introduced?

The ability to do auto-enrolment would break the per-site uniqueness of credentials (which makes them pretty strongly phishing resistant under most sane threat models where the browser isn't totally compromised)

Right now, the public key from one token is unique to that site (and specifically your registration attempt with the site, so you can have multiple unlinkable accounts using the one FIDO2 key). If you could do an offline and remote enrollment, you'd need to work with a single static public key (and corresponding private key) for all sites.

Despite all this, I still think this is a use case that's important - both the ability to have an offline backup key (even pairing all your tokens together at setup time to use a common internal root AES key wouldn't help as there's an anti replay counter in FIDO authentications from what I recall), and the ability to use passkeys portably across vendor ecosystems, without relying on a single ecosystem as your trust root.

There are some assumptions in your explanation that I'm not following.

For one, you could generate a new unique private key for the site login, and then encrypt that with the other device's public key. And you could sign it with the active device's key, so that third parties can't try to send you enrollment data.

If desired, you could handle this encryption in a way that makes it impossible for anyone else to tell what keys are being used.

Or instead of generating a private key, you could securely send a single-use token to the other device, and that token allows it to register.

Either way the fixed public key would only be used once, and only directly between the two devices. It doesn't get tied into the site authentication process. And you could replace or augment it with a symmetric key that's unique to that device pair.

> would break the per-site uniqueness of credentials

It wouldn't break things as I've described it. Each device would have a handful of pre-negotiated single-use public keys for the other device it could enroll with.

I tend to think there's no blockers and I just invented a better+obvious flow.

> It'd be awesome if you could ask to enroll a variety of other devices all at once, without having them on hand.

This is one of the feature goals Yubico said they want to implement.