Bitwarden Acquires Passwordless.dev

The expectation is that websites will allow you to register multiple passkeys, and that these may correspond to different devices. For instance, I may have both my iPad, android phone and windows desktop registered as three separate passkeys on an account.

There is a cross device flow that works across ecosystems, based on QR codes and wireless proximity. So the expectation is that websites could (if they desire) see that you authenticated using your phone onto your Windows Hello capable desktop, and ask if you want to register a new passkey from your Windows desktop to make things more convenient in the future.

Before platforms added backup to cloud sync fabric, you would lose your credentials when you lost your security keyfob or upgraded your phone. It was a user's responsibility to register additional credentials, such as remembering to go back after-the-fact to use a security key they kept at home in their firesafe to register their 'backup' credential.

This strong hardware binding made it more useful for secure environments (which typically have MFA requirements and staff dedicated to account recovery) and a lot less useful for consumer environments (which want to prevent breaches but not at the expense of additional user friction or support costs)

Web Authentication is effectively saying to let the user utilize whatever they want to authenticate, and let a relying website determine how to react to the capabilities or limitations of that choice. What is considered a capability or liability will depend on the particular deployment business requirements, and that will determine how they adapt. For example, an enterprise might decide to just reject everything except the exact security key they issued to an employee or contractor. For most other verticals, that is not a viable strategy.

Unfortunately no. A passkey is a registered credential that supports user verification and discoverability, to support a usernameless and passwordless authentication experience.

U2F did not support either of these capabilities, and was only meant to be used for second factor authentication after a traditional authentication (e.g. username/password).

So a website which wants the passkey capabilities in order to provide a particular user experience is not going to be able to accept U2F devices - unless they provide those users an alternative experience. There may simply not be enough U2F devices in active use for many sites to justify that.

Newer Yubikeys which support CTAP 2.0 or later can generate "single device passkeys" for websites. The "single device" is meant to indicate that there is no backup capability, and losing that keyfob will lose the ability to authenticate using that mechanism. Web Authentication Level 3 describes this capability to websites, as they may this information to determine whether to offer a user any sort of 'account security upgrade' that removes passwords and/or site-provided recovery mechanisms.

Since discoverable credentials require storage inside the security key, the newer the keyfob is the more robust it is likely to be. It is even possible that some security keys may support some form of optional backup and recovery in the future (e.g. you could imagine a system with factory-paired keys packaged together, and a software agent that exports/imports that encrypted data)

> Or are MS+Google+Apple doing an "embrace, extend and extinguish" on webauthn?

I don't think any of them have a goal to reduce a diverse selection of webauthn authenticators. However, platform support does implicitly affect that ecosystem, because the shipped default is what most people will want to use.

The platforms may want to focus on a particular set of features, so this diversity plays to their benefit - I suspect at least some of the platform vendors want to point to the existence of a FIPS-certified Yubikey such that they don't need to implement such behavior themselves.

> Are the "small adjustements that ever so slightly reduces the security" sufficient to effectively kick security keys hardware vendor out of the game?

Leaving the remark about older security protocols not supporting the usability features - I think (and hope) there will be a place for hardware vendors to provide products and services to meet the needs of companies that platform vendors simply won't want to (or won't commit to on a reasonable schedule).

The hardware vendors may see consumer sales drop with the new alternatives, or may grow due to a significant increase in consumer understanding of what their hardware uniquely provides and in where their hardware can be used.

Passkeys don't rely on this mechanism (although being able to authenticate your desktop using your cellphone is a very valuable user experience!)

This upcoming mechanism is also meant to be used between platforms (or at least, a platform and an extremely robust authenticator). It is not meant to be used by a website or native application which want to just rely upon/consume credentials. If the browser/platform supports this mechanism, it will be presented to the user as a choice of how to authenticate.

But any level of that may take responsibility - for instance, 1Password and Dashlane replace the browser/platform support by default by altering the implementation of the javascript API via their Web Extensions.

There are ramifications to this approach, such as having to fall back to the browser/platform UX to support hardware security keyfobs.

The platforms (and browsers using their API) also support or plan to support a cross-device option, where you should be able authenticate within a desktop browser using your cellphone via QR code and radio proximity checks. The vision is that some websites will see that the location browser _could_ have supported authentication directly, and offer to help the user register it as a second (more convenient) option.

Until recently I was using it for two different accounts in the same 1Password business account, one account enabled with integration to the desktop app and a second account on another browser profile (for admin purposes) with just the browser extension.

Neither of those necessitated logging in again in another tab.

Still using 1Password, but Firefox containers have removed the need for multiple Firefox profiles.

For a second business I use Bitwarden, and that works well, but I find 1Password superior in so many respects.