WebAuthn Passkey QR Codes & Bluetooth: Hybrid Transport

1. Introduction

2. Passkeys: Synced or Only Available on a Single Device

3. Technical Setup of Cross-Platform Passkey Authentication

    3.1 Hardware Requirements

    3.2 Software Requirements

4. Passkeys: QR Code

    4.1 Initiate the Passkey Cross-Platform Authentication

    4.2 Generate the QR Code

    4.3 Scan the QR Code

    4.4 Start the Data Flow and Authentication Process

    4.5 Transmit Technical Data

    4.6 Validate the Signature

5. Passkeys: Bluetooth (caBLE)

    5.1 What is Bluetooth Low Energy (BLE) in Authentication?

    5.2 What is caBLE (Cloud-Assisted Bluetooth Low Energy)?

    5.3 User Experience and Security with caBLE

    5.4 Scenario: The QR Code vs. BLE Dilemma

    5.5 Data Exchange and Privacy

6. Benefits

    6.1 Path to Good User Experience

    6.2 Robust Security

    6.3 Passkey Integrity

    6.4 Phishing Prevention

7. Disadvantages

    7.1 User Familiarity and Adoption

    7.2 Dependence on Device Capabilities

    7.3 Inconsistent User Behavior

    7.4 Developer Adaptation

    7.5 Creating New Passkeys

    7.6 Educating Users

8. Real-Life Test: Hybrid Transport Passkey Behavior

    8.1 Windows 11 23H2 + Chrome 119

    8.2 Windows 11 23H2 + Edge 119

    8.3 Windows 11 23H2 + Firefox 119

    8.4 macOS Ventura + Chrome 119

    8.5 macOS Ventura + Safari 16.6

    8.6 iOS 17.1 + Chrome 119

    8.7 iOS 17.1 + Safari 17.1

    8.8 Windows 10 21H2 + Chrome 119

    8.9 Windows 10 21H2 + Edge 119

    8.10 Windows 10 22H2 + Chrome 119

    8.11 Windows 10 22H2 + Edge 119

9. Recommendations for Developers

    9.1 Implementation Tips

    9.2 Educational Strategies

    9.3 Temporary Access Considerations

10. Conclusion: QR Code / Bluetooth Passkeys

1. Introduction

Passkeys are more and more replacing passwords as the de-facto standard in user authentication. Unlike traditional passwords, passkeys are bound to an ecosystem (e.g. iCloud Keychain, Google Password Manager, Windows Hello or a password manager like 1Password or Dashlane); they are not designed to be memorized but are built to seamlessly integrate with your devices, offering great out- of-the-box user experience.

Imagine youre away from your personal computer perhaps at a public terminal or a friends laptop and you need to log into your passkey- protected account. This scenario is quite common and necessitates a secure yet convenient method of authentication but with passkeys many people dont know what to do, as their passkey is not immediately available in this situation. One of the passkey features to help you in such a situation is the ability to employ your passkeys across multiple devices through the facilitation of QR codes and Bluetooth technology. This process is formally known as hybrid transport in the WebAuthn specification (in previous versions of the specification it is referred to as cloud-assisted Bluetooth Low Energy caBLE).

The process is straightforward: you need a device that has your passkeys stored and is capable to take pictures, so most likely a smartphone or tablet. This device can open a tunnel to the new device just for that one instance of authentication. This not only maintains the integrity of your passkey but also ensures that access to your account on new devices can be given, no matter where you are or whose device you want to use to login.

However, this passkeys cross-platform authentication feature is surrounded with misconceptions and confusion both in its utility and its technical implementation. This is something I noticed recently again, when I visited a local IT security meetup. Through this article, we aim to unravel the complexities and provide recommendations to implement this cross-platform passkey authentication (hybrid transport) flow, ensuring you can provide the best login experience for your users.

2. Passkeys: Synced or Only Available on a Single Device

Passkeys are a form of user authentication that replaces the traditional password with a more secure and convenient cryptographic public-private-key pair. This key pair is unique to each user and is used to verify identity without the hassle of remembering complex passwords.

The advantages of passkeys are numerous when compared to their password predecessors. They significantly reduce the risk of phishing, as they cannot be tricked into being shared with a fake website. Moreover, they are immune to brute force and dictionary attacks, which are common methods used to crack passwords. Passkeys are also more user-friendly, eliminating the need to remember or manage a long list of passwords.

