Add browser.credentials proposal
#368
Conversation
lukewarlow
changed the title
browser.credentials proposal
|
See https://github.com/lukewarlow/demo-credential-manager-extension for a rough example of a usage of this API (well the mock for it). |
|
|
||
| ## Types | ||
|
|
||
| ```ts |
There was a problem hiding this comment.
Not sure how we feel about TypeScript types would probably be better as WebIDL
| This retrieves a boolean indicating if this extension is the active credential manager. | ||
|
|
||
| ```js | ||
| browser.credentials.isActiveContainer(); |
There was a problem hiding this comment.
Potentially this should be per credential type depending on whether browsers let users pick their manager per credential type?
|
|
||
| ## Manifest | ||
|
|
||
| To make use of the browser.credentials namespace a new `credentials` key would be required inside of the extension manifest. |
There was a problem hiding this comment.
Not sure if this or a programmatic approach with an options object passed to browser.credentials.registerContainer would be better?
|
|
||
| Any conventional password manager extension would benefit from this API. However, those looking to support Passkeys would particularly benefit. | ||
|
|
||
| The Dashlane browser extension, a password manager with over 4M weekly active users in the Chrome Web Store, currently provides functionality to create and retrieve Passkey credentials. |
There was a problem hiding this comment.
Based on looking at the extensions source code I've determined that Dashlane (and I imagine soon 1Password) make use of code very similar to the mock where a content script injects a "page" script that overrides the navigator.credentials implementation. However, they don't rely on evil evals because they can just put their implementation inside the page script.
|
|
||
| This API would also help extensions and in turn websites embrace the passwordless future. | ||
|
|
||
| **Only Chromium implements the password credential type. Would this limit the usefulness of this API?** |
There was a problem hiding this comment.
This to me is this biggest blocker to the usefulness of this API without some sort of "custom" credentials support.
|
|
||
| They could also address the lack of password credential support. | ||
|
|
||
| These would probably require a change to the [Credential Management API](https://w3c.github.io/webappsec-credential-management) to provide a way to check supported credential types. |
There was a problem hiding this comment.
Depending on how we handle the password type this may be required regardless.
|
|
||
| ## Proposal | ||
|
|
||
| We propose a new browser.credentials API that would allow extensions to integrate with these existing web APIs. |
There was a problem hiding this comment.
Need more detail on what the expected integration looks like from a UI /UX perspective. Potentially a UI mock could be useful but the exact details rely on unknowns such as whether to have 1 credential manager or multiple based on credential type.
| return this._internal.store(credential); | ||
| }, | ||
| preventSilentAccess() { | ||
| // This would be something the browser handles and the extension wouldn't need to worry about this |
There was a problem hiding this comment.
I imagine the browser would handle the logic for this. That would rely on Firefox and WebKit implementing this "properly" though?
|
|
||
| These would probably require a change to the [Credential Management API](https://w3c.github.io/webappsec-credential-management) to provide a way to check supported credential types. | ||
|
|
||
| ## Remaining Work |
There was a problem hiding this comment.
Main questions (beyond the obvious "is this something we want?"
Exact behaviour of choosing whether to use an in-built vs specific extension credential manager:
- Do we allow multiple providers with the browser delegating between them all? Or should it just be one manager either built in or a single extension?
How does an extension determine if a site is using the credential management API with their login forms?:
- Potentially this is something that just accepted as not possible?
- Without knowing either way you'd still have to use the old approach for password credentials and could still run into false results (positives being worse than negatives because if the site DOES use this API you will always know, whereas with positives there's no API to say DON'T save this)
Should all types be allowed to be handled by extensions?:
- Not sure if federated or the new Identity (which I think is Federated V2) make sense to be handled by extensions?
Types not natively supported by all browsers:
- Passwords
- OTPs (only SMS is supported by any browser)
Custom types not supported by any browser:
- e.g. Enable a new CryptoKey Credential to provide a possession factor webappsec-credential-management#152 (not sure what this is about but it's a proposal for a new type that potentially could be implemented by an extension)
|
Another use case beyond Passkeys and Passwords could be the OTPCredential type currently supported by Chromium. Currently chromium only supports the SMS transport but credentials could support others. Bitwarden (and I'm sure many other extensions) let you store and retrieve time based one time passwords. This API (along with probable required additions to the Credential Management API) could allow them to be programatically managed. |
| This retrieves a boolean indicating if this extension is the active credential manager. | ||
|
|
||
| ```js | ||
| browser.credentials.isActiveContainer(); |
There was a problem hiding this comment.
Does this function even make sense to include? Only really makes sense if we allow only one active credential manager.
|
An extra thought, the credential and options objects passed to the extension credential container implementation would also have to include the credentials internal origin property so the extension can correctly bind it to that origin. Password managers currently have the ability to associate multiple origins to a password credential. So this might have to be considered in the API design. |
|
Going to close this for now until there's a bigger consensus on the issue. |
Rough draft of a proposal related to #361
To clarify I've got no affiliation with any password manager companies this is just based on my experience as a web developer and web user.