It won't, at least not in the short term. For that to happen trusted platform modules would need an api to export a private key wrapped with a certificate signed by (none/one/all/a quorum) of members in the circle of trust and itself. This will need standardizing. Only apple has implemented it so far because it has total control of their ecosystem. I think for Windows and Chrome to work like this, they'll need to start requiring TPM vendors to implement this in their drivers, but I can't see it being cross compatible with the API in the apple TPM any time soon, especially because the circle of trust is now as weak as the weakest TPM, and it's a reputation risk for apple if a credential gets compromised because some non-apple device trusted by the user in an apple circle of trust got breached

I think the first iteration of this system will definitely receive the synced key material in RAM.

It's possible that the TPM spec will be updated to allow for loading pre-encrypted data into the TPM store as a response to this. Alternatively, existing secure computing systems (SGX/TrustZone) can also be used to decrypt the synchronised key relatively securely.

TPMs don't generally store encrypted data (bar their master key)

instead they wrap/seal everything instead with a layer of crypto, then you can pass that wrapped object around as much as you want, only the TPM can unseal it

a TPM could easily be instructed to seal an internally generated secret with additional escrow keys for MS/Apple/...

that plus remote attestation could make it so you can never see the key in the clear

As far as my understanding goes this sealed secret is device specific and connected to the TPM master key. That would mean you could pass it around, but you'd need to have the blob on the device itself to actually use it.

The problem is that you need private/public key pairs that are synchronised across devices for FIDO to work properly cross-device. When you register an account on your phone, you need that account key on your desktop to use it there, and that's nearly impossible without some kind of key sharing mechanism.

Yes but what the OP is saying is that the TPM does not store the encrypted passkey, rather, the passkey is wrapped with this TPM's public key by another TPM that already trusts this TPM, so this TPM can import a passkey that's been wrapped with its own public key and store it unencrypted. See Apple's circle of trust: https://support.apple.com/guide/security/secure-keychain-syn...

I understand that, but that's not supported by any current standard as far as I know. We'll need a new TPM standard for this, which probably also means it will take years before every device supports this feature as modern computers can easily last five to seven years if you replace the batteries and don't cheap out. FIDO needs something that works now, or maybe tomorrow.

Agreed, and that's why I say in my original comment that I don't see it happening in the short term. If we had something that worked now or maybe tomorrow and was acceptable, it would simply be virtual authenticators; an authenticator implemented entirely in software. There's no practical reason why password managers like 1Password can't do that beyond attestation which nobody checks anyway. But in the end, I don't see the big three participating in sharing. The threat model changes so much that especially for Microsoft (in cell phones) and Google (in desktops) that means trusting an adversarial OS they have no control over

you can do it easily enough with the current TPM operations (2.0, not 1.2)

receiving synced key material in RAM significantly alters the threat model. Apple's current passkey implementation does not, at any point, handle unwrapped key material in the operating system. I expect all other implementations to follow.