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.
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.