"Saved Passkey" vs "Touch ID Passkey": What's the difference?

[coolaj86]

I don't know what it's like on other operating systems, but on macOS the user experience is nicer with Touch ID Passkeys rather than Saved Passkeys - the modal window opens in the correct place rather than potentially on another screen.

Do you know what the difference is between triggering the two different types of passkey?

Also, clicking Use a different passkey doesn't show the Touch ID Passkey option.

This is, of course, very confusing because they both use the term "Touch ID" and the term "Passkey". One of them is "Browser" and the other is "Saved".

Saved Passkey

Touch ID

[getify]

Interesting, I don't have a mac so I haven't seen this UX myself. My instinct is to say it's up to the browser and OS, because the APIs we call just hand off the request to them. I don't think there's anything I'm sending which is affecting which of those modals shows up or which options are available.

[coolaj86]

It's the same (not-Safari) browser on the same OS and same user account etc, being tested with WebAuthn side-by-side on two different websites, so it's definitely a difference in options.

I'm thinking it's related to either "UV required" or the option to show a list of initial options vs showing the os-default option only.

I highly doubt it's a different non-WebAuthn API because Apple never lets 3rd party apps use their integrated APIs, and this isn't Safari.

I'm about to the point of doing my own testing, so I'll update if I figure it out.

[getify]

I highly doubt it's a different non-WebAuthn API because Apple never lets 3rd party apps use their integrated APIs, and this isn't Safari.

Websites wouldn't have different APIs, no. But I have definitely seen different UX from how different native apps (I use Android) integrate and use various native platform APIs.

...so it's definitely a difference in options.

OK, interesting. FWIW, we do in fact require some specific settings for the way we need the passkey to work...

1. authenticatorAttachment is set to "platform", which means a built-in authenticator (like a FaceID camera or a TouchID scanner), as opposed to "cross-platform" which are external authenticators like USB sticks, etc. This is required/strongly-preferred because many of the external authenticators don't support the behavior we need (the userHandle retrieval, discoverable passkeys, etc).

