Intent to Deprecate and Remove: U2F API (Cryptotoken)

778 views
Skip to first unread message

Martin Kreichgauer

unread,
Jun 11, 2021, 2:34:24 PMJun 11
to blink-dev

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

unread,
Jun 11, 2021, 2:54:34 PMJun 11
to blink-dev, 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

unread,
Jun 21, 2021, 7:16:38 PMJun 21
to Martin Kreichgauer, blink-dev
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

unread,
Jun 22, 2021, 12:32:46 AMJun 22
to Chris Harrelson, Martin Kreichgauer, blink-dev
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.

Mike West

unread,
Jun 25, 2021, 7:57:11 AMJun 25
to Yoav Weiss, Chris Harrelson, Martin Kreichgauer, blink-dev
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


PhistucK

unread,
Jun 25, 2021, 8:55:38 AMJun 25
to Mike West, Yoav Weiss, Chris Harrelson, Martin Kreichgauer, blink-dev
> 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


Martin Kreichgauer

unread,
Jun 25, 2021, 5:09:05 PMJun 25
to PhistucK, Mike West, Yoav Weiss, Chris Harrelson, blink-dev
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

unread,
Jun 25, 2021, 5:25:01 PMJun 25
to blink-dev, Martin Kreichgauer
Edge is (very) supportive of this deprecation/removal.

Christian Biesinger

unread,
Jun 25, 2021, 5:31:29 PMJun 25
to Martin Kreichgauer, PhistucK, Mike West, Yoav Weiss, Chris Harrelson, blink-dev
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

unread,
Jun 25, 2021, 5:41:29 PMJun 25
to Christian Biesinger, Martin Kreichgauer, PhistucK, Mike West, Yoav Weiss, Chris Harrelson, blink-dev
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

unread,
Jun 28, 2021, 9:19:51 AMJun 28
to John Bradley, blink-dev, Adam Langley, PhistucK, mk...@chromium.org, yoav...@chromium.org, Chris Harrelson, Christian Biesinger
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

unread,
Jun 28, 2021, 10:27:07 AMJun 28
to John Bradley, blink-dev, Adam Langley, PhistucK, mk...@chromium.org, yoav...@chromium.org, Chris Harrelson, Christian Biesinger
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

unread,
Jun 28, 2021, 11:17:09 AMJun 28
to blink-dev, Martin Kreichgauer, blink-dev, Adam Langley, PhistucK, mk...@chromium.org, yoav...@chromium.org, Chris Harrelson, Christian Biesinger, 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

unread,
Jun 28, 2021, 11:17:25 AMJun 28
to blink-dev, Adam Langley, Martin Kreichgauer, PhistucK, mk...@chromium.org, yoav...@chromium.org, Chris Harrelson, blink-dev, Christian Biesinger
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

unread,
Jun 28, 2021, 11:49:47 AMJun 28
to Martin Kreichgauer, blink-dev, Adam Langley, PhistucK, mk...@chromium.org, yoav...@chromium.org, Chris Harrelson, Christian Biesinger
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

unread,
Sep 22, 2021, 4:32:14 PMSep 22
to blink-dev, 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

unread,
Sep 23, 2021, 8:18:30 AMSep 23
to Martin Kreichgauer, blink-dev
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.

Martin Kreichgauer

unread,
Sep 23, 2021, 1:45:54 PMSep 23
to Yoav Weiss, blink-dev
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

unread,
Sep 23, 2021, 2:50:12 PMSep 23
to Martin Kreichgauer, blink-dev
Thanks for clarifying!
Reply all
Reply to author
Forward
0 new messages