So IIUC, the deprecation trial would run from M98-M104. That seems like a reasonable time period to give to folks and enable them to adjust. Still LGTM.
On Wed, Sep 22, 2021 at 10:32 PM 'Martin Kreichgauer' via blink-dev < blink-dev@chromium.org> wrote: > Dear blink-dev, > > I wanted to provide an update on our progress with the U2F API deprecation > effort and request a short extension for removal of the API and the end > date of the Reverse Origin Trial. > > First, the changes originally announced for Chrome 94 are now scheduled to > ship instead with Chrome 95. These changes include gating of U2F API > requests behind a permission prompt, deprecation warnings logged to the > developer console, and a Reverse Origin Trial > <https://developer.chrome.com/origintrials/#/view_trial/-6366963973195038719> > . > > We still plan to disable the U2F API by default with Chrome 98. > > We also have been in close contact about this deprecation with partners > who still rely on the U2F API. In some of these conversations, partners > asked us to allow a little more time for them to migrate their websites to > the WebAuthn. We therefore would like to push back removal of the U2F API > to Chrome 104, and to extend the Reverse Origin Trial to the same time > period. > > Thanks, > Martin > > > On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer wrote: > >> 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 >> <https://www.chromestatus.com/feature/5669923372138496>). 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 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/SdceviqfKJo/m/zIMMWWoLBgAJ> >> 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 >> <https://docs.google.com/document/d/1Di6ec7B3t2EVPa0iFzrj6kWPvzI71IzBQo4g8JHeb50/edit> >> 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 <https://bugs.webkit.org/show_bug.cgi?id=202427>. >> >> 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: >> >> Milestone >> >> Approximate stable date >> >> Actions >> >> M93 >> >> August 2021 >> >> Support googleLegacyAppIdSupport extension >> >> M94 >> >> September 2021 >> >> - >> >> Gate U2F API requests behind a user permission prompt >> - >> >> Log a deprecation notice in Developer Console for every request >> - >> >> Start a Deprecation Trial; keep the U2F API enabled by default >> >> M98 >> >> February 2022 >> >> Disable the U2F API by default; but keep it available to sites on the >> Deprecation Trial >> >> M100 >> >> March 2022 >> >> Fully remove the U2F API >> >> >> 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 >> <https://developer.mozilla.org/en-US/docs/Web/API/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 >> <https://www.chromestatus.com/metrics/feature/timeline/popularity/2812> >> and U2FCryptotokenSign >> <https://www.chromestatus.com/metrics/feature/timeline/popularity/2813> >> 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 >> >> https://www.chromestatus.com/feature/5759004926017536 >> >> -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4bbbde2d-6122-4dc4-a177-76afb2c58f9bn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU_ZW49yEf5keyEakCb8HZrTGDMtMJ_u95EB6YdhUatnw%40mail.gmail.com.