Passkeys are synchronized in cloud accounts, like those managed by Google Password Manager or Apple iCloud Keychain (Microsoft with Windows Hello will follow soon), or those stored in modern passkey-ready password managers, like 1Password or Dashlane. However, its essential to know that by default passkeys are bound to the ecosystem and the respective cloud account synchronization. The operating systems do not provide an interface to export the private keys and in most devices, there is a hardware component providing additional security measures to avoid any access to the private keys, e.g. the secure enclave on iOS devices or the trusted platform module (TPM) on Windows devices. Only the operating system provider can sync the passkeys to other devices in an encrypted way (ultimately protected by the users biometrics, passcode or PIN). The private keys can only be restored and decrypted using the passcode / PIN and will be destroyed in case there are too many unsuccessful login attempts to the cloud account (e.g. Apple introduces a rate limit to prevent brute-force attacks even from a privileged position on the cloud backend; Google does the same).

This inherent design means that if passkeys arent synced as described, accessing your passkeys on a new device can pose a challenge. This is precisely why the hybrid transport method for passkey cross-platform authentication (hybrid transport) with QR code and Bluetooth proximity check exists. It provides a secure bridge for your passkeys between devices without the need to sync them through a cloud account / password manager, thereby maintaining the principle that passkeys can solely remain with the user.

3. Technical Setup of Cross- Platform Passkey Authentication

Using cross-platform passkey authentication (hybrid transport) with hybrid transport helps overcoming cross-device problems, when an account is purely accessed via passkeys. As not all passkeys are synchronized in cloud accounts or password managers, the necessity for a reliable method of accessing passkeys across devices becomes critical, especially when transitioning to a new device or needing access on a shared device.

3.1 Hardware Requirements

To facilitate passkey cross-platform authentication (hybrid transport), there are the following hardware requirements:

• WebAuthn Support: The devices must support WebAuthn. This is already given on 99% of devices, according to our latest passkey data analysis.
• Camera for QR Code Scanning: Devices will need a camera capable of scanning QR codes. Most modern smartphones are equipped with cameras that have this functionality. Moreover, the camera needs built-in QR scanning capabilities (what most devices have out-of-the-box). Otherwise, installing a QR code app is fine, too.
• Bluetooth Capability: Cloud-assisted Bluetooth Low Energy (caBLE) is used for establishing a proximity-based secure connection between devices. The versions to look for are Bluetooth 4.0 or higher, which enable the caBLE extension for WebAuthn.
• Internet Connection: A stable internet connection on both devices needs to be in place, as the exchange involves opening a tunnel to perform verification steps that require real-time data transfer.

3.2 Software Requirements

From a software standpoint, the following requirements exist:

• WebAuthn Server Configuration: Obviously, you need to have a WebAuthn server in place that manages the public keys. This also involves enabling the users account to be linked with multiple authenticators and setting up the server to initiate the authentication ceremony.
• Web Bluetooth API: For the Bluetooth proximity check, youll need to access the Web Bluetooth API that triggers the devices Bluetooth capabilities from a browser.
• Operating System Requirements: Please see the following table about the support of Cross-Device Authentication for different operating systems as of November 2023. Authenticator means that the device can serve as the device that holds a passkey (in our scenario the smartphone). Client means the device that creates the QR code and where the user tries to login (in our scenario the desktop):

Source: passkeys.dev

4. Passkeys: QR Code

The process to use passkey cross-platform authentication (hybrid transport) via QR code looks as follows:

4.1 Initiate the Passkey Cross- Platform Authentication

The QR code for passkey cross-platform authentication (hybrid transport) is generated when a user attempts to access a service on a device where the registered passkey is not present, but the service knows that the user should have a passkey. Typically, a Scan QR code button or a similar call-to- action is provided within the authentication interface.

4.2 Generate the QR Code

Upon user request, the device initiates the generation of a QR code. This QR code encodes a unique, time-sensitive session identifier. This identifier is tied to a session that the authenticating server temporarily maintains, awaiting completion of the authentication process.

4.3 Scan the QR Code

The user scans this QR code with a device where their passkey is available. Security measures include:

