Intent to Deprecate and Remove: U2F API (Cryptotoken)

[Martin Kreichgauer]

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). 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 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 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.

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 (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 and U2FCryptotokenSign 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

[Martin Kreichgauer]

On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer wrote:

We would like to implement support for the goolgeLegacyAppId WebAuthn request extension in Chromium to allow Google’s accounts system to do this.

The correct link for the googleLegacyAppIdSupport extension is https://docs.google.com/document/d/1CXBAVyahuhcv8EwTRDBMEKhWeQpSk97knqqQip1Ur1E/view.

[Chris Harrelson]

LGTM

--
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/beb9f40d-d389-4528-b633-2491ec2a6abfn%40chromium.org.

[Yoav Weiss]

LGTM2

Shipping a non-standard extension in multiple engines is certainly an odd case, but it seems like this is the best thing to do for users here.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-vs-CUKUAZ9ikWx6qkYjPqb5uhkL-JpBB9QiiZ4XJK0w%40mail.gmail.com.

[Mike West]

LGTM3.

Removing a proprietary, extension-based mechanism is something that I think can safely bypass TAG review. WebAuthN is the way forward, and they've signed off on that path pretty clearly by now.

One thing to call out here is not just that this is a non-standard extension, but one that explicitly empowers `*.google.com` to continue using U2F in ways that other web origins can't. This kind of carveout (especially of `*.google.com`) isn't something that I'd generally consider acceptable for web-facing APIs, so it's worth digging into the justification a bit in the interests of explaining what I hope is a narrow exception that won't repeat itself: old Android devices have a platform-level account whose sign-in flows are built on U2F, and which are not compatible with security keys registered via WebAuthN. Removing U2F without this workaround would result in users being unable to sign into those Android devices, eventually bricking them. The tradeoff here seems reasonable, especially given that this extension is already shipping in Safari and Firefox.

We should join them, quickly remove the cryptotoken extension, and solidify the ecosystem's move towards WebAuthN.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3cWrPN2M3KLGyo-%3Dd3%3DtozLwYG%2B3Na-oGL%3D2nZOWecA%40mail.gmail.com.

[PhistucK]

> Removing U2F without this workaround would result in users being unable to sign into those Android devices

Unclear - are they plugging a U2F security key into their computer in order to sign into their Android tablet/phone?

By signing into their device, you mean, the sign-in when you get a new device/factory reset a device/change/add account (an operation that usually happens around once)?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfJhBsbDEKDgaR56JAJZEy632Uz%2BBrtQvONPFpg3h7xrQ%40mail.gmail.com.

[Martin Kreichgauer]

On Fri, Jun 25, 2021 at 5:55 AM PhistucK <phis...@gmail.com> wrote:

> Removing U2F without this workaround would result in users being unable to sign into those Android devices

Unclear - are they plugging a U2F security key into their computer in order to sign into their Android tablet/phone?

By signing into their device, you mean, the sign-in when you get a new device/factory reset a device/change/add account (an operation that usually happens around once)?

The device sign-in out of the box or after a factory reset on these devices does not support asserting security key credentials that were registered via WebAuthn. U2F credentials work, and users can connect a security key to the phohne via USB/BLE/NFC.

 

☆PhistucK

On Fri, Jun 25, 2021 at 12:57 PM Mike West <mk...@chromium.org> wrote:

LGTM3.

Removing a proprietary, extension-based mechanism is something that I think can safely bypass TAG review. WebAuthN is the way forward, and they've signed off on that path pretty clearly by now.

One thing to call out here is not just that this is a non-standard extension, but one that explicitly empowers `*.google.com` to continue using U2F in ways that other web origins can't. This kind of carveout (especially of `*.google.com`) isn't something that I'd generally consider acceptable for web-facing APIs, so it's worth digging into the justification a bit in the interests of explaining what I hope is a narrow exception that won't repeat itself: old Android devices have a platform-level account whose sign-in flows are built on U2F, and which are not compatible with security keys registered via WebAuthN. Removing U2F without this workaround would result in users being unable to sign into those Android devices, eventually bricking them. The tradeoff here seems reasonable, especially given that this extension is already shipping in Safari and Firefox.

(Just to clarify, Safari shipped googleLegacyAppIdSupport, but not Firefox.)

[Eric Lawrence]

Edge is (very) supportive of this deprecation/removal.

[Christian Biesinger]

On Fri, Jun 25, 2021 at 4:09 PM 'Martin Kreichgauer' via blink-dev
<blin...@chromium.org> wrote:
>
>
>
> On Fri, Jun 25, 2021 at 5:55 AM PhistucK <phis...@gmail.com> wrote:
>>
>> > Removing U2F without this workaround would result in users being unable to sign into those Android devices
>>
>> Unclear - are they plugging a U2F security key into their computer in order to sign into their Android tablet/phone?
>>
>> By signing into their device, you mean, the sign-in when you get a new device/factory reset a device/change/add account (an operation that usually happens around once)?
>
>
> The device sign-in out of the box or after a factory reset on these devices does not support asserting security key credentials that were registered via WebAuthn. U2F credentials work, and users can connect a security key to the phohne via USB/BLE/NFC.

Do a lot of people connect security keys to the phone directly like
that? I mean they could always use g.co/sc instead, right?

Christian

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEYua7A-Bnp%3DHBaoMSJbOERgX0feH1LygJLpxWV5hq1WQA%40mail.gmail.com.

[Adam Langley]

On Fri, Jun 25, 2021 at 2:31 PM Christian Biesinger <cbies...@chromium.org> wrote:

Do a lot of people connect security keys to the phone directly like
that? I mean they could always use g.co/sc instead, right?

Not all accounts support security codes and those people do have to connect a security key to the phone to sign in. (Or use NFC/BLE, if applicable.)

In such cases, without the accommodations proposed here, they would be stuck.

Cheers

AGL

[Martin Kreichgauer]

On Mon, Jun 28, 2021 at 3:01 PM John Bradley <jbra...@yubico.com> wrote:

The U2F API is supported in Safari on OSX and I assume on iOS.   I think they added that to avoid the error when people try to make Google credentials.  

Safari implements the googleLegacyAppIdSupport extension: https://bugs.webkit.org/show_bug.cgi?id=202427

I don't think Safari implements the U2F API, unless I missed something: None of the U2F demo sites work and window.u2f is undefined.

 

Off the top of my head, I can't think of anyone other than Google still using the U2F API other than Google, and some test pages.  

However, given that until recently the only FIPS approved keys have been U2F some gov applications may still be using U2F.

Yubico has been strongly recommending migration to WebAuthn for some time.   I can check to see if others at Yubico know of any RP still using the u2F API.

Thanks, that would be helpful!

 

You should probably fix the link to the extension so that WebKit/Apple and perhaps FireFox could implement the new WebAuthn extension. 

Does this link work for you? https://docs.google.com/document/d/1CXBAVyahuhcv8EwTRDBMEKhWeQpSk97knqqQip1Ur1E/view (Can't edit the original posting unfortunately.)

 

I am guessing that Edge will have the option of inheriting the Chromium code so that should be no issue as long as nothing in WebAuthn.dll creates problems.

We expect these Chromium changes to work in Edge as well.

 

Regards

John B.

[Martin Kreichgauer]

On Mon, Jun 28, 2021 at 3:53 PM John Bradley <jbra...@yubico.com> wrote:

Sorry, you are correct about OSX,  I confused myself by testing the wrong browser.  Too many OS / browser combinations:)

