Thanks for clarifying! On Thu, Sep 23, 2021 at 7:45 PM Martin Kreichgauer <marti...@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 <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/CAL5BFfVQLT1ENMZ5%2BZjY6v04fxCdus956rFLTPOdhJzuHSBEPQ%40mail.gmail.com.
