Client UI/UX in regards to using security keys.

[My1]

Hi again,

we REALLY gotta talk about how hard it has become to use FIDO2 Sticks even if you want to (or a service requires them) rather than platform or phones or password managers, or anything else I might have forgotten.

Several combination need you to go through a bunch of steps that are not immediately obvious that they exist without prior knowledge, and some even require you to actively make steps that are quite literally against what anyone would assume, like clicking CANCEL.

1) if you are on windows 10 and use a chromium-based browser, and have bluetooth if you cannot use windows hello (either due to restriction by the relying party or not having it set in the first place), it will show a dialog like this:

(ref: attachment chrome-passkey-phone.png)

just store the passkey on phone with NO INDICATION AT ALL that you even can use a FIDO2-Stick, here you have to click the "back" button at the bottom left to get a choice dialog between External or phone.

2) no preference set by the RP, Windows hello active on Windows 10, you get this absolute beauty

(ref: attachment W10-Winhello.png), where you need to click CANCEL

3) Macos, a Browser that is not Safari, you get this dialog if there is no specific preference, where you also need to click cancel

(ref: mac-passkey-altbrowser.png)

4) with safari it is ever so slightly better, offering a "more options" button, but still why doesnt it ask where to store directly?

These are just some of the worst that I aware of, there are easily more especially with password manager extension hijacking the request even if e.g. cross-platform has been set or Browsers' own password/passkey managers, such as chrome.

[Chad Spensky]

Unfortunately, I don't think there is much discussion to be had here. The consensus appears to be that synced passkeys, stored in insecure password managers, are the only passkeys that matter.  The more secure hardware tokens and device-bound keys appear to be considered deprecated. Pretty sad to see.

I thought it was clear that password managers were a dangerous temporary solution and that we needed to move away from them. However, we have succeeded in making them even more dangerous by storing private keys in them...

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNoh34r4zRq019AXfzm-Xef-irKG1jEE3cfRsJCUu97UMw%40mail.gmail.com.

--

www.allthenticate.com

Chad Spensky, Ph.D.  Founder and CEO M: (601) 80-31337 Houston, TX 77002

The content of this email was 100% human generated 🧑‍💻

[Tim Cappalli]

Hey Chad - Obviously everyone’s opinions are welcome but maybe don’t make general, misleading statements about an ecosystem that you clearly don’t understand and which you seek to profit off with your company. Very disappointing to see this FUD inducing rhetoric from a FIDO Alliance member company. 

@My1 there’s been significant work in this space recently, including preventing RPs from being able to completely exclude security keys. The reality is that most devices operate in a consumer context by default, the vast majority of consumers don’t use hardware security keys as their passkey credential manager, and  extensive user research shows that showing the security key option by default is very confusing to them causing them to abandon the ceremony. We’re working to best balance the needs of most users with the needs of those requiring device-bound passkeys in hardware authenticators.

Tim

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAPkAZdyS3Lz%2Bi_i%3DpsbdTeRq6SanUzoJ7L8BrAPp%3DGx6Z%3DxX9A%40mail.gmail.com.

[عا بد‎]

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/DS0PR13MB6276D6730097502122551DEFA008A%40DS0PR13MB6276.namprd13.prod.outlook.com.

[Claude Robitaille]

While this thread focuses on physical security keys, I'd like to address the broader UI/UX challenges we're facing with passkey adoption.

The core issue is a fundamental mismatch between authentication ceremony design and user mental models. Current FIDO implementations, shaped by security requirements and browser ecosystems, create experiences that feel disconnected from the user's primary context—the web application they're actually trying to use. The case with the physical key is simply one of such situations.

When users are signing into an application, they're focused on that specific service and their relationship with it. However, the current approach pulls them into generic authentication flows that often feel foreign, confusing and / or imcomplete. This context switching disrupts the user's natural workflow and creates friction.

The web application possesses crucial contextual information—user history, subscription status, onboarding state—that could significantly improve the authentication experience. Unfortunately, security boundaries prevent this contextual data from informing the authentication ceremony, leaving generic systems to make assumptions without full knowledge of the user's situation.

I'm not advocating for web applications to have complete control over authentication flows. Rather, I'm suggesting that completely isolating them from the process contributes to the current adoption challenges we're seeing with passkeys. The lack of contextual integration, regardless of how much user research we conduct, will always limit our ability to create truly intuitive experiences.

