Bug 202427

***Background*** Google launched support for U2F Security Keys long before FIDO2/WebAuthn existed. As a result all Security Keys registered to Google Accounts are "bound" to the appID https://www.gstatic.com/securitykey/origins.json. The add-account-flow in Android is burned in by OEMs and cannot be updated — as a result, many Android devices only know how to speak U2F to authenticators. If Google were to begin registering Security Keys over WebAuthn — specifically, using an RP ID rather than an appID — Google users with Security Keys would not be able to sign into their accounts on the aforementioned Android devices. While Google intends to move fully to WebAuthn, the transition will take some time. ***Tweaks for create()*** The following describes the necessary behavior for any WebAuthn Client (that does not also provide a U2F API or that wants to deprecate its U2F APIs) so that users may register security keys with Google accounts. Google will eventually deprecate this behavior, therefore this behavior SHALL be controlled by a (new) WebAuthn registration extension "googleLegacyAppidSupport", which will take in a single boolean value. When set to true, the "legacy behavior" defined below will be enabled; when set to false, the behavior will be disabled. When not specified, the value of this extension is false. When receiving a WebAuthn create() request with an RP ID of google.com and the googleLegacyAppidSupport value set to true, the WebAuthn Client MUST: 1) only use the U2F transport protocol, 2) communicate only with roaming authenticators (that support U2F), and 3) use a hard-coded appID of https://www.gstatic.com/securitykey/origins.json ***Tweaks for get()*** We have previously filed bugs that describe the necessary WebAuth Client behavior changes here: https://bugs.webkit.org/show_bug.cgi?id=196046