Primary eng (and PM) emails
mart...@google.com, a...@chromium.org
Summary
We want to deprecate and remove the legacy U2F API for interacting with security keys. (But not U2F security keys themselves, which will continue to work.)
Affected sites should migrate to the Web Authentication API (WebAuthn). Credentials that were originally registered via the U2F API can be challenged via WebAuthn. USB security keys that are supported by the U2F API are also supported by the WebAuthn API.
Motivation
U2F is Chrome’s original security key API. It allows sites to register public key credentials on USB security keys and challenge them for building phishing-resistant two-factor authentication systems. U2F never became an Open Web standard and was subsumed by WebAuthn (launched in M67). Chrome never directly supported the FIDO U2F JavaScript API in Blink, but rather shipped a component extension called cryptotoken, which exposes an equivalent chrome.runtime.sendMessage API. U2F and Cryptotoken are firmly in maintenance mode and we encouraged sites to migrate to WebAuthn two years ago.
U2F’s continued existence presents several issues:
Cryptotoken requests don’t trigger a permission prompt or any UI indicating that the website is interacting with a special type of USB device. Instead we rely on the website to handle UI for the requested security key interaction. We believe this isn’t ideal from a secure UX perspective. WebAuthn presents either a tab-modal dialog or UI provided by the operating system for every request.
Sites can unconditionally query U2F credentials when embedded in cross-origin iframes. WebAuthn guards this behavior behind a feature policy.
Because Cryptotoken is a component extension and externally connectable from any URL, it effectively exposes the chrome.runtime APIs unconditionally to the entire web. Removing cryptotoken will allow us to make these APIs unavailable to websites that are not explicitly listed as connectable by an extension.
WebAuthn has subsumed U2F and we don’t want to encourage new use of an old API.
googleLegacyAppIdSupport extension
The factory image on some Android devices predates WebAuthn’s existence and therefore only supports the U2F API. Because credentials registered via WebAuthn cannot be challenged via U2F, Google continues to require a mechanism for registering U2F-compatible security key credentials even after the U2F API has been removed from Chrome, or else users that register a security key on their desktop would be unable to sign into their affected Android devices with that security key. We would like to implement support for the goolgeLegacyAppId WebAuthn request extension in Chromium to allow Google’s accounts system to do this. The extension would allow *.google.com origins to create WebAuthn credentials that can be challenged via WebAuthn and U2F, so that it will be possible for Android’s burned-in user account adding system to exercise them. While the googleLegacyAppIdSupport extension has not been formally standardized, Safari has already shipped it.
The ability to use WebAuthn in Chrome on these Android devices is not affected. Chrome supports WebAuthn on devices running Android N or newer. Other websites should therefore not encounter Google’s particular problem in their own WebAuthn migrations.
Deprecation and Removal Timeline
We propose the following timeline for deprecation and removal:
Interoperability and Compatibility Risk
We believe there exist only a handful of sites that still use the U2F API. Nevertheless, we want to be careful to avoid surprising developers by the removal and possibly affect users’ ability to log into websites. We will run a Reverse Origin Trial starting with M97 to get an accurate picture of which sites are left on U2F at that point and allow them time to migrate.
Removing U2F and encouraging sites to switch to WebAuthn should be positive for compatibility and interoperability in the long run.
Edge: Supported, no signals on removal
Firefox: Supported, no signals on removal
Safari: Not supported
Somewhat confusingly, U2F is the name for both the web-facing API and a USB security key wire protocol. The WebAuthn API supports security keys speaking either the U2F (CTAP1) or FIDO2 (CTAP2) wire protocol. The proposal here is only to remove the U2F API. Users can continue to use their U2F security keys via the WebAuthn API.
Alternative implementation suggestion for web developers
Developers should migrate to using the Web Authentication API (WebAuthn). To challenge an existing security key credential that was originally registered via the U2F API, developers can use the appid extension:
navigator.credentials.sign({
publicKey: {
allowCredentials: [{
id: new Uint8Array([…]).buffer,,
type: 'public-key'
}],
challenge: new Uint8Array([…]).buffer,
extensions: {
appid: ‘https://example.com’,
},
},
};
(Where example.com is replaced with the appID that was used for registering the U2F credential.)
Credentials created via WebAuthn cannot be asserted via the U2F API. Sites therefore may want to first migrate their sign-in flows and then, once that is settled, migrate their security key enrollment.
Usage information from UseCounter
U2F usage is measured in the U2FCryptotokenRegister and U2FCryptotokenSign UKM metrics. However, the number of total requests isn’t as relevant as the number of sites on the web that support U2F for signing in. Based on UKM data, we believe the latter to be quite low, but we would like to give these sites the chance to make the switch to WebAuthn rather than break them.
Entry on the feature dashboard
We would like to implement support for the goolgeLegacyAppId WebAuthn request extension in Chromium to allow Google’s accounts system to do this.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/beb9f40d-d389-4528-b633-2491ec2a6abfn%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-vs-CUKUAZ9ikWx6qkYjPqb5uhkL-JpBB9QiiZ4XJK0w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3cWrPN2M3KLGyo-%3Dd3%3DtozLwYG%2B3Na-oGL%3D2nZOWecA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfJhBsbDEKDgaR56JAJZEy632Uz%2BBrtQvONPFpg3h7xrQ%40mail.gmail.com.
> Removing U2F without this workaround would result in users being unable to sign into those Android devices
Unclear - are they plugging a U2F security key into their computer in order to sign into their Android tablet/phone?By signing into their device, you mean, the sign-in when you get a new device/factory reset a device/change/add account (an operation that usually happens around once)?
☆PhistucKOn Fri, Jun 25, 2021 at 12:57 PM Mike West <mk...@chromium.org> wrote:LGTM3.Removing a proprietary, extension-based mechanism is something that I think can safely bypass TAG review. WebAuthN is the way forward, and they've signed off on that path pretty clearly by now.One thing to call out here is not just that this is a non-standard extension, but one that explicitly empowers `*.google.com` to continue using U2F in ways that other web origins can't. This kind of carveout (especially of `*.google.com`) isn't something that I'd generally consider acceptable for web-facing APIs, so it's worth digging into the justification a bit in the interests of explaining what I hope is a narrow exception that won't repeat itself: old Android devices have a platform-level account whose sign-in flows are built on U2F, and which are not compatible with security keys registered via WebAuthN. Removing U2F without this workaround would result in users being unable to sign into those Android devices, eventually bricking them. The tradeoff here seems reasonable, especially given that this extension is already shipping in Safari and Firefox.
Do a lot of people connect security keys to the phone directly like
that? I mean they could always use g.co/sc instead, right?
The U2F API is supported in Safari on OSX and I assume on iOS. I think they added that to avoid the error when people try to make Google credentials.
Off the top of my head, I can't think of anyone other than Google still using the U2F API other than Google, and some test pages.However, given that until recently the only FIPS approved keys have been U2F some gov applications may still be using U2F.Yubico has been strongly recommending migration to WebAuthn for some time. I can check to see if others at Yubico know of any RP still using the u2F API.
You should probably fix the link to the extension so that WebKit/Apple and perhaps FireFox could implement the new WebAuthn extension.
I am guessing that Edge will have the option of inheriting the Chromium code so that should be no issue as long as nothing in WebAuthn.dll creates problems.
RegardsJohn B.
Sorry, you are correct about OSX, I confused myself by testing the wrong browser. Too many OS / browser combinations:)That link is now working for me. I will pass it on to the person working on the Windows WebAuthn.dll updates so he is aware of it.
Is the extension in Canary now?
ThanksJohn B.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4bbbde2d-6122-4dc4-a177-76afb2c58f9bn%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWUwbsk2ggMRSb8DGFX83ssm44XdMP7cy%2B%2BomHq7m_6CA%40mail.gmail.com.