This disconnect between security requirements and user experience design may be one factor limiting broader passkey adoption. Finding ways to better integrate contextual information while maintaining security boundaries could help bridge this gap.

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAOEhFagKUV%3DO%3Dm%2B0psW6_DDnae_4VxB8RmDv%2BMVpMPtWY0jDFw%40mail.gmail.com.

[Arshad Noor]

Claude,

The arguments you make for UI/UX is the precise reason why FIDO has
become THE most confusing and convoluted authentication systems in the
world. And, I come from nearly 3 decades of PKI experience and can speak
volumes about how the PKI industry messed that ecosystem up.

I'm not sure how long you've been following the FIDO ecosystem, but
there was a time - nearly a decade ago - when the web application had
complete control over the authentication flow for one simple reason:
there was only a physical Security Key to interact with, over USB, and
only one browser supported that (Chrome); as a result, the web
application had to take control over the authentication flow (we will
ignore FIDO UAF here, since it was never intended for use with browsers).

When Mozilla built support for FIDO, they went along with that notion:
a browser, a web application and a Security Key - they would make
authentication *simpler and stronger*.

But, you have to understand that the comparative statement was not just
comparing FIDO with passwords - that was shooting fish in a barrel; it
was also addressing the complexity of the strongest passwordless
authentication protocol in the world for web applications: TLS Client
Authentication (aka ClientAuth) - with digital certificates + smartcards
+ reader + middleware software.

Things were going well for a while until Microsoft joined the alliance.
Since they owned the browser platform where some of the world's largest
PKIs for authenticating humans (US Government, DoD, National ID cards in
many countries, etc.) were used, the protocols could no longer be
defined within the FIDO Alliance - the web API had to be standardized at
the W3C, independently and in an abstract manner. That's when things
started going downhill.

The web application lost control since it could no longer depend on the
browser interacting with a Security Key over USB - it had to deal with
the TPM, smartcards and other devices that worked over Bluetooth, NFC,
etc. To make matters worse, the people who convoluted X.509 brought
"extensions" to FIDO!

There is a thread somewhere in the WebAuthn forum where (based on my PKI
experience) I argued for keeping things simple in WebAuthn, and for it
focus on just the core authentication protocol. Engineers from Google,
Microsoft and Mozilla concurred with me - but things are never quite so
simple in the "standards" world.

I won't bore you with how Apple was the last platform vendor to join the
FIDO Alliance - and initially, create a solid implementation that worked
with Security Keys - but then flipped and chose to go with synchronized
passkeys, ignoring Security Keys and the TPM completely (not surprising).

So, here we are today. The web application completely lost control
because some factions were simply not satisfied with the fact that
billions of people were already familiar with smartcards, and could have
been trained to extend that knowledge to working with Security Keys -
including two of them (for account recovery). UI/UX became central to
the experience of working with "passkeys".

