Add an API to integrate with the Credential Management Web API

[lukewarlow]

This proposal is to provide a way for password manager extensions to integrate with website authentication flows more directly. This would allow site users the UX benefits of the credential management API while also being able to use a password manager of their choice not just the default browser one.

Currently password manager extensions have to rely on heuristics and / or overriding the navigator.credentials JS API to effectively work for their users. I've experienced first hand issues with password managers not always being able to effectively determine when a successful registration or login occurs especially on single page apps where there's no conventional page reload. If sites could reliably make use of navigator.credentials for Password credentials and the browser allow the user to choose a provider rather than having only the choice of (currently only Chromium) the browsers built manager it would massively improve the experience, for end users, website developers and password manager developers.

An example of an extension being forced to override the JS API itself is Dashlane's Passkey saving functionality. (Not directly mentioned in their article but I've tested and that's what the extension is doing).

I imagine this API could work similarly to Android 14s new credential management API where apps use a standard API (which the web already has) and then there's a corresponding API that apps can implement to handle password and Passkey create and get requests.

[lukewarlow]

Some very quick thoughts on what this could look like.

// Implementation of a new ExtensionCredentialsContainer which could probably be the same as (or similar to) the CredentialsContainer type (type of navigator.credentials)
const implementation: ExtensionCredentialsContainer = { }

// Extension API to register the container. Perhaps supported credentials could be declared in the manifest instead of programmatically?
chrome.credentials.registerContainer(implementation, {supportedCredentials: ['password', 'public-key']});

// New function inside of navigator.credentials to return the supported credential types.
// This could replace searching for Credential types on the window object to allow extensions to support types that browsers don't natively support. Such as password inside of Firefox and Safari?
navigator.credentials.getSupportedTypes()

Preferably the UA could act as a middleware that delegates to multiple places at once, listing credentials from multiple providers? Not sure how this would work with custom credentials?

Like this crude mockup:

If the custom credential stuff opens up too many issues it'd be much better to not support that case rather than not doing this API at all imo.

[dotproto]

Tweaking the title as this issue is currently more of an enhancement request than a specific proposal.

[lukewarlow]

https://developer.chrome.com/docs/extensions/reference/webAuthenticationProxy/

Not what this issue is requesting but it seems chrome has some sort of mechanism for extensions to take part in WebAuthn requests

[oliverdunk]

Thanks for opening this! Having worked on a password manager before I joined Google, I definitely empathise with the use case. I think there are definite benefits to something like this (for example, so a third-party can offer Passkeys integration on Chromebooks where the options for installing apps are more limited).

That said, this sort of change would require investment from the team working on these types of authentication APIs in addition to the extension team. Having spoken to them in the past, I don't think this is the sort of thing likely to be worked on in the short term and we would nudge developers towards integrating at the system level instead.

Given that I would say this doesn't feel worthwhile to pursue right now purely from the Chrome side, but it could be interesting if another browser vendor wanted to champion this.

https://developer.chrome.com/docs/extensions/reference/webAuthenticationProxy/
Not what this issue is requesting but it seems chrome has some sort of mechanism for extensions to take part in WebAuthn requests

On this API specifically, we don't want to encourage it as a general way for extensions to handle WebAuthn. We made it public because we'd rather not have private APIs, but this is heavily focused on extensions that want to proxy requests to another device (in a remote desktop scenario for example). It doesn't provide any way to fallback to other options etc.

Currently password manager extensions have to rely on heuristics and / or overriding the navigator.credentials JS API to effectively work for their users. I've experienced first hand issues with password managers not always being able to effectively determine when a successful registration or login occurs especially on single page apps where there's no conventional page reload.

As much as I'd love to solve this problem (and I think an API would be nice) I think the impact of allowing extensions to use navigator.credentials would be more limited than it might seem. Filling is a hard problem (and most sites don't use the credential management APIs) so most password managers opt to use their own filling logic.

Again, not saying that we shouldn't have an API, just that I suspect if we spoke to password managers they may have other feature requests which they would rather the time went on.

Adding neutral: chrome Not opposed or supportive from Chrome for now.

[xeenon]

We are opposed to this from Safari. We prefer credential providers to use the system APIs so auto fill will work in apps and not be limited to browser contexts.

[lukewarlow]

From the discussion I feel like everyones on the same page with the use cases behind this but if anyone would like to discuss this further I am happy to provide further context.

I think Firefox and Chrome (on certain platforms) would be the major benefactors here so completely understand Safari's stance.

[irew]

Dashlane does allow the user to fallback to the default implementation, so if they user has a key stored in Chrome or on a hardware key they are not prevented from that usecase:

https://drive.google.com/file/d/1KD0kZ0kR5VwaMMEFQkIcStAr_683dAZb/view?usp=sharing

I admit this puts the responsibility of the overall experience on the password manager extension and not all will behave in ways to easily allow a fallback - here just to say that it is something we thought about and catered for to ensure users are not blocked from accessing all their keys.

[lukewarlow]

Bitwarden has also recently started intercepting the browser passkey flow, I imagine through a very similar mechanism to dashlane.

[irew]

@lukewarlow I expect the majority of password managers to do this:

1. Not all platforms have APIs to plug into
2. Not all password managers have a native app. Some, like Dashlane, have only a browser extension on some platforms. I've also heard other password managers who have both a native app and a browser extension have the majority of their users opting to use their browser extension.

[lukewarlow]

Yeah I think that's exactly why an API for extensions would be so useful.