Open arianvp opened 11 months ago
I think in practise this means give a mechanism for Web Extensions to extend the internal PublicKeyCredential.[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
method.
such that silentlyDiscoveredCredentials
can be extended some way?
If 1Password or other password managers are reading this:
iOS 17 and MacOS 14 now have support for integrating your password manager extension into the native Passkey auto-complete UI
https://developer.apple.com/documentation/authenticationservices/ascredentialproviderviewcontroller
This only works if you ship a native app. Also, while iOS 17 is likely to be adopted by many users in a short amount of time, we have seen that it can take a lot longer for macOS updates/upgrades to get taken up by users. There will most likely be a solution to this problem in the long run, but in the short/medium term browser extensions from password managers is the best way to provide passkey support to a broad segment of users. There will be specific use cases where this introduces friction, but I consider those edge cases, at least among our users.
Agree that having a Web Extension api for this would be more ideal given the high bar of writing a native application integration. Thanks for the context from the PW-manager side of things. Appreciated :)
Description
Password Managers are rolling out Passkey support and they're doing this by monkey-patching
navigator.credentials.get
. This is leading to a lot of confusion with users as suddenly native Passkey autofill (conditional mediation) breaks and instead a non-native pop-up opens when the website loads.This breaks all the nice usability features of Passkeys.
I have a lot of complaints of colleagues (As we're both using 1Password and Passkeys) that they can not log in anymore and I need to explain them to instead of expecting the nice Autofill flow from Safari they need to click the little "Security Key" icon in the 1Password popup. The problem is that I don't think 1Password can do any better within the constraints of the current API. And we need to provide them with the tools to build a nicer integration.
1Password's implementation currently does the following:
mediation: conditional
navigator.credentials.get()
call to be non-conditional. Triggering a modal flow. Note: I think they have no option here as it's not possible to trigger the conditional mediation flow from a web extension? (Not sure about this).Solution
Stop gap solution:
If an extension intercepts a
navigator.credentials.get({mediation:"conditional"l})
call it should be able to callnavigator.credentials.get({mediation:"conditional"l})
again after dismissing the extension-specific logic; such that the browser autofill gets triggered.Ideal solution:
Web Extensions should not be forced to monkey-patch
navigator.credentials.get
and break native autofill behaviour. Instead they should be provided with hooks to augment the autofill UI and add their own entries in the list.Other options
Disable Password Manager.
Related Links
Notes
Perhaps this discussion should be made in the Web-Extensions group. But given people here are domain experts about how the browser integration for webauthn are built I think discussion here is useful. We could then make a proposal for an API to the WebExtensions WG