• One-time use: The session identifier within the QR code is valid for a single use, preventing replay attacks.
• Encryption: All data within the QR code is encrypted, ensuring that any intercepted communication cannot be deciphered by unauthorized parties.

The scanned QR code holds a specific URI with the scheme FIDO, e.g.: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

4.4 Start the Data Flow and Authentication Process

Scanning the QR code triggers the users second device (e.g. smartphone or tablet) to interpret the FIDO URI and communicate with the authentication server, sending a signal that the user is attempting to authenticate via a new device (e.g. the friends laptop). This action prompts the server to generate a cryptographic challenge, unique to this authentication attempt.

4.5 Transmit Technical Data

The challenge is sent back to the users second device (e.g. smartphone or table), where their passkey is stored. The device then creates a digital signature using the private key associated with the passkey, without the private key ever leaving the device (e.g. smartphone or tablet). The signed challenge (signature) is then sent back to the server through a secure, encrypted tunnel over the internet, verifying the integrity and origin of the authentication attempt.

4.6 Validate the Signature

The server validates the signature using the corresponding public key already associated with the users account. Upon successful validation, the server confirms the authentication, allowing the user to access the service on the new device.

Some more important privacy and security aspects to consider:

• No Bluetooth, Pure Internet: It is important to note that in this QR code-based passkey cross-platform authentication (hybrid transport), Bluetooth is not involved in the authentication and data exchange. This process relies entirely on an Internet connection for the transmission of encrypted data between the devices and the server.
• Private Keys Dont Leave The Device: Throughout this process, the users private keys remain securely on their device.
• No Sensitive Data Exposure: No sensitive passkey information or private keys are transferred or exposed during the authentication process.
• Asymmetric Cryptography: The challenge-response mechanism ensures that what is being sent are merely non-reusable, signed versions of challenges that cant be exploited for unauthorized access.

By adhering to these technical and security protocols, the QR code method for passkey cross-platform authentication (hybrid transport) upholds a high standard of security while providing a convenient way for users to authenticate their identities on new devices.

5. Passkeys: Bluetooth (caBLE)

Besides, the QR code scanning process, there is also the proximity check via Bluetooth (caBLE). Being sure that the client and authenticator are physically close to each other is one of the major benefits of the WebAuthn protocol. More insights on the inner workings of this process are described in the following:

5.1 What is Bluetooth Low Energy (BLE) in Authentication?

Bluetooth Low Energy (BLE) is a wireless communication technology designed for short-range data exchange. It plays a pivotal role in confirming the physical proximity of devices during the authentication process.

5.2 What is caBLE (Cloud-Assisted Bluetooth Low Energy)?

caBLE is a protocol that facilitates the secure transfer of authentication information between devices using BLE. When using caBLE for passkey cross- platform authentication (hybrid transport), the device that holds the passkey confirms the proximity of the requesting device via BLE signals. Once proximity is verified, the authentication process proceeds, leveraging BLE for secure, local communication.

5.3 User Experience and Security with caBLE

The user experience is enhanced as this method typically requires less direct user interaction; devices in close physical proximity detect each other automatically. For security, caBLE offers a significant advantage - it ensures that the authentication process is only carried out when the two devices are near each other, preventing remote attackers from initiating the authentication process.

5.4 Scenario: The QR Code vs. BLE Dilemma

Imagine receiving a QR code that redirects to a malicious site. If authentication is performed through this QR code, theres a risk that the session or cookie might be hijacked. BLE circumvents this issue by not relying on a visual scan, but rather on the physical presence of devices. This proximity check minimizes the risk of man-in-the-middle attacks, as the proximity check doesnt occur over the internet or a visual medium.

5.5 Data Exchange and Privacy

Unlike other methods, caBLE does not actually exchange authentication data like passkeys. Instead, it uses BLE as a confirmation channel to establish that the devices are physically close. This check is designed to be a part of a multi-factor authentication process where BLE proximity is one of the factors, ensuring that even if other factors are compromised, without physical proximity, access is not granted.

By integrating the caBLE protocol, developers can offer a secure and user- friendly method for passkey cross-platform authentication (hybrid transport) that enhances the overall security of the authentication process. The proximity check adds an additional layer of protection that is simple for users and yet effectively safeguards against certain types of sophisticated cyber-attacks.