The world is very different today. With more than 75K data breach
notifications, and 9.4B+ users' PII compromised
(https://privacyrights.org/data-breaches), business models in some
quadrants of the internet only provide lip-service about security and
privacy - their business models are designed to get users on-boarded
instantly and keep them "engaged" to sell advertising and the users'
information. Some of us are simply trying to deliver on the original
promises of PKI and FIDO: to keep systems secure and information private
(recognizing that you cannot make an omelette without breaking eggs).

Arshad Noor
StrongKey

> <mailto:bd72...@gmail.com>> wrote:‬
>
>
>
> في الجمعة، ١٢ سبتمبر ٢٠٢٥، ٥:٥٢ م 'Tim Cappalli' via FIDO Dev (fido-

> dev) <fido...@fidoalliance.org <mailto:fido...@fidoalliance.org>> كتب:

>
> Hey Chad - Obviously everyone’s opinions are welcome but maybe
> don’t make general, misleading statements about an ecosystem
> that you clearly don’t understand and which you seek to profit
> off with your company. Very disappointing to see this FUD
> inducing rhetoric from a FIDO Alliance member company.
>
> @My1 there’s been significant work in this space recently,
> including preventing RPs from being able to completely exclude
> security keys. The reality is that most devices operate in a
> consumer context by default, the vast majority of consumers
> don’t use hardware security keys as their passkey credential
> manager, and  extensive user research shows that showing the
> security key option by default is very confusing to them causing
> them to abandon the ceremony. We’re working to best balance the
> needs of most users with the needs of those requiring device-
> bound passkeys in hardware authenticators.
>
> Tim
>

> *From: *'Chad Spensky' via FIDO Dev (fido-dev) <fido-
> d...@fidoalliance.org <mailto:fido...@fidoalliance.org>>
> *Date: *Friday, September 12, 2025 at 10:33
> *To: *My1 <teamhyd...@gmail.com
> <mailto:teamhyd...@gmail.com>>
> *Cc: *FIDO Dev (fido-dev) <fido...@fidoalliance.org
> <mailto:fido...@fidoalliance.org>>
> *Subject: *Re: [FIDO-DEV] Client UI/UX in regards to using

> dev+uns...@fidoalliance.org <mailto:fido-
> dev+uns...@fidoalliance.org>.

> To view this discussion visit https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/CACHSkNoh34r4zRq019AXfzm-

> Xef-irKG1jEE3cfRsJCUu97UMw%40mail.gmail.com <https://
> groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/
> CACHSkNoh34r4zRq019AXfzm-Xef-
> irKG1jEE3cfRsJCUu97UMw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
>

[My1]

Hi everyone,

sorry for my late reply, my gmail filters sorted this thread kinda away into my password emails, lol, so I'll kinda address everyone with this, a bit long response.

@tim

The most "fun" part is that I know of an RP that would like to exclude any passkey that ISNT on a security key and does so via attestation and users always fall into the trap of trying to register their computer or whatever. partly that is because they havent got the line that they need to set cross platform but even if they did, phone passkeys still get offered first on some combinations, especially with windows 10 (as mentioned in the first post), which can be severely annoying.

I wouldnt even say you have to set a default, but just a simple "where do you want to store" dialog right from the start which could offer any local password managers, your phone and the obvious option for external USB/NFC/BT FIDO Devices depending on what the platform supports (I made a lil mockup, see attachment).

Granted the windows 11 prompt if you havent prepared windows hello is the closest to what I think as it straight asks: phone or security key without being forceful or heavy handed on one option (I dont remember how they had it if you DO have win hello tho and dont set a preference).

One problem some Relying Parties need to solve tho is

1) the inability to have multiple passkeys, like seriously they take like less than 1KB each and that's a generous estimate, one should at least allow like 10 or so for each user, even more if you intend platform passkeys (paypal for example, while they only do u2f-style, it still isnt great to only be able to have one single key)

2) even if you can do multiple passkeys, the inability to distinguish them, by either assigning generic names that you cannot change or no name at all. (sony for example, see attachment)

that shows that not onl platform holders but even relying parties seem to be not exactly looking at the whole picture, which is plain sad.

or maybe just shortcut directly to a reasonable default, like if you have a FIDO-Device connected, go for that, if you have an extra password manager, go for that, and if platform is available, opt for that (as the default option with an OBVIOUS option to choose a different method, that means no "cancel" or "back" bs)

@Claude Robitaille

"When users are signing into an application, they're focused on that specific service and their relationship with it. However, the current approach pulls them into generic authentication flows that often feel foreign, confusing and / or imcomplete. This context switching disrupts the user's natural workflow and creates friction."

that actually reminds me of pre-webauthn u2f, where the the websites actually gave usable instructions to users, instead of users waiting for something to happen when it says "touch your security key" which can be interpreted as (especially in translations) to touch the key on a list on the PC rather than physically with your finger.

@Arshad absolutely, with the addition of MS and also google adding platform keys on phones as well stuff went weirdly really fast.

I can understand that there needs to be some thing to make sure all is going well, and that the website cant have the entire auth flow even without non-security key storage, as FIDO2 added the PIN which definitely needs a more "impartial" interface.

Although non-synced passkeys (notably Windows Hello-based passkeys) really should stay out of the game for now at least as local-only keys create problems when computers break or you are somewhere else and need to go through a potential recovery workflow, they should always be portable in some way, either via a device you take with you or synced via an account.

@Chad while yes having passkeys on a synced account at some provider isnt exactly the best option in my book either, it does have a huge amount of convenience, a low barrier to entry and gets even better once cross-vendor transfer gets somewhere, and most importantly they are still much more secure than passwords which are often attacked in so many ways you cannot just attack passkeys with, most notably phishing, reuse of existing passwords or just weak passwords in general.

[Claude Robitaille]

Interesting "My1"

Just to add context:
1 - My RP do support multiple passkeys