That link is now working for me.  I will pass it on to the person working on the Windows WebAuthn.dll updates so he is aware of it.  

No webauthn.dll changes are required to support this extension on Windows.

 

Is the extension in Canary now?

Not yet. It should land in time for M83. But note that only origins rooted under *.google.com are able to exercise it.

 

Thanks

John B.

[John Bradley]

Sorry, you are correct about OSX,  I confused myself by testing the wrong browser.  Too many OS / browser combinations:)

That link is now working for me.  I will pass it on to the person working on the Windows WebAuthn.dll updates so he is aware of it.  

Is the extension in Canary now?

Thanks

John B.

On Monday, June 28, 2021 at 9:19:51 AM UTC-4 Martin Kreichgauer wrote:

[John Bradley]

The U2F API is supported in Safari on OSX and I assume on iOS.   I think they added that to avoid the error when people try to make Google credentials.  

Off the top of my head, I can't think of anyone other than Google still using the U2F API other than Google, and some test pages.  

However, given that until recently the only FIPS approved keys have been U2F some gov applications may still be using U2F.

Yubico has been strongly recommending migration to WebAuthn for some time.   I can check to see if others at Yubico know of any RP still using the u2F API.

You should probably fix the link to the extension so that WebKit/Apple and perhaps FireFox could implement the new WebAuthn extension. 

I am guessing that Edge will have the option of inheriting the Chromium code so that should be no issue as long as nothing in WebAuthn.dll creates problems.

Regards

John B.

On Friday, June 25, 2021 at 5:41:29 PM UTC-4 Adam Langley wrote:

[John Bradley]

Yes now that I see the new extension, it is very google specific.  

I was mostly concerned that updates to WebAuthn.dll don't change anything.  It doesn't look like it will be a problem as long as the WebAuthn extension is not passed to the API and Crome makes the necessary switch to the U2F portion of the API.

I remember now the discussion about Apple supporting Alexei's extension to allow making credentials for Google.   Funny they added it before you.

I will check for other people still using the U2F API.  Is the depreciation plan public someplace?

John B.

[Martin Kreichgauer]

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.

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:

[Yoav Weiss]

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.

--
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.

[Martin Kreichgauer]

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.

[Yoav Weiss]

Thanks for clarifying!

[Martin Kreichgauer]

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

[Yoav Weiss]

Is it possible to keep the trial alive for 2 more milestones, but disable new registrations?

[Mike West]

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

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.