One of the next frontiers as a barrier to browser switching will be "software"-backed WebAuthn/FIDO2/"passkeys".
If you look at the APIs available on MacOS/iOS at present [0], and how WebAuthn works, you need to "trust" the client-side software to correctly identify the site origin (i.e. protocol, domain, port) and pass it to a physical security key. In the case of a software token, you need to restrict which app(s) can pass this information through to the system carrying out authentication.
The end result right now, as I can see it, is that if you sign up to a website using a "passkey" via Safari (for example), there is no real supported workflow that isn't site-specific, for migrating to a new browser - you are effectively beholden to Apple's keychain for getting you back into that site.
If you want to enrol a new device (say an Android phone using its own software implementation of WebAuthn), you would need to find a way to sign into your old account (which requires your MacOS/iOS passkey to log in), then enrol your Android device (which is a separate physical device). You'll likely get stuck here.
An expert user could add a physical FIDO2 token to their account from the old device (Safari), and use that as the authenticator to log in on the new device, but this is significant friction for a non-technical user.
While moving users away from passwords might make sense, I do think we'll see these "passwordless" authentication mechanisms become the next major point of friction in user browser choice. Even if you can implement WebAuthn in your rival browser, unless you get access to the system key store, you won't be able to let users sign in. That will prevent them switching.
[0] https://developer.apple.com/documentation/xcode/supporting-a...
If you look at the APIs available on MacOS/iOS at present [0], and how WebAuthn works, you need to "trust" the client-side software to correctly identify the site origin (i.e. protocol, domain, port) and pass it to a physical security key. In the case of a software token, you need to restrict which app(s) can pass this information through to the system carrying out authentication.
The end result right now, as I can see it, is that if you sign up to a website using a "passkey" via Safari (for example), there is no real supported workflow that isn't site-specific, for migrating to a new browser - you are effectively beholden to Apple's keychain for getting you back into that site.
If you want to enrol a new device (say an Android phone using its own software implementation of WebAuthn), you would need to find a way to sign into your old account (which requires your MacOS/iOS passkey to log in), then enrol your Android device (which is a separate physical device). You'll likely get stuck here.
An expert user could add a physical FIDO2 token to their account from the old device (Safari), and use that as the authenticator to log in on the new device, but this is significant friction for a non-technical user.
While moving users away from passwords might make sense, I do think we'll see these "passwordless" authentication mechanisms become the next major point of friction in user browser choice. Even if you can implement WebAuthn in your rival browser, unless you get access to the system key store, you won't be able to let users sign in. That will prevent them switching.
[0] https://developer.apple.com/documentation/xcode/supporting-a...