Thanks! Just to be clear, the deprecation trial is beginning with M95, but it would only be *required* by M98 when we disable the U2F API by default. M104 is where we plan to delete the API, so M103 would be the last release where the deprecation trial is functional.
On Thu, Sep 23, 2021 at 5:18 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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/CAB%3DfcEYhfgrgRHLffmL%2BkHMnMePnit__Z2mJTOqN3ZGtNtJusw%40mail.gmail.com.