2 - And it does has a way to distinguish them

BUT

Regardless of the data size you must manage the storage. How and when do I decide to prune passkeys? ATM there is 0 support from anything. And I can certainly not ask the user; this is way over his head.

To distinguish you need to have some sort of an ID. Again, you do not want to ask the user. And again there is nothing that helps this other can create a random ID in the browser's local storage. Ouch...

Claude

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNoT%3Dcr4qouRRen%3DJa8bUX6ny%2BG7T%2BLBL1ZkEMTWxKVgyg%40mail.gmail.com.

[Tim Cappalli]

I wouldnt even say you have to set a default, but just a simple "where do you want to store" dialog right from the start which could offer any local password managers, your phone and the obvious option for external USB/NFC/BT FIDO Devices depending on what the platform supports (I made a lil mockup, see attachment).

User research has consistently shown that most users will get confused by a dialog like that. 

To distinguish you need to have some sort of an ID. Again, you do not want to ask the user. And again there is nothing that helps this other can create a random ID in the browser's local storage. Ouch..

You can (and should) automatically name the credential manager for your users (and show the icon!) using the AAGUID.

How and when do I decide to prune passkeys?

In general, automatic server-side pruning isn’t necessary. You can also use the Signal API to opportunistically clean up old passkeys from the user’s credential manager. 

[My1]

@tim sure users will always be confused somehow, but literally hiding the option the user might need behind a cancel/back button, seems even more crazy at least in my eyes.

regarding pruning, I think Claude meant on the RP side rather than on the password manager side. and that's obviously a hard thing as an rp couldn't see whether a user still has access to a certain passkey just never really uses it because it's e.g. on an emergency backup stick.

@Claude yes any half decent RP does that, and most I encountered certainly do, but it's crazy when you have quite big names, especially when their logo is literally on the front page of the FIDO alliance.

regarding distinguishing, there are 2 things, 1 as Tim mentioned, the AAGUID, which can also (to a degree) identify many FIDO devices (and even if it's not in the MDS the attestation cert usually has some data you can try using, and the user should still get the option to set a name if they want to (especially if multiple similar devices are involved).

in my opinion there should be 3 or 4 data points:

1) a name the user can set freely, if they want to

2) a claimed model based on AAGUID, attestation etc.

3) time of registration

4, optional) time of last use

[Claude Robitaille]

Now, let's consider a very very very basic use case where the user, despite extensive user research, can still be confused.

On the initial Web App load on a new device, the Web App has 2 choices:

1 - Ask the user his email address and if the user has an account blindly try the passkey sign-in ceremony (assertion). At that point, the user will be asked to complete the sign-in, if indeed there is a passkey accessible somewhere (and the RP can not help since all it knows is that it is a new device, the user exists and potentially a passkey exists too but there is no way to determine if the passkey is accessible or not on the new device). This may fail or may not fail but the user will be very confused if it fails. The Web App has no clue why the failure and can not guide the user). Even worse and definitely a lot more confusing is that the user may not have used a passkey at all and does not even know what a passkey is. At that point, the Web App must go back and start the sign-on ceremony (probably via SSO).
2 - Also ask the user his email address and start some sign-on ceremony, if the user already exists, which happens outside the Web Authn realm (also probably via SSO). If the user does not already exist then a sign-up ceremony may be started (or offered).

The alternative is to ask the user by presenting all the options:
1 - Sign-in with passkey
2 - Sign-in by alternative methodology (fallback).

3 - Sign-on (and possibly sign-up).

All this is very confusing to most users.

On Sun, Sep 14, 2025 at 7:07 AM My1 <teamhyd...@gmail.com> wrote:

@tim sure users will always be confused somehow, but literally hiding the option the user might need behind a cancel/back button, seems even more crazy at least in my eyes.

regarding pruning, I think Claude meant on the RP side rather than on the password manager side. and that's obviously a hard thing as an rp couldn't see whether a user still has access to a certain passkey just never really uses it because it's e.g. on an emergency backup stick.

I was effectively talking about the RP.

[My1]

signing IN is generally a lot easier (at least when you know you are using passkeys already, and you ask for the email address) as

1) passkeys can come with transport hints and stuff

2) the client can be aware where a locally stored passkey located, and can straight skip to asking for phone or USB passkey, heck due to linux and mac not having a system intercept for FIDO sticks, chrome even does exactly this, it plonks a qr code on the screen but instructs that you can plug in a USB Security key right on that dialog, and reacts to it with no need for further interactions.

