Hi all,

Some naive questions to understand what's happened here.

Is
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api
the
API that will be added to Firefox?

Is
https://cs.chromium.org/chromium/src/chrome/browser/resources/cryptotoken/enroller.js
the
relevant bit of code in Chromium?

Is https://github.com/grantila/u2f-api the mentioned Google-supplied
polyfill called u2f-api.js?

On Thu, Mar 21, 2019 at 3:08 PM Henri Sivonen <hsivo...@mozilla.com> wrote:

> On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones <j...@mozilla.com> wrote:
> > It appears that if we want full security key support for Google
> > Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> > API support from “experimental and behind a pref”
>
> I think it's problematic to describe something as "experimental" if
> it's not on path to getting enabled. "Experimental and behind a pref"
> sounds like it's on track to getting enabled, so simultaneously 1)
> sites have a reason to believe they don't need to do anything for
> Firefox, since for now users can flip a pref and the feature is coming
> anyway and 2) still the feature doesn't actually work by default for
> users, and, considering the penalty of using an experimental feature
> where the experiment fails is getting locked out of an account for
> this particular feature.
>
> So I think it's especially important to move *somewhere* from the
> "experimental and behind a pref" state: Either to interop with Chrome
> to the extent required by actual sites (regardless of what's de jure
> standard) or to clear removal so that the feature doesn't look like
> sites should just wait for it to get enabled and that the sites expect
> the user to flip a pref.
>
> As a user, I'd prefer the "interop with Chrome" option.
>
> > to either “enabled
> > by default” or “enabled for specific domains by default.” I am
> > proposing the latter.
>
> Why not the former? Won't the latter still make other sites wait in
> the hope that if they don't change, they'll get onto the list
> eventually anyway?
>
> > First, we only implemented the optional Javascript version of the API,
> > not the required MessagePort implementation [3]. This is mostly
> > semantics, because everyone actually uses the JS API via a
> > Google-supplied polyfill called u2f-api.js.
>
> Do I understand correctly that the part that is actually needed for
> interop is implemented?
>
> > As I’ve tried to establish, I’ve had reasons to resist shipping the
> > FIDO U2F API in Firefox, and I believe those reasons to be valid.
> > However, a multi-year delay for the largest security key-enabled web
> > property is, I think, unreasonable to push upon our users. We should
> > do what’s necessary to enable full security key support on Google
> > Accounts as quickly as is  practical.
>
> This concern seems to apply to other services as well.
>
> > I’ve proposed here making the FIDO U2F API whitelist a pref. I can’t
> > say whether I would welcome adding more domains to it by default; I
> > think we’re going to have to take them on a case-by-case basis.
>
> What user-relevant problem is solved by having to add domains to a
> list compared to making the feature available to all domains?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to