6. Benefits

The following benefits of this passkey cross-platform authentication (hybrid transport) method exist:

6.1 Path to Good User Experience

Cross-platform passkey authentication via QR code and Bluetooth (hybrid transport) is a way to improve the UX in cross-platform scenarios compared to not offering any possibility at all. However, the user flow is absolutely new to most users and we dont expect many non-technical users to understand what is happening when they first come across this flow. The only resemblance of introducing the QR code flow can be with login flows for e.g. WhatsApp Web or Discord where QR codes are employed (here the functionality is different though). So, the analyzed cross-platform passkey authentication process via QR code / Bluetooth (hybrid transport) minimizes user effort in the cross- platform scenario, as theres no need to manually enter any credentials, but still the overall flow is unknown to most users.

6.2 Robust Security

The security of passkey cross-platform authentication (hybrid transport) is reinforced by advanced cryptographic techniques. When a QR code is scanned or a Bluetooth connection is made for authentication, cryptographic challenges and responses ensure that only the intended device can successfully complete the authentication process.

Proximity checks via Bluetooth add an additional layer of security, confirming that the authentication attempt is being made by someone with physical access to the secondary device.

6.3 Passkey Integrity

During the cross-platform authentication (hybrid transport) process, passkeys are never temporarily stored on intermediary devices or servers, which prevents the risk of passkeys being intercepted or leaked during the transfer process. The authentication happens in real-time, and the passkey remains bound to the users primary device, preserving its integrity.

6.4 Phishing Prevention

The QR code and Bluetooth authentication methods inherently provide protection against phishing. Users are less likely to be tricked into providing a passkey for a malicious site because the authentication process requires physical actions that are specific to the users trusted devices.

The process of scanning a QR code or connecting via Bluetooth typically happens in a trusted environment, reducing the chance of users inadvertently compromising their credentials.

7. Disadvantages

The following disadvantages of this passkey cross-platform authentication (hybrid transport) method exist:

7.1 User Familiarity and Adoption

Introducing any new technology can lead to user confusion, especially if the users are not tech-savvy. Passkey cross-platform authentication via QR code and Bluetooth (hybrid transport) is a significant shift from traditional authentication methods, and some users might find the new process challenging to grasp, potentially leading to a slower adoption rate. However, we expect that users will eventually get used to it, so the change might be harder in the beginning and will be smoother and more accepted over time.

7.2 Dependence on Device Capabilities

The success of passkey cross-platform authentication (hybrid transport) heavily relies on the users device having the necessary capabilities, such as a camera that can scan QR codes and Bluetooth functionality. Users with older devices that lack these features will not be able to take advantage of passkey cross-platform authentication (hybrid transport), creating a digital divide based on hardware limitations.

7.3 Inconsistent User Behavior

User behavior can be unpredictable, and reliance on users to perform specific actions like scanning a QR code or enabling Bluetooth can introduce user errors. For instance, Bluetooth can sometimes be seen as a UX challenge due to pairing issues, discovery problems, and general user mistrust of wireless technologies for secure transactions.

7.4 Developer Adaptation

Developers face the task of constantly updating and maintaining systems to support the latest authentication methods. Integrating passkey cross-platform authentication (hybrid transport) into existing systems requires developers to stay abreast of new standards, adopt new APIs, and ensure backward compatibility, which can be resource-intensive and time-consuming.

7.5 Creating New Passkeys

For every new device or subsequent login request, a new passkey needs to be created if not using a synced cloud account like iCloud Keychain or a password manager. This could add complexity to the user experience and may create frustration if users are not familiar with the process or if it is not made intuitive.

7.6 Educating Users

There is an inherent need for user education when implementing new security methods like passkey cross-platform authentication (hybrid transport). Ensuring that users understand how to use QR codes and Bluetooth securely requires clear communication and possibly extensive customer support.

While passkey cross-platform authentication via QR code and Bluetooth (hybrid transport) presents a significant advancement in authentication technology, these potential disadvantages highlight the need for user-friendly design, robust support systems, and a gradual, well-communicated transition from traditional methods to innovative ones. As with any technological shift, balancing the innovations benefits with its challenges will be key to successful implementation and widespread user acceptance.

