Hi, we recently had a call with Yubico iterating over https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/220 and there are a few things which are FreeIPA related, so I'm creating this ticket on Dave Pham behalf (I'll share the link with him so he can follow up here if necessary).

Authentication:

• When an incorrect PIN is entered, the system appears to recycle the error message reserved for passwords. i.e. “Sorry, password authentication didn’t work. Please try again.” This should be reworked so that PIN attempt failures are distinct from password failures as they are entirely different flows.

• The defined standard for the number of FIDO2 incorrect PIN attempts is 8, i.e. a user can attempt to enter their PIN 8 times the passkey device is locked. As such, this number is quite important for the user to be cognizant of and must therefore be displayed clearly within the UI. Ideally, this should also include the current attempt number in addition to the amount of remaining attempts the user still has available. Further, having the final attempt highlighted with something different such as a prominent warning “Hey, you have 1 attempt left before your passkey will be blocked!” in a red box or text will help emphasise the importance of getting the PIN correct and the consequence of failing.

• Nowadays, it may even be optimal to divide the number of PIN attempts into chunks (e.g. 3 attempts, then 3 additional attempts, and then 2 final attempts). Arguably this was inherited because of legacy password behavior (which generally allows 3 attempts) but is something to consider in order to make transitioning users feel more familiar with the UX, so perhaps consider grouping the failure attempts accordingly.
  Although not recommended from a security purist point of view, it may be possible to have a passkey device registered without a local PIN securing the credential. This means when prompted for a PIN by the system, the user could theoretically press enter to skip the PIN entry and proceed with the user presence testing flow of touching their security key. Currently, it appears that when a null PIN is entered, the system will fall back to password and abandon the passkey flow.

• There needs to be very clear and distinct text to instruct the user to "touch the passkey device" when performing user presence testing. Currently, the passkey device will flash but there is no on-screen prompt to denote this.

• All text for requesting information/providing instructions should be moved below the text input box instead of being inside it. This solves the problem of text being truncated, having the cursor obstruct the text or having the user's text hide the original instructions

Registration and Recovery:

• From Yubico's testing of Fedora, registration takes place by generating a private/public pair on-device, and then simply pasting the public key into a text box within the user management function of FreeIPA. This is clearly not the ideal UX for most users, especially in a corporate setting where all registration must then happen centrally by an IT or Security Admin (since users won't have access to the user management function).

• Registration should be presented as a clear flow within the UX as a visual flow, where a user can nominate their device, present their device, and the system should then obscure the actual key generation and copying of the public key. This includes the process that can also be performed via the CLI.

• Information about the need to register 2 or more devices to their account as backup should be highlighted during registration (and perhaps even during authentication if only a single device is registered), as this will help future issues of recovery.

• Speaking of which, recovery is a complicated facet of passkeys, and both Yubico and the FIDO alliance generally have not found an optimal solution across all scenarios. Falling back to password is weak and vulnerable to "fall back attack", but sending out a magic link or SMS is not magnitudes better either as these can be phished relatively easily. The safest way is for users to have two or more passkey devices registered, and then falling back to one of those if the primary is lost. This means that a user should be able to always rename existing and current passkeys registered on their account, to help them identify and manage their options. Users typically use the labels to either describe their device (e.g. Red YubiKey) or to specify the make and model of their device (e.g. YubiKey 5C NFC).

• Further, the system should block attempts to remove a passkey if there is only one. i.e. If the user has 2 or more passkeys registered, then the system should allow their removal up to the last passkey as there must always be an option to login.'

Management:

• There are many extensions supported by passkeys, such as "discoverable credentials" and biometric. It would be great for UX to have these (and more) added as support to allow user's more authentication options