2. residentKey is set to "required", because we need to support discoverable passkeys (meaning where you are authenticating but don't already know the credential-ID, so the browser needs to prompt the user to select a passkey (among possibly multiple registered ones).

   Technically, this is an optional setting, because you could limit usage to where you only ever store and know about passkeys. But I think this will be worse UX for users in the cases where such a credential ID might be forgotten (like if storage was cleared).

   A sub-setting related to this is requireResidentKey, which is set to true.

3. userVerification tells the authenticator that it must actually affirmatively prompt and verify with the user, instead of just silently verifying in the background.

   This setting is probably the most important, because without UV, the passkey will not return the userHandle from the passkey upon successful authentication, and we have to have that value to re-derive the encryption keypair.

All of these settings can be overridden in the options that are passed to WebAuthn-Local-Client's register(..) call. However, Local-Data-Lock's getLockKey(..) call does not currently support overriding these particular settings for its underlying register() call. Neither does Local-Vault's connect() call support overriding them for its underlying getLockKey(..) call.

It's possible we could revisit and potentially allow overriding these through Local-Data-Lock and Local-Vault APIs. But we have to make sure settings aren't overridden in a way that fundamentally breaks what's being assumed about how the passkeys / userHandles work.

I'll update if I figure it out.

Yes, please do let me know if you figure anything specific out.

[coolaj86]

Interestingly, if I just click "Continue" then I get the "ugly" modal:

But this particular demo gives the "Save Another Way" option, which I don't think was in the other demos:

It seems that one is the BROWSER, which I think proxies to the system keychain, managed by the OS.

It seems that the other is, in fact, the OPERATING SYSTEM keychain, directly.
(macOS actually has 3 different keychains, I believe - the one it selected is for iCloud)

I'm not sure what to make of that. I wonder if it could be made the default.

0 Keys

If no keys are available, you get a prompt to insert a device, or scan a phone.

iCloud & Browser Keys

[getify]

The UX (which modals you get) also will depend on which button/mode you're trying in the test demo page.

• The "setup vault" registers a new passkey, which presents a slightly different looking flow of modal prompts.

• The "unlock vault" and "discover vault" both try to unlock (via passkey authentication instead of new registration), but...

  • "unlock" passes a specific credential ID and tells the system to only use that specific passkey for the authentication... so the browser/system may skip or simplify its modal in such a case where only one specified passkey is allowed.

  • "discover" doesn't pass a credential-ID and instead asks the browser/system to present all "discoverable" (aka "resident") passkeys, so that modal prompt is likely going to look different since it has to show you potentially a list of various passkeys to choose from.

[coolaj86]

Okay, so I think I've figured it out. All of what you said, but a few extra details:

Options

• mediation
  • "optional" and "required" mean "please show the multi-auth prompt, maybe"
  • "conditional" means "mini-prompt on inputs with autocomplete="webauthn""
  • "silent" seems to be ignored
• user
  • seems to be ignored, except when registering
  • maybe used to skip the multi-auth prompt when silent is set?

Modes

• When 0 keys exist, a special prompt use a QR or other device pops up
• When exactly 1 passkey exists, get(credOpts) on macOS always uses that key, always with biometrics, regardless of the options - unless it was created with the browser option, in which case it will do the uglier modal, with a password
• When 2+ passkeys exist, you can get the multi-auth to come up

There's a lot of possible permutations here. I think I won't realistically discover many of them until user complaints surface.

[getify]

Potentially related: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredentialCreationOptions#hints

[getify]

"conditional" means "mini-prompt on inputs with autocomplete="webauthn""

BTW, if you haven't seen this: https://web.dev/articles/passkey-form-autofill

Conditional mediation is demo'd in the tests for this library (WebAuthn-Local-Client), but honestly... that UX flow -- clicking into a username/password field to activate auto-fill, instead of just clicking a button -- doesn't really match the expected UX of how I think apps will use local-data-lock and local-vault.

It seems like a "transitional UI" mode where you've got an app that users already do username/password authentication, and you're migrating/upgrading to passkeys (optionally)... so users can sort discover passkey functionality, while interacting with an auth UI they're already familiar with.

[getify]

Also, while I agree that it matters how the UX of these modals feels to end-users, ultimately, I'm not inclined to obsess too much about it, or jump through too many hoops to affect what's shown.

The reason is similar to how I use standard HTML form elements (select boxes, checkboxes, calendar picker, etc) instead of super-customized UI elements. I actually think that sort of responsibility belongs to the browser/OS/device. It should be different for iOS users versus Android, etc. Because the makers of those devices have an entirely different relationship with their users, set different brand/UX expectations, etc. I think app developers should kind of yield control over in those cases, and let those makers own the responsibility to design good interaction UX.

[coolaj86]

I 100% agree that users on Android should be given the opportunity to have the Android experience, and users on Apple should be given the Apple experience.

I hate these milktoast apps that in order to have "better" and "consistent" design end up with far worse design with the defaults provided by the platform, and completely inconsistent with user expectations.

And Chrome users, well, there doesn't seem to be a way to force the Apple or Microsoft experience to come first on Desktop - it's just always Chrome experience by default (Browser Sync, NOT OS Keychain) - the user has to personally click the button to opt-in to the Apple or Microsoft experience - which makes sense because Google doesn't want your keys on someone else's cloud. They need their fingers in there to divert the keys first and foremost to them, duh!

---

[EDITOR NOTE]: With you bringing up your proposed solution of using credential ID for encryption-key seed, this discussion has now veered off from this library (WebAuthn Local Client), into concerns that are more related to Local Data Lock. So I'm moving the rest of your response over to an existing issue you already filed on that library, just to keep things more tidy and coherent.

[getify]

Thanks for the UX thoughts and feedback. I think we've covered that here sufficiently, so closing for now. If there's more thoughts specifically on the UX of the various system modal prompts, please feel free to continue to post here.