WebExtensions should use asset links model for WebAuthn RP ID

[timcappalli]

Original issue created by @Mikescops is here: https://github.com/w3c/webauthn/issues/1766

I believe this would be net new for the Web Extensions area. I don't think there is anything specific to change in WebAuthn.

EDIT: Adding additional details

WebAuthn credentials are origin-bound. For example, a credential created for login.example.com cannot be used by contoso.com. This is one of the primary security properties that enable phishing resistance.

Using a WebAuthn credential in the native app world can be challenging as apps do not use web origins for their identity. Example Co's app may have an app identifier of com.example.app.android.prod. This has been addressed by platform vendors by using "asset links"[1] / "associated domains"[2] where an app developer can link their app to their web origin.

Most password managers today use some kind of knowledge factor / secret for signing into the password manager and for some unlock operations. Many password managers would like to move to stronger, phishing-resistant auth. Browser extensions have a similar problem as mobile apps, except in this case, there is a web origin, but it is locally-specific to the extension. For example, Bitwarden in Edge is: edge-extension://jbkfoedolllekgbhcbcoahefnbanhhlh and in Chrome is chrome-extension://jbkfoedolllekgbhcbcoahefnbanhhlh. The browser / platform will never allow a WebAuthn credential for vault.bitwarden.com to be used to for those extensions because of this mismatch, by design.

The formal ask is to evaluate an asset-links style model for web extensions that allow a formal link back to the primary web origin.

[1] https://developers.google.com/identity/fido/android/native-apps#interoperability_with_your_website [2] https://developer.apple.com/documentation/xcode/supporting-associated-domains

[Mikescops]

Thank you @timcappalli for moving this issue, do you know if I can push it to a specific working group?

[oliverdunk]

Related (but not intended for public extensions) API mentioned in the last meeting: https://bugs.chromium.org/p/chromium/issues/detail?id=1231802

[timcappalli]

Looking at the meeting notes, I wanted to comment that this issue was to address signing into an extension using WebAuthn, not integrating in autofill, overriding WebAuthn requests for RPs, etc.

[Rob--W]

For completeness, here is a relevant Bugzilla ticket (already linked from https://github.com/w3c/webauthn/issues/1766): https://bugzilla.mozilla.org/show_bug.cgi?id=1693562

[timcappalli]

@Rob--W @dotproto I've added additional background to the original post as requested.

[timcappalli]

In a few other discussions at TPAC 2022 and other WebAuthn F2F, some browser extensions shared that they pop open a new tab for either the entire auth flow, or just for WebAuthn, which uses the web origin. So there is a solution today, but I understand it may not be perfect.

Does the Web Extensions CG wish to pursue a more concrete pattern that uses asset links?

[Mikescops]

Websites integrity cannot be trust compared to web extensions. There is no guarantee that the website delivery has not been tampered. So far the only technology that is in draft is SXG (https://datatracker.ietf.org/doc/html/draft-yasskin-http-origin-signed-responses-06) but it is only implemented on Chromium browsers.

Some extensions, because they manage high value assets, cannot accept this risk.

[irew]

Just want to add that popping out to a new tab is not an acceptable experience. In this instance, using a passkey instead of a password diminishes the user experience when signing directly into a browser extension. You should be able to use a passkey directly within a browser extension to sign into a service running through that extension - you can do that today with a password, ideally you should be able to do that with a passkey.

[Rob--W]

Quoting https://github.com/w3c/webextensions/issues/409#issuecomment-1623858323 because it includes one slide that explains the issue:

Would love to talk about Issue 238 in a future meeting, I don't have a lot of involvement in WECG, but happy to join just to to raise this topic.

One slide explaining issue 238

In case the slide ever disappears, this is the content:

[ screenshot showing location bar of browser at https://www.google.com ]

Android: https://www.google.com/.well-known/assetlinks.json Apple: https://www.google.com/apple-app-site-association WebAuthn rpId = google.com

Systems can link mobile apps to domains, which allows passkeys to work seamlessly between a website and its related mobile apps.

No such behaviour exists for web extensions - it could use the same pattern, allowing services to let users to sign directly into a web extension with a passkey.

[oliverdunk]

We have landed a change in Chromium that will allow extensions to assert RP IDs they have host permissions for starting in Chrome 122: https://chromiumdash.appspot.com/commit/cfea6b18ede2a8fe0d7ea32e6bba967a7f2de6f8

[zombie]

And a webauthn list post with a few more details: https://lists.w3.org/Archives/Public/public-webauthn/2023Dec/0078.html.