Is it possible to keep the trial alive for 2 more milestones, but disable new registrations?
On Thu, May 19, 2022 at 1:21 AM Martin Kreichgauer <marti...@google.com> wrote: > Greetings blink-dev, > > I would like to request a second extension of the U2FSecurityKeyAPI > deprecation trial. We are continuously gathering direct user feedback about > this deprecation, and virtually all trial participants we have been in > contact with have either migrated off of U2F already or are expecting to do > so ahead of the current July 26 deadline. However, one enterprise user with > a very sizable security key deployment across its workforce has told us > that they might not be able to fully migrate a number of stragglers by that > time, and asked whether we could extend the deadline by 8 weeks in order to > minimize disruptions for them. > > We're therefore asking to push back removal of the U2F API by two > milestones (M106 instead M104), and extend the deprecation trial until > September 20, 2022. We would still like to close new trial registrations on > July 26, and grant renewals beyond July 26 only to existing participants > that contact us directly. > > Since the upcoming removal of extensions manifest V2 from Chrome presents > a hard technical deadline for removing Cryptotoken, further extensions of > this trial would be extremely unlikely. > > Cheers, > Martin > > On Thursday, September 23, 2021 at 11:50:12 AM UTC-7 yoav...@chromium.org > wrote: > >> Thanks for clarifying! >> >> On Thu, Sep 23, 2021 at 7:45 PM Martin Kreichgauer <mart...@google.com> >> wrote: >> >>> 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 <yoav...@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 < >>>> blin...@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+...@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/CAL5BFfWUwbsk2ggMRSb8DGFX83ssm44XdMP7cy%2B%2BomHq7m_6CA%40mail.gmail.com.
