The solution to most of the author's criticisms lies in not forcibly mixing Passkeys and WebAuthn-based 2FA.
As long as you are satisfied with passkeys being "usernameless" (i.e. discoverable), you can offer a nice login flow with a "Sign in with a passkey" button and Passkey Autofill.
For 2FA use cases, you should provide a second WebAuthn configuration that does not require discoverable credentials, for example, and does not necessarily require user verification.
This allows a user to have both fully-fledged passkeys and, for example, security keys as a second factor to secure username/password-based login.
Users can choose what they want to do (create a passkey on e.g. iCloud or add security keys as 2FA without using precious key storage resources on the hardware tokens).
GitHub has done a very solid implementation of that model, and we are working on adopting it to our services and it's looking very good so far.
As long as you are satisfied with passkeys being "usernameless" (i.e. discoverable), you can offer a nice login flow with a "Sign in with a passkey" button and Passkey Autofill.
For 2FA use cases, you should provide a second WebAuthn configuration that does not require discoverable credentials, for example, and does not necessarily require user verification.
This allows a user to have both fully-fledged passkeys and, for example, security keys as a second factor to secure username/password-based login. Users can choose what they want to do (create a passkey on e.g. iCloud or add security keys as 2FA without using precious key storage resources on the hardware tokens).
GitHub has done a very solid implementation of that model, and we are working on adopting it to our services and it's looking very good so far.