Provide a way for Web Extensions to hook into browser's Passkey autofill UI

[arianvp]

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:

1. Intercept the call with mediation: conditional
2. Show 1password UI
3. if you dismiss it, rewrites the 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 call navigator.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

[arianvp]

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?

[arianvp]

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

[irew]

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.

[arianvp]

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 :)

[nicksteele]

From WebAuthn WG April 2nd '25 Meeting:

While we in the credential provider space are interested in supporting this, it falls outside the scope of WebAuthnWG and ideally should be raised as an issue in the WebExtensions WG.

[arianvp]

Is this something the WebAuthnWG (specifically the members representing password managers) can initiate? I think it will have more political capital than me opening an issue there.

[timcappalli]

This issue is quite old and a lot has changed. In 2025, credential providers have the ability to natively integrate into 3 of 4 major operating systems with the 4th coming in a few months. This is the only model that works at scale and ensures users can sign in with passkeys wherever they need to.

tl;dr, IMO there is no Web Platform work to do.

[arianvp]

I am aware of the native integrations. I even suggested it here in this thread.

But rhe reality currently 2 years later is;

1password still monkeypatches navigator.credentials Bitwarden still monkeypatches navigator.credentials

I haven't checked dashlane (who are in this thread asking for a web extension API). Maybe @irew can give details.

Even today 1password shipped a bug that makes the entire page unusable when calling navigator.credentials.create() that I'm currently running into on both Firefox and Chrome.

To me as an end user nothing has changed since I opened this issue.

Having to integrate with native APIs is apparently such a high barrier that two big names dont bother. This sounds to me like a web extensions API would be beneficial?

I don't speak for credential providers but it seems for some reason the native credential APIs don't have high adoption rates so far. And it's affecting me as an end-user

[lgarron]

I don't speak for credential providers but it seems for some reason the native credential APIs don't have high adoption rates so far. And it's affecting me as an end-user

I also strongly concur with this.

I use 1Password, and for one reason or another they have decided to inject 700kB into every single page load to implement their UI. In addition, they have implemented this in a way (at least in Chrome) that intercepts every single WebAuthn call unless I manually opt out in every every single user profile on each Chrome installation that I use. [^1]

[^1]: Even if I disable the passkey interception, they still load a lot of code. As @arianvp points out, this can lead to bugs that break browser functionality even if the extension meant to leave built-in functionality alone.

While in theory it's possible to say "if you don't like that, don't use 1Password", there are a lot of considerations for what password manager to use. "The one I'm using makes me very uncomfortable" is still preferable to "other choices have bigger dealbreakers for me". There are also non-trivial risks to switching.

The WebAuthn spec has generally struck a great balance incentivizing both browsers and sites to implement good UX. This is a great success. But as it stands, password managers interject themselves and break this balance. Considering this issue out of scope leaves the UX broken for many users in practice.

[irew]

I haven't checked dashlane (who are in this thread asking for a web extension API). Maybe @irew can give details.

• Dashlane does not invest in developing native desktop apps, the ROI is not justified for the size of our company and the limited usage of such apps by our users. In the past when we did ship native desktop apps, however our users preferred the standalone browser extension over the native app.
• We will continue to monkey patch navigator.credentials.create (and get). We're only interested in publicKey credentials, if the RP indicates a preference for a security keys, the call is returned to the browser/OS.
• There is a trend of native autofill APIs being adopted at the OS level, with support for a very limited set of data types. These are necessary on mobile, but not on desktop. We are not interested in using these desktop APIs which would limit our product features and reduce market competition. On desktop we prefer to control the UI for autofill of all types of data we support, which is much more than the OS would ever support. Even if the OS did support these types, we prefer to control the heuristics of detecting which fields to autofill, and the UI that goes with it, so we would not use the OS APIs.

We consider our approach optimal for the vast majority of Dashlane users.

[timcappalli]

Having to integrate with native APIs is apparently such a high barrier that two big names dont bother.

It's actually quite a low barrier. Unfortunately some credential providers have chosen not to balance the health of the ecosystem with their business goals. At the end of the day, their users will be impacted when they're unable to sign in to services on their devices. I just hope when that happens, it only impacts people's opinions of those products, and not passkeys as a whole.

That being said, there are a number of mainstream providers who are currently working on integrating natively on desktop, which is exciting!

I don't speak for credential providers but it seems for some reason the native credential APIs don't have high adoption rates so far. And it's affecting me as an end-user

While this venue isn't typically designed for end user feedback, I would highly recommend you reach out to your credential provider of choice and ask why they are impacting your experience with their product by not integrating natively into the ecosystem.

[arianvp]

Active discussion moved here:

https://github.com/w3c/webextensions/issues/361

[arianvp]

It's actually quite a low barrier. Unfortunately some credential providers have chosen not to balance the health of the ecosystem with their business goals.

Bit of an experience report as we rolled out passkeys at our company.

So we've been experimenting with implementing SPC (a spec closely related to WebAuthn) at our company and found out that the monkey-patching of navigator.credentials that password managers like Bitwarden and 1Password do heavily interfere with this as chrome's SPC flow simply doesn't trigger as it gets intercepted by the extensions and loses the spc extension bits, so this ticket came back into my mind again.

Also without SPC in the picture, in general we find that the UX of third party password managers monkey-patching navigator.credentials is terrible, leads to hard to diagnose bugs, requires us to be aware of password-manager specific quirks, and is very confusing to end-users due to lack of a unified experience.

One thing that is within direct control of the WebAuthn charter, and might form as a forcing function to get password managers to behave and integrate with the right integration points is to solidify in the spec that navigator.credentials is immutable and can not be overridden by web extensions.

Is this maybe something we could consider for L4? If we force password managers to not mess with navigator.credentials then there is no possibility of degradation of user experience. Currently it's a wild west and it's very confusing to end users that 3rd party web extensions intercept these calls. It even gets worse when you install multiple password manager web extensions as they fight over control.

@timcappalli thoughts on this?

[emlun]

navigator.credentials is governed by the Credential Management API, which is in the Web Application Security Working Group (there is considerable overlap with participants in the WebAuthn WG, though), so the immutability topic would have to be brought there. In fact there already are a couple of issues on this and related topics:

• https://github.com/w3c/webappsec-credential-management/issues/63
• https://github.com/w3c/webappsec-credential-management/issues/220