Passkey authentication and creation using cross-platform authenticatorAttachment. Is this the correct behaviour?

[RemcodM]

Steps To Reproduce

On any passkey capable website, create a passkey stored using Bitwarden or authenticate using a passkey stored in Bitwarden.

Expected Result

Since most password managers (e.g. 1Password) use the platform value for authenticatorAttachment, I would like to see Bitwarden using that value as well.

Actual Result

At this point, Bitwarden uses the value cross-platform for authenticatorAttachment.

Screenshots or Videos

No response

Additional Context

The problem that arises here is that the Webauthn spec is somewhat ambiguous about which values a password manager such as Bitwarden should use. According to https://www.w3.org/TR/webauthn-2/#sctn-authenticator-attachment-modality:

• A platform authenticator is attached using a client device-specific transport, called platform attachment, and is usually not removable from the client device. A public key credential bound to a platform authenticator is called a platform credential.

• A roaming authenticator is attached using cross-platform transports, called cross-platform attachment. Authenticators of this class are removable from, and can "roam" between, client devices. A public key credential bound to a roaming authenticator is called a roaming credential.

Arguably, password managers such as Bitwarden are platform authenticators, as the public key is bound to the Bitwarden vault. It might roam between devices (using the cloud vault synchronisation), but it never actually leaves Bitwarden and therefore the credential itself does not ever roam outside of Bitwarden. Therefore, the public key credential is bound to the authenticator, thus it being a platform credential. Therefore, using the platform value for authenticatorAttachment as many other password managers do seems appropriate.

On the other hand, if you read the definition of a roaming authenticator, you could argue that this applies to Bitwarden as well, as the Bitwarden authenticator can somewhat roam between client devices. However, that could be countered by saying that the Bitwarden authenticator is really a platform authenticator supported on multiple platforms and itself not really 'roaming'.

Futhermore the spec mentions:

We refer to authenticators that are part of the client device as platform authenticators, while those that are reachable via cross-platform transport protocols are referred to as roaming authenticators.

If we look at what cross-platform transport protocols are defined, we see that these are Bluetooth, USB and NFC. None of these seem appropriate in the case of Bitwarden. Moreover, Bitwarden uses the internal transports value, which suggests the public key was directly provided by the platform.

Why is this all relevant?
Websites seem to use the cross-platform value to detect if the user should be nudged to create an additional passkey on the client device. They expect the user to have logged in using a phone or security key, for example, and then ask the user to create an additional passkey on the device itself. This is a weird interaction in the context of Bitwarden, since the credential is already present on the client device and creating an additional passkey does not really make sense. The nudge here is an annoying interaction for websites that use the cross-platform value.

Operating System

Windows, macOS, Linux

Operating System Version

No response

Web Browser

Chrome, Safari, Microsoft Edge, Firefox, Opera, Brave, Vivaldi

Browser Version

No response

Build Version

2023.10.2

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[SergeantConfused]

Hi @RemcodM,

Thank you for this report. As you have noted, the authenticatorAttachment definition in the spec leaves some room for interpretation when it comes to Bitwarden’s implementation. However, after further consideration, and taking into account the evolving way that relying parties are using this value, we do feel that platform is more appropriate. We will be making this change in an upcoming release.

Thank you again,