I think that's what Martin's email suggests ("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."). Assuming that's the
case, a two milestone extension doesn't seem overly burdensome from a
burn-in perspective.If y'all can communicate that deadline to your partners in a way that they can accept, this extension LGTM. -mike On Thu, May 19, 2022 at 1:47 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWUwbsk2ggMRSb8DGFX83ssm44XdMP7cy%2B%2BomHq7m_6CA%40mail.gmail.com?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/CAKXHy%3De04-QwvQf8Y%2BG6WUNLv9mrW%2B5jtuUaVVKvxV2P40h-pA%40mail.gmail.com.