8. Real-Life Test: Hybrid Transport Passkey Behavior

As a disclaimer: we are ignoring hardware security keys (e.g. YubiKeys) in the following test and only use platform authenticators which are built into the devices (e.g. Face ID, Touch ID, Windows Hello). In case of hardware security keys (e.g. YubiKey), the values for transports would be usb or nfc for instance.

Were using the following device / browser combinations and the Passkeys Debugger to test the behavior. Android is not considered as Android cannot serve as a cross- platform authentication (hybrid transport) client (see table above):

To test the behavior, we create for each combination a new passkeys with the following properties:

• userName: alex muller (no influence in this test)
• authenticatorAttachment: platform (as we want to exclude hardware security keys like YubiKeys)
• residentKey: preferred (no influence in this test)
• userVerification: preferred (no influence in this test)
• attestation: none (no influence in this test)
• hints: empty (see explanation below)
• usePRF: no (no influence in this test)

After the successful creation of the passkey, we then modify the input the allowCredentials WebAuthn server property and initiate a login request. We want to mimic a deleted passkey on the device where we created the passkey, so that the device / browser looks for another device that can provide a passkey via QR code / Bluetooth. Therefore, we change the credential ID and assign the value CHANGED-ID, so that a matching fails. Moreover, we change the transports property of a WebAuthn credential in allowCredentials and assign for each device / browser combination the following values:

1. transports: [internal, hybrid]: Passkeys can be used from the platform authenticator (e.g. Face ID, Touch ID, Windows Hello) or via cross-platform authentication
2. transports: [internal]: Passkeys can be used from the platform authenticator (e.g. Face ID, Touch ID, Windows Hello)
3. No transports property set: default behavior which gives no restrictions

In the WebAuthn testing site, there is also the new WebAuthn Level 3 feature for user agents hints provided. This feature can improve the user experience if the relying party has certain assumptions about how the login request can be completed in the most user-friendly way. In this test, we disregarded this feature as its not rolled out yet. Please have a look at the specifications for more details.

8.1 Windows 11 23H2 + Chrome 119

8.1.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.1.2 transports: [internal]

Quite confusingly, the QR code is also displayed here, even if we only allow for internal credentials. We couldnt find a valid reason for this behavior.

8.1.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

For some reason, parts of the modal appears in German, which is one of the installed languages.

8.1.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Windows Hello, via QR code, via known devices and via hardware security keys.

8.2 Windows 11 23H2 + Edge 119

8.2.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.2.2 transports: [internal]

Quite confusingly, the QR code is also displayed here, even if we only allow for internal credentials. We couldnt find a valid reason for this behavior.

8.2.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

For some reason, parts of the modal appears in German, which is one of the installed languages.

8.2.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Windows Hello, via QR code, via known devices and via hardware security keys.

8.3 Windows 11 23H2 + Firefox 119

When creating the passkey, we received the following error (still a passkey was created):

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

8.3.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.3.2 transports: [internal]

Quite confusingly, the QR code is also displayed here, even if we only allow for internal credentials. We couldnt find a valid reason for this behavior.

8.3.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

For some reason, parts of the modal appears in German, which is one of the installed languages.

8.3.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Windows Hello, via QR code, via known devices and via hardware security keys.

8.4 macOS Ventura + Chrome 119

8.4.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user). Moreover, you can directly select one of the known devices to use a passkey from there.

The modal is quite different to the pendant on Windows in Chrome 119.

8.4.2 transports: [internal]

This is an expected behavior, as we only allow to use internal passkeys but cannot find an internal credential on the device (we are not allowed to use hybrid passkeys). The passkey authentication fails in this step and in real-life implementations, you would need to provide a fallback authentication method.

8.4.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator. Moreover, you can directly select one of the known devices to use a passkey from there.

The modal is quite different to the pendant on Windows in Chrome 119.

8.4.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Touch ID, via QR code, via known devices and via hardware security keys.

8.5 macOS Ventura + Safari 16.6

8.5.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.5.2 transports: [internal]

Quite confusingly, the QR code is also displayed here, even if we only allow for internal credentials. We couldnt find a valid reason for this behavior.

8.5.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.5.4 Empty allowCredentials

