Yes, either the Browser or the OS will need to be involved. For example, for Webauthn on Chrome on Windows: chrome receives the request, then it calls the Windows Hello APIs. Then, that Windows Hello API shows a popup to read a physical security key or authenticate a virtual security key via face/PIN (this is protected by a TPM, but it's "virtual" since Windows generates it via the TPM but stores it encrypted on-disk).
To support a syncing fido keyvault, Chrome could very well redirect the calls to its own popup for choosing to 'use Chrome', or 'use another key', which would then call the Windows Hello API. In fact, Chrome already supports this[0], with 'Add a new Android phone' is simply how they're presenting Webauthn over BLE, and it works with iOS when passkeys are enabled in the iOS developer menu[1].
Yes, either the Browser or the OS will need to be involved. For example, for Webauthn on Chrome on Windows: chrome receives the request, then it calls the Windows Hello APIs. Then, that Windows Hello API shows a popup to read a physical security key or authenticate a virtual security key via face/PIN (this is protected by a TPM, but it's "virtual" since Windows generates it via the TPM but stores it encrypted on-disk).
To support a syncing fido keyvault, Chrome could very well redirect the calls to its own popup for choosing to 'use Chrome', or 'use another key', which would then call the Windows Hello API. In fact, Chrome already supports this[0], with 'Add a new Android phone' is simply how they're presenting Webauthn over BLE, and it works with iOS when passkeys are enabled in the iOS developer menu[1].
0: https://i.judge.sh/Qq93C/v_GG5R7LyM.png
1: https://developer.apple.com/documentation/authenticationserv...