[webauthn] Extend WebAuthn spec to support interoperability in WebExtensions (#1766)

Mikescops has just created a new issue for https://github.com/w3c/webauthn:

== Extend WebAuthn spec to support interoperability in WebExtensions ==
### Background
We, at Dashlane, a password manager, use WebAuthn to provide passwordless authentication with the fingerprint or 2FA using a roaming authenticator in order to log in to the user's vault. For instance, a user can decide that their vault will be decrypted by a combination of his Master Password and a remote key that is delivered against a valid WebAuthn flow.
If you want to have more context, I recommend [Dashlane's whitepaper](https://www.dashlane.com/security/white-paper).
We use [this flow](https://support.dashlane.com/hc/en-us/articles/360021374760-How-to-log-in-with-biometrics-or-a-security-key-on-the-web-app-and-the-extension-) in a WebExtension as it is our [main app](https://chrome.google.com/webstore/detail/dashlane-password-manager/fdjamakpfbbddfjaooikfcpapjohcfmg?hl=en).

### Issue
I already raised this issue a year ago in thread #1372 but never formalized it in its own issue.
Currently, the spec doesn't mention the use of WebAuthn inside a WebExtension, but as a matter of fact, the API is accessible in this context (except for Firefox where the implementation is still broken: [bugzilla thread](https://bugzilla.mozilla.org/show_bug.cgi?id=1693562)). 

WebAuthn relies on the validity of the RPID (+ its origin). In the context of a WebExtension, the browser is setting the RPID to the current URL which looks like this `chrome-extension://dnifbcdaadaoifdojfdjhimhdaaoomio`. This causes interoperability issues with other platforms when it comes to roaming authenticators as the chrome-extension pattern is not matching your website domain.


### Proposal
**Context:**
To quote @dwaite : 

> With the example of an application, let's call it AsteriskAsterisk. There is a desire to authenticate access with WebAuthn. The existing model would be:
> 
> - A web-based version may have an RPID based on its hosting, perhaps "asteriskasterisk.com"
> PWA functionality which allows that web version to behave like an installed application would use the same RPID of "asteriskasterisk.com"
> - A native application on android or windows would use a RPID of "asteriskasterisk.com" (after some sort of application linking to the domain to whitelist the native apps)
> - A CLI version, if the platform allows direct usage of a FIDO authenticator or if it uses the same OS-level whitelisting above, would use the RPID of "asteriskasterisk.com"
> - A browser extension should therefore be defined to use a RPID of (you guessed it) "asteriskasterisk.com".

**Solution:**
Similar to the implementation of the [FIDO2 API for Android](https://developers.google.com/identity/fido/android/native-apps), WebExtensions should support interoperability with your website by defining your extension ID in a `.well-known` (like `https://asteriskasterisk.com/.well-known/assetlinks.json`) hosted on your domain name.

For instance:
```
[
  {
    "relation" : [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target" : {
      "namespace" : "web_extension",
      "extension_id" : "dnifbcdaadaoifdojfdjhimhdaaoomio",
      "provider" : "chrome"
    }
  }
]
```
**Known limitation:**
In the current implementation of WebExtensions of browsers, the extension_id is susceptible to change. On Chrome, this id is unique once submitted to the store, on Safari it seems to change between sessions...
The fact that this id is not consistent will create issues when it comes to having multiple environments (prod, QA, dev...).


Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1766 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 7 July 2022 12:40:37 UTC