As expected, most forms of passkey authentication are allowed: via Touch ID, via QR code and via hardware security keys. For some reason know devices are not displayed.

8.6 iOS 17.1 + Chrome 119

8.6.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.6.2 transports: [internal]

Quite confusingly, the QR code is also displayed here, even if we only allow for internal credentials. We couldnt find a valid reason for this behavior.

8.6.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.6.4 Empty allowCredentials

As expected, most forms of passkey authentication are allowed: via Face ID, via QR code and via hardware security keys. For some reason know devices are not displayed.

8.7 iOS 17.1 + Safari 17.1

8.7.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.7.2 transports: [internal]

Quite confusingly, the QR code is also displayed here, even if we only allow for internal credentials. We couldnt find a valid reason for this behavior.

8.7.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.7.4 Empty allowCredentials

As expected, most forms of passkey authentication are allowed: via Face ID, via QR code and via hardware security keys. For some reason know devices are not displayed.

In the following, for Windows 10 devices, we decided to go one level further and analyze how the behavior looks like if Bluetooth is disabled or not available at a Windows 10 machine in general. In particular for older desktop devices, this is still a very common scenarios as these devices often do not have a Bluetooth module, thus making cross-platform authentication via QR code and Bluetooth impossible.

8.8 Windows 10 21H2 + Chrome 119

8.8.1 Bluetooth Enabled

8.8.1.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to use the passkey on another device (as the system knows that there exists a passkey for this user - first screenshot) or choose to scan the QR code (second screenshot).

8.8.1.2 transports: [internal]

Quite confusingly, you are prompted to enter your Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.8.1.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.8.1.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Windows Hello, via QR code, via known devices and via hardware security keys.

8.8.2 Bluetooth Disabled

8.8.2.1 transports: [internal, hybrid]

This is a really confusing message for users, as it's not explicitly stated what they should do and how they can authenticate. The only option they have is to click on "Cancel", making this scenario a deadend.

8.8.2.2 transports: [internal]

This behavior is the same to the case where Bluetooth is enabled. It's very confusing thate the users is prompted to enter the Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.8.2.3 No transports property set

No local passkey matches, so the only option you have is to use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.8.2.4 Empty allowCredentials

Passkey authentication is only possible via Windows Hello and hardware security keys.

8.9 Windows 10 21H2 + Edge 119

8.9.1 Bluetooth Enabled

8.9.1.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.9.1.2 transports: [internal]

Quite confusingly, you are prompted to enter your Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.9.1.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.9.1.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Windows Hello, via QR code and via hardware security keys. For some reason, known devices are not displayed.

8.9.2 Bluetooth Disabled

8.9.2.1 transports: [internal, hybrid]

This is a really confusing message for users, as it's not explicitly stated what they should do and how they can authenticate. The only option they have is to click on "Cancel", making this scenario a deadend.

8.9.2.2 transports: [internal]

This behavior is the same to the case where Bluetooth is enabled. It's very confusing thate the users is prompted to enter the Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.9.2.3 No transports property set

No local passkey matches, so the only option you have is to use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.9.2.4 Empty allowCredentials

Passkey authentication is only possible via Windows Hello and hardware security keys.

8.10 Windows 10 22H2 + Chrome 119

8.10.1 Bluetooth Enabled

8.10.1.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.10.1.2 transports: [internal]

Quite confusingly, you are prompted to enter your Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.10.1.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.10.1.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Windows Hello, via QR code and via hardware security keys. For some reason, known devices are not displayed.

8.10.2 Bluetooth Disabled

8.10.2.1 transports: [internal, hybrid]

This is a really confusing message for users, as it's not explicitly stated what they should do and how they can authenticate. The only option they have is to click on "Cancel", making this scenario a deadend. For some reason, parts of the Windows Security modal are also displayed in German (a second language installed on this device).

8.10.2.2 transports: [internal]

This behavior is the same to the case where Bluetooth is enabled. It's very confusing thate the users is prompted to enter the Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.10.2.3 No transports property set

No local passkey matches, so the only option you have is to use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.10.2.4 Empty allowCredentials

Passkey authentication is only possible via Windows Hello and hardware security keys.

8.11 Windows 10 22H2 + Edge 119

8.11.1 Bluetooth Enabled

