[UX] Account creation: Create Passkey re-enabled when password is valid #431

New issue

Closed

opened 2026-05-21 11:14:30 -05:00 by spin-drift · 2 comments

spin-drift commented

2026-05-21 11:14:30 -05:00

(Migrated from github.com)

In the user signup screen, the following behavior is observed:

Password field has characters	Password valid	Can create passkey
❌		❌
✅	❌	❌
✅	✅	✅

I believe this is because the Passkey button is grayed-out when the form is in an "invalid" state. Following this logic, a valid password will then re-enable the Passkey button.

I think it would be less confusing to users if either:

The Passkey button was disabled whenever the password field has characters, regardless of whether or not it's valid.
Having a valid password and then clicking Passkey would both register a passkey AND password, since they typed it out. Perhaps the button/interface could change to reflect that they will both be creating a password and registering a passkey.

2 is definitely the harder and possibly more confusing option, so 1 should suffice.

Or, perhaps, registering a password and a passkey both could be considered mutually exclusive options that simply show the respective auth method has been registered, with a "Finish" button required to actually complete the flow.

This way, users who intend to login on multiple devices won't have to go back and create a password if they register a passkey first.

I haven't tested this yet, but I also imagine it can be tricky if users try to sign in on a device that doesn't support passkeys, but where it's their only auth method. This would make the "best UX" option registering a password first, then a passkey later, which could be an antipattern from a security standpoint.

Sorry for the ticket ramble. :) Thanks!

In the user signup screen, the following behavior is observed: |Password field has characters|Password valid|Can create passkey| |---|---|---| |❌||❌| |✅|❌|❌| |✅|✅|✅| I believe this is because the Passkey button is grayed-out when the form is in an "invalid" state. Following this logic, a valid password will then re-enable the Passkey button. I think it would be less confusing to users if either: 1. The Passkey button was disabled whenever the password field has characters, regardless of whether or not it's valid. 2. Having a valid password and then clicking Passkey would both register a passkey AND password, since they typed it out. Perhaps the button/interface could change to reflect that they will both be creating a password and registering a passkey. 2 is definitely the harder and possibly more confusing option, so 1 should suffice. Or, perhaps, registering a password and a passkey both could be considered mutually exclusive options that simply show the respective auth method has been registered, with a "Finish" button required to actually complete the flow. This way, users who intend to login on multiple devices won't have to go back and create a password if they register a passkey first. I haven't tested this yet, but I also imagine it can be tricky if users try to sign in on a device that doesn't support passkeys, but where it's their only auth method. This would make the "best UX" option registering a password first, then a passkey later, which could be an antipattern from a security standpoint. Sorry for the ticket ramble. :) Thanks!

notquitenothing commented

2026-05-23 00:37:48 -05:00

(Migrated from github.com)

Thank you for opening an issue! I will update the logic so that the Signup and Signup with Passkey buttons on the registration page have separate enable/disable logic. This is not one of the listed options, but I think it will solve the immediate problem of not being able to register a passkey without a valid password entered, which makes no sense.

Thank you for opening an issue! I will update the logic so that the `Signup` and `Signup with Passkey` buttons on the registration page have separate enable/disable logic. This is not one of the listed options, but I think it will solve the immediate problem of not being able to register a passkey without a valid password entered, which makes no sense.

spin-drift commented

2026-05-29 02:21:20 -05:00

(Migrated from github.com)

Closing cuz fix has been merged!