Passkeys authenticatorAttachment and transports in macOS 14.4 and iOS 17.4

In the new macOS and iOS updates (14.4 and 17.4 respectively), something has changed in regards to passkey creation:

• Any passkey created from Safari doesn't have any transports + the authenticatorAttachment is always set to platform, irrespective of whether a cross-platform authentication method is utilized, such as a hardware security key.
• All passkeys saved in iCloud Keychain created from any browser have an authenticatorAttachment always set to platform + empty authenticator transports.

authenticatorAttachment always set to platform

According to the WebAuthn specification (Section 5.4.5), the authenticatorAttachment descriptor plays a crucial role in guiding the client (browser or platform) to create or use an authenticator of a specific type. The options are platform for a built-in authenticator or cross-platform for a roaming authenticator.

Some relying parties mandate a cross-platform method for the first passkey or as second authentication factor. This is to ensure users do not find themselves locked out when they try to sign in from a device that doesn't have access to the non-roaming webauthn credential. Unfortunately, the current implementation in Sonoma 14.4 forces the authenticatorAttachment to platform, thus preventing the creation of passkeys that comply with such policies on websites.

For comparison, browsers like Chrome correctly return a cross-platform authenticatorAttachment when a hardware security key is used, and the same used to happen on previous macOS and iOS versions from Safari.

Authenticator transports missing

The absence of transport data (WebAuthn Section 5.8.4) for all passkeys created via Safari and iCloud Keychain passkeys created from all browsers further complicates the scenario. The transport hint is crucial for informing relying parties about the preferred transport method for the authenticator, be it USB, NFC, BLE, HYBRID or internal. This omission could lead to inefficiencies and a diminished user experience, as the system cannot optimize the authentication process based on the authenticators available to the user.

These issues jeopardize the utility and adoption of passkeys across various platforms and browsers, a primary goal of WebAuthn and FIDO2 for widespread secure authentication practices. What is the rationale behind this choice and is there any workaround to be considered?

Thanks for all the help and clarification!