8.11.1.1 transports: [internal, hybrid]

As expected, no local passkey matches, so its suggested to scan the QR code and use the passkey on another device (as the system knows that there exists a passkey for this user).

8.11.1.2 transports: [internal]

Quite confusingly, you are prompted to enter your Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.11.1.3 No transports property set

No local passkey matches, so its suggested to scan the QR code or use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.11.1.4 Empty allowCredentials

As expected, all forms of passkey authentication are allowed: via Windows Hello, via QR code and via hardware security keys. For some reason, known devices are not displayed.

8.11.2 Bluetooth Disabled

8.11.2.1 transports: [internal, hybrid]

This is a really confusing message for users, as it's not explicitly stated what they should do and how they can authenticate. The only option they have is to click on "Cancel", making this scenario a deadend.

8.11.2.2 transports: [internal]

This behavior is the same to the case where Bluetooth is enabled. It's very confusing thate the users is prompted to enter the Windows Hello PIN code (or fingerprint / face scan if set up on the device), even though we changed the credential ID (so it should actually not find the credential as it's not specified in the allowCredentials property). However, after submitting the Windows Hello PIN code, an error is thrown: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." From a user perspective, this is a rather confusing behavior but makes sense as it could provide information about the users passkeys without user consent.

8.11.2.3 No transports property set

No local passkey matches, so the only option you have is to use a hardware security key (e.g. YubiKey) / cross-platform authenticator / roaming authenticator.

8.11.2.4 Empty allowCredentials

Passkey authentication is only possible via Windows Hello and hardware security keys.

9. Recommendations for Developers

9.1 Implementation Tips

• Use libraries and frameworks that abstract some of the complexities of the pure WebAuthn API.
• Consider cross-platform authentication scenarios from the start to ensure a broad user base can benefit from your passkey implementation. Depending on your design choices, you can also offer alternative login methods in these scenarios.
• Develop fallback mechanisms for scenarios where passkey cross-platform authentication (hybrid transport) might not be possible due to device limitations.
• The biggest design decision is to decide if you want to promote cross-platform passkey authentication via QR code / Bluetooth (hybrid transport) and make it a prominent method for passkey authentication or use hints to not promote it actively. In the latter case, its always tried to immediately use the internally stored passkeys and only if no internal passkey is found, a QR code for cross-platform authentication (hybrid transport) is displayed. This needs to be defined in your WebAuthn server options in the excludeCredentials and allowCredentials properties. In the excludeCredentials property of your WebAuthn server, you can see transport information about already created credentials. In the allowCredentials property, you can specify the behavior in the login process (see tests above).
• Moreover, you cannot prevent cross-platform passkey authentication (hybrid transport) entirely (see the tests above with transports: [internal]), so you need to be prepared that your users will find this method and will have questions. The occurrence of this cross-platform authentication (hybrid transport) will occur in particular if users start to delete passkeys locally.

9.2 Educational Strategies

• Create comprehensive guides and tutorials that walk users through the passkey cross-platform authentication (hybrid transport) process.
• Use in-app tooltips and contextual help sections to guide users during their first passkey cross-platform authentication (hybrid transport) experience.
• Provide FAQs and troubleshooting sections on your website or within the application.

9.3 Temporary Access Considerations

• Implement time-bound sessions for passkey logins via QR code or Bluetooth to ensure that access is only temporary and secure.
• Ensure that passkey cross-platform authentication (hybrid transport) doesnt undermine any existing security protocols, maintaining the integrity of user data.
• Consider the privacy implications and ensure that any temporary access granted via passkey cross-platform authentication (hybrid transport) is logged and monitored according to security best practices.

10. Conclusion: QR Code / Bluetooth Passkeys

Passkey cross-platform authentication via QR code / Bluetooth (hybrid transport) offers a balance between security and UX. However, its an entirely new process for most users and could cause many confusing situations, so need to think carefully if you want to promote it.

We hope that we could shade some light on the topic of passkey cross-platform authentication (hybrid transport) via QR code / Bluetooth, explain how to set up things and how the behavior on different device / browser combinations looks like. If you have any questions, feel to reach out to us via our passkeys community or subscribe to our passkeys Substack. Lets make the Internet a safer place by spreading passkeys.