3) The RP can still see what type of passkeys the account has and what was last used in general on the account.

the hardest part is really signing UP, as there is no info the RP can access except to ask the user (where microsoft accounts even have a completely decorative but still useful asking prompt what kinda security key you are using (USB or NFC) to describe what to do before spawning the FIDO dialog)

[Claude Robitaille]

The exactly that, knowing that passkey are in use. There is nothing in local storage since I am assuming this is the first visit on a new device. The user has passkeys in other devices and hence the rp has knowledge of the user but no specific knowledge for this particular device. Can passkeys be used, ie created? Or must something (fall back) be used? Don’t know…

[My1]

sure I am not denying passwordmanager-based passkeys their existence, I can fully see that in many scenarios they are extremely useful.

the big issue is that it's extremely complicated to use FIDO sticks either because you prefer that or the service would want those because of the added security compared to synced passkey services (e.g. e-government stuff) and it's kinda crazy that even when you DO set attachment to cross-platform you need to click options that are not immediately obvious to get the browsers out from asking for phone passkeys.

this gets especially chaotic as the attachment option can allow or disallow the same synced passkey depending on whether it's stored locally or you are using a phone, which is kindan crazy.

there are really 3 types to distinguish

1) movable hardware Security Keys

2) local platform passkeys (often attested, almost dead except windows Hello)

3) synced passkeys (regardless of whether it's the platform or an extension)

Am Mo., 15. Sept. 2025 um 09:29 Uhr schrieb Peter Gutmann <pgut...@gmail.com>:

Someone pointed me to this discussion, having done a fair bit of work in security UI I thought I'd add my $0.02 (+ 40% tariff for US readers): The reason why password managers are popular isn't because of some conspiracy to block everything else but because they're the least unusable authentication mechanism out there.  Second is probably TOTP stuff like Authy (there are also very unusable TOTP implementations, UI research rates Authy as the best).  Anything involving PKI or crypto tokens or requiring cryptographic protocols is last, no matter what else you add to the list.  For example one very usable but toe-curling to crypto purists mechanism is used by some payment provider whose name I can't remember where they recognise your email address on checkout and send you an SMS to auth the payment, with no credit card details or PII being sent anywhere.  It works, it's very easy to use, and it's a lot more secure than typing your credit card details into some random web site, it just wouldn't ever get suggested by a cryptographer or security expert.

Unfortunately the response from the crypto community has been to design ever more awkward but eminently conference-paper-worthy cryptographic protocols and mechanisms for replacing passwords that then fail to deploy because they're still as unworkable as they were the last twenty times the same thing was tried.  There's a good paper written some years ago by Cormac Herley et al "The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes" which provides a checklist for what it'd take to create something that can displace the ubiquitous passwords.  It also probably functions as a decent predictor of how likely a proposed replacement will be to fail in the marketplace...

[Peter Gutmann]

Someone pointed me to this discussion, having done a fair bit of work in security UI I thought I'd add my $0.02 (+ 40% tariff for US readers): The reason why password managers are popular isn't because of some conspiracy to block everything else but because they're the least unusable authentication mechanism out there.  Second is probably TOTP stuff like Authy (there are also very unusable TOTP implementations, UI research rates Authy as the best).  Anything involving PKI or crypto tokens or requiring cryptographic protocols is last, no matter what else you add to the list.  For example one very usable but toe-curling to crypto purists mechanism is used by some payment provider whose name I can't remember where they recognise your email address on checkout and send you an SMS to auth the payment, with no credit card details or PII being sent anywhere.  It works, it's very easy to use, and it's a lot more secure than typing your credit card details into some random web site, it just wouldn't ever get suggested by a cryptographer or security expert.

Unfortunately the response from the crypto community has been to design ever more awkward but eminently conference-paper-worthy cryptographic protocols and mechanisms for replacing passwords that then fail to deploy because they're still as unworkable as they were the last twenty times the same thing was tried.  There's a good paper written some years ago by Cormac Herley et al "The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes" which provides a checklist for what it'd take to create something that can displace the ubiquitous passwords.  It also probably functions as a decent predictor of how likely a proposed replacement will be to fail in the marketplace...

On Monday, September 15, 2025 at 9:46:49 AM UTC+12 Claude Robitaille wrote: