Last Comment Bug 1065729 - Implement the FIDO Alliance u2f javascript API
: Implement the FIDO Alliance u2f javascript API
Status: NEW
[parity-chrome] [extension available:...
: dev-doc-needed
Product: Core
Classification: Components
Component: DOM: Device Interfaces (show other bugs)
: unspecified
: All All
-- enhancement with 460 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 268835 (view as bug list)
Depends on: 1244959 1245527 1265472 1267247 1298838 1301793 1198330 1231681 1297552
Blocks: platform-ui-team
  Show dependency treegraph
 
Reported: 2014-09-10 16:07 PDT by Axel Nennker
Modified: 2017-02-10 05:31 PST (History)
422 users (show)
nalexander: needinfo? (gpoul)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
?


Attachments
u2f-webidl.patch (3.02 KB, patch)
2014-11-12 05:16 PST, Axel Nennker
no flags Details | Diff | Splinter Review
Bug1065729.patch (31.56 KB, patch)
2014-12-16 06:59 PST, Axel Nennker
no flags Details | Diff | Splinter Review
Bug1065729.patch (35.48 KB, patch)
2015-01-14 02:13 PST, Axel Nennker
no flags Details | Diff | Splinter Review

Description User image Axel Nennker 2014-09-10 16:07:08 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20140910030204

Steps to reproduce:

http://fidoalliance.org/specs/fido-u2f-javascript-api-v1.0-rd-20140209.pdf
Comment 1 User image Axel Nennker 2014-09-10 16:08:49 PDT
There is an open source extension (BSD-License) for Chrome by Google here:
https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/u2f-api.js
Comment 2 User image Paul [:pmac] McLanahan 2014-10-21 09:04:46 PDT
Google announced Chrome support this morning:

http://googleonlinesecurity.blogspot.com/2014/10/strengthening-2-step-verification-with.html
Comment 3 User image Axel Nennker 2014-10-21 19:55:57 PDT
The spec was updated this month.
https://fidoalliance.org/specifications/download
Especially
https://fidoalliance.org/specs/fido-u2f-v1.0-rd-20141008.zip

I guess it is time to create some more bugs and use this one to track them.

How difficult is usb access in Firefox? Support on different platforms will bind developer resources.

I would like to support other hardware as authenticators like SIM cards on Firefox for Android and B2G too.
We (Telekom Innovation Laboratories) are working on the Secure Element API in Firefox (B2G).
This bug is no dependency on u2f but just for info: 
https://bugzilla.mozilla.org/show_bug.cgi?id=879861

The Chromium code is here:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/cryptotoken/

Is somebody attending W3C TPAC? Sadly I am not attending.
http://www.w3.org/2014/11/TPAC/
FIDO and WebCrypto HW Tokens will be discussed in the WebCrypto session
http://lists.w3.org/Archives/Public/public-webcrypto/2014Sep/0026.html

Another good event to meet interested parties is IIW in Mountain View.
http://www.internetidentityworkshop.com/
Yubico, FIDO Alliance and Googlers are usually there.
Comment 4 User image Axel Nennker 2014-10-27 12:50:02 PDT
Dependency to WebUSB? bug 674718
Although the API https://wiki.mozilla.org/WebAPI/WebUSB seems quite highlevel and
this search
http://mxr.mozilla.org/mozilla-central/search?string=attachdevice
yields zarro results (yet).

The Chrome code for u2f usb handling
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/cryptotoken/usbgnubbydevice.js
uses: (https://developer.chrome.com/apps/usb)
chrome.usb.getDevices
chrome.usb.listInterfaces
chrome.usb.bulkTransfer
chrome.usb.closeDevice
chrome.usb.claimInterface
chrome.usb.releaseInterface
chrome.usb.requestAccess or chrome.usb.openDevice (depending on whether it is ChromeOS)

I think that we need something like bug 674718. Probably more.
Although exposing webusb to content is a currently unsolved permission/priviledge problem. So I would like to see webusb (or similar) implemented but first only for internal browser use and addons.
Comment 5 User image Harlan Lieberman-Berg 2014-11-10 11:10:45 PST
I think that tying this to WebUSB (and thus bug 674718) isn't desirable.  While they share some things in common, I'm wary of having some of the potential security challenges that come with WebUSB associated with U2F, which is explicitly a security-sensitive system.

Even if we end up leveraging some of the same underlying code in terms of interacting with USB devices, I don't think that U2F should end up leveraging WebUSB directly.
Comment 6 User image Axel Nennker 2014-11-12 05:16:38 PST
Created attachment 8521381 [details] [diff] [review]
u2f-webidl.patch

Copying the webidl fragments from the spec did not work
https://fidoalliance.org/specs/fido-u2f-javascript-api-v1.0-rd-20141008.pdf

One thing is that the data type "int" is not legal webidl. 
I replaced it with "unsigned long" and contacted the spec authors.
Other issues are that "SignRequest[]" does not go well down the throat of our webidl.parser. 
I replaced those by sequence<Signrequest> which according to the ECMAScript binding should be an array.
http://www.w3.org/TR/WebIDL/#es-sequence

The W3C webidl checker has more comments but those should be addressed by the spec authors too.
http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Faxel.nennker.de%2FU2F.webidl&output=html
Comment 7 User image Paul Holder 2014-12-05 14:50:51 PST
I wanted to post the link to the video of the presentation from Yubico.  This is a useful backgrounder for anyone who needs it.  https://air.mozilla.org/fido-u2f/
Comment 8 User image Benjamin Kerensa [:bkerensa] 2014-12-08 02:04:33 PST
I was just considering upgrading my Yubikey to their new FIDO U2F Security Key (https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/#toggle-id-3) but looks like adding this support is a blocker for me personally. 

So I guess I will subscribe and hope for support in the near future :)
Comment 9 User image Urda 2014-12-09 15:49:21 PST Comment hidden (advocacy)
Comment 10 User image Simon Josefsson 2014-12-09 23:47:39 PST
We have published a low-level C library for talking to U2F devices over USB -- https://developers.yubico.com/libu2f-host/ -- and we can relicense it as needed if you want to use it.  What remains is to work on the JavaScript side, which is something we don't have expertise in but I believe you already started on that.  If I can help with anything, including devices for testing, I'd be happy to help out.
Comment 11 User image Axel Nennker 2014-12-16 06:30:11 PST
(In reply to Simon Josefsson from comment #10)
> We have published a low-level C library for talking to U2F devices over USB
> -- https://developers.yubico.com/libu2f-host/ -- and we can relicense it as
> needed if you want to use it.  What remains is to work on the JavaScript
> side, which is something we don't have expertise in but I believe you
> already started on that.  If I can help with anything, including devices for
> testing, I'd be happy to help out.

Thanks for the library code. Regarding the license please see here:
https://www.mozilla.org/MPL/license-policy.html#Licensing_of_Third_Party_Code
It appears to me that Yubico's license for libu2f-host is not compatible with Mozilla's license.
If Yubico could relicense the libu2f-host code to Mozilla 2.0 that would be great.
Mozilla's licensing team probably has to be involved anyway. Please file a licensing bug here:
https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|mozilla.org|Licensing

Regarding building the library: I develope under Ubuntu and "./configure" fails with:
./configure: line 5259: syntax error near unexpected token `win32-dll'
./configure: line 5259: `LT_INIT(win32-dll)'

Which is probably no blocker because the code has to be turned into a component/service as decribed here:
https://developer.mozilla.org/en-US/docs/Adding_XPCOM_components_to_Mozilla_build_system

-Axel
Comment 12 User image Axel Nennker 2014-12-16 06:59:51 PST
Created attachment 8537208 [details] [diff] [review]
Bug1065729.patch

An intermediate state that contains a ton of gruft from the identity work.
I chose the Identity.webidl and stuff because Identity has a similare API that contains no DOMEvents.

Next steps:
- put libu2f-host into XPCOM component
- send messages to java on Android
- if the Secure Element API is availabe (B2G) use u2f authenticator on SE
- return results to content script. My tries resulted in an exception when the content script accesses the priviledged error object.
Comment 13 User image Simon Josefsson 2014-12-16 07:10:10 PST
We discussed applicability of libu2f-host a couple of days ago -- while we are happy to relicense it (and will probably do it just to get that issue out of the way) there are other aspects of it that will need more work: for example, currently the library is synchronous, and busy-loops waiting for U2F communications from the device.  I'm pretty sure this won't work for you.  We are adding a small tweak to add a timeout to do the looping, so the application regains control and can invoke the library again, when needed.  However, this may not be sufficient either -- do you require fully asynchronous libraries?  Alternatively, if you put our library in a separate thread it may work.

Generally, we are happy to consider fixes to libu2f-host that makes it more usable for you.
Comment 14 User image Simon Josefsson 2014-12-16 07:11:46 PST
> Regarding building the library: I develope under Ubuntu and "./configure"
> fails with:
> ./configure: line 5259: syntax error near unexpected token `win32-dll'
> ./configure: line 5259: `LT_INIT(win32-dll)'

Sounds like you need libtool, or possibly a newer version of libtool.

/Simon
Comment 15 User image Timothy Hamlett 2014-12-16 09:35:40 PST
If I can help in any way, let me know. I have a new U2F device I can test with.

/Timothy
Comment 16 User image Nibbles Dev Team 2014-12-24 00:51:59 PST Comment hidden (me-too)
Comment 17 User image Axel Nennker 2014-12-26 06:29:19 PST
Is it true that even if Yubico relicenses libu2f-host we still might have a problem because of libu2f-host uses libusb which is LGPL?
https://bugzilla.mozilla.org/show_bug.cgi?id=1115685

In https://bugzilla.mozilla.org/show_bug.cgi?id=webusb :gerv says that it is ok to use libusb if we link a dynamic library. 

So we have to collect libusb.dll, libusb.so for all supported platforms and put them into the mozilla-central tree somewhere, right?
Comment 18 User image 1tlister 2014-12-30 05:00:08 PST Comment hidden (me-too)
Comment 19 User image 1tlister 2014-12-30 05:05:07 PST Comment hidden (me-too)
Comment 20 User image Stavros Korokithakis 2015-01-08 03:34:37 PST Comment hidden (me-too)
Comment 21 User image tapiwa@gwatidzo.com 2015-01-08 07:50:25 PST Comment hidden (me-too)
Comment 22 User image tapiwa@gwatidzo.com 2015-01-08 07:50:48 PST
I have been using u2f for a while now and have a few commercial devices I can use to test the implementation of u2f in Firefox. Please include me in testing.
Comment 23 User image Urda 2015-01-08 08:13:05 PST Comment hidden (me-too)
Comment 24 User image Kashif Shah 2015-01-13 17:12:43 PST Comment hidden (me-too)
Comment 25 User image Axel Nennker 2015-01-14 02:08:06 PST
1)
I noticed that Yubico's demo page uses window.u2f while the current patch uses navigator.u2f ...
http://demo.yubico.com/start/u2f/neo

The FIDO spec about the javascript API does not specify where the API lives.

Not sure what the "standard" is or will be.

2)
My own test page http://axel.nennker.de/testu2f.html is currently bonked because I try to get a challenge from http://demo.yubico.com/wsapi/u2f/enroll?username=jas&password=foo but that server does not send a CORS header so the patched Firefox forbids the request. 
Using CORS does not make terrible sense but it is only a test page...
Using Yubico's demo page http://demo.yubico.com/start/u2f/neo seems to make more sense.

3)
Status: Played with libu2f-host, libusb, libhid on Ubuntu.
Looks like libu2f-host can be reimplemented in javascript and send the APDUs through libhid
Comment 26 User image Axel Nennker 2015-01-14 02:13:05 PST
Created attachment 8548780 [details] [diff] [review]
Bug1065729.patch

Suddenly the init method is not allowed to return something and when this happens the browser code crashes Firefox on purpose here:
http://mxr.mozilla.org/mozilla-central/source/dom/bindings/BindingUtils.cpp#2164

Removed the preferences check and do not return null.
Comment 27 User image Simon Josefsson 2015-01-14 02:16:43 PST
FWIW, libu2f-host 0.0.3 is relicensed under LGPLv2+.
Comment 28 User image arnarbi 2015-01-14 10:58:45 PST
Axel, re #25:

1) The location of the API is left unspecified until it is a proper web API. It's also left browser specific how to obtain the MessagePort to the U2F client, but if navigator.connect [1] matures into a standard, that would be a cross-browser way to get one.

The motivation for the two layered API is similar to [2]. The interface between the two layers is fully defined in [3], which is BSD licensed and so should be reusable by Mozilla.

[1] http://mkruisselbrink.github.io/navigator-connect/
[2] https://github.com/dglazkov/tubes
[3] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/u2f-api.js


2) I can help with adjusting u2fdemo.appspot.com to accommodate FF testing. That website serves as a model for other server implementations, so it'd be awesome if it supports FF.


3) Chrome's implementation is nearly all in JS. The APDUs are constructed and sent from [4] and [5], with the hid transport defined in [6] (which uses chrome.hid [7])

[4] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/gnubby.js
[5] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/gnubby-u2f.js
[6] https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/hidgnubbydevice.js
[7] https://developer.chrome.com/apps/hid

Again, this is all under a BSD style license (https://developers.google.com/open-source/licenses/bsd)


(The U2F extension on GitHub is very similar to the one built into Chrome - which you can also browse here: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/cryptotoken/ )

Feel free to ping me if I can assist in other ways.
Comment 29 User image Benjamin Kerensa [:bkerensa] 2015-01-23 18:26:47 PST
FWIW, Yubico is giving me a code to share with 200 Nightly Testers anyone who would like to test the functionality when it lands please request a code the post is up on Planet or ping me on IRC.
Comment 30 User image Timothy Hamlett 2015-01-25 10:52:40 PST
(In reply to Benjamin Kerensa [:bkerensa] from comment #29)
> FWIW, Yubico is giving me a code to share with 200 Nightly Testers anyone
> who would like to test the functionality when it lands please request a code
> the post is up on Planet or ping me on IRC.

what exactly does the code do?
Comment 31 User image Benjamin Kerensa [:bkerensa] 2015-01-25 13:27:40 PST
(In reply to Timothy Hamlett from comment #30)
> (In reply to Benjamin Kerensa [:bkerensa] from comment #29)
> > FWIW, Yubico is giving me a code to share with 200 Nightly Testers anyone
> > who would like to test the functionality when it lands please request a code
> > the post is up on Planet or ping me on IRC.
> 
> what exactly does the code do?

Allows them to have a free U2F Yubikey but they are all gone now :)
Comment 32 User image Mike Nicholls 2015-01-25 18:31:26 PST
Has much progress been made on an implementation using native libraries?  As an experiment I've written an extension which instead uses js-ctypes to discover and communicate directly with U2F devices using Windows APIs.  Currently it just opens a channel and sends a "wink" command (which incidentally seems to be broken on the Yubico U2F keys I have) as a proof-of-concept, but I've been working in my spare time on turning it into a more useful implementation.  I can finish tidying up and releasing the code if it would be useful to anyone, I'm not sure how difficult a similar approach would be for Mac and Linux but I believe it should be possible.
Comment 33 User image Axel Nennker 2015-01-26 06:31:58 PST
(In reply to Mike Nicholls from comment #32)
> Has much progress been made on an implementation using native libraries?  As
> an experiment I've written an extension which instead uses js-ctypes to
> discover and communicate directly with U2F devices using Windows APIs. 
> Currently it just opens a channel and sends a "wink" command (which
> incidentally seems to be broken on the Yubico U2F keys I have) as a
> proof-of-concept, but I've been working in my spare time on turning it into
> a more useful implementation.  I can finish tidying up and releasing the
> code if it would be useful to anyone, I'm not sure how difficult a similar
> approach would be for Mac and Linux but I believe it should be possible.

There is not much progress from my side. I am doing this in my pet-project-time too.
My plan is to put libusb under mozilla_centra/ipc/ as mozilla_central/ipc/libusb and get the mozilla build-system to build the libusb-library for the different platforms.
That library can then be used to implement an u2f-usb-handler with a js2c bridge to libusb.
I think the u2f-usb-handler api should not export the whole usb glory but something like:

dictionary UsbAuthenticator {long device; long vendorId; long productId; }
callback ListAuthenticatorsCallback = void(ListDevicesResponse or Error) response);

[JSImplementation="@mozilla.org/u2f/usbhandler;1", NoInterfaceObject, ChromeOnly]
interface U2fUsbHandler {
 listauthenticators(ListOption options, ListAuthenticatorsCallback listcallback);
 open(Authenticator authenticator, OpenAuthentitcatorCallback openCallback);
 close(Authenticator authenticator, CloseAuthenticatorCallback closeCallback);
 send(U2fRequest requestData, SendRequestCallback sendCallback);
};

The U2F implementation as a whole should allow bluetooth, SIM and NFC too.
E.g. 
- Fennec should look for U2F SIM support. 
- Fennec on a NFC capable device should read NFC-Authenticators.
- FirefoxOS should support SIM and NFC authenticators.
Comment 34 User image dattaz 2015-01-26 09:29:01 PST
Maybe Firefox os should support U2F with USB OTG (when support of OTG will be done => https://bugzilla.mozilla.org/show_bug.cgi?id=1029961 )
Comment 35 User image Daniel Holbert [:dholbert] 2015-01-27 15:36:05 PST Comment hidden (obsolete)
Comment 36 User image dennis 2015-06-02 21:37:06 PDT Comment hidden (me-too)
Comment 37 User image mikejonesey 2015-06-03 04:18:54 PDT Comment hidden (me-too)
Comment 38 User image HLFH 2015-06-03 13:52:31 PDT
Btw, it is not advisable to buy right now an U2F key right now (Yubico, Plug-Up, ...) because the FIDO 2.0 specification is on the way, that Windows 10 will probably support it, Chrome OS will update its FIDO support to the next FIDO 2.0 specification. So, it's better to wait and buy a FIDO 2.0 U2F device. Right now, it's like 5 years ago when you were buying some devices with USB 2.0 port, whereas USB 3.0 was released: manufacturers are happy to destock their obsolete technology, but not the consumers. So, for FIDO 2.0, you have to wait more than 2 months, before you could buy one FIDO U2F 2.0 device.
Comment 39 User image riccardo 2015-06-09 01:31:54 PDT
HLFH, I can't find any documentation or discussion about FIDO 2.0 specification, can you provide some reference?
Comment 40 User image cserpentis 2015-06-09 01:37:30 PDT
(In reply to HLFH from comment #38)
> Btw, it is not advisable to buy right now an U2F key right now (Yubico,
> Plug-Up, ...) because the FIDO 2.0 specification is on the way, that Windows
> 10 will probably support it, Chrome OS will update its FIDO support to the
> next FIDO 2.0 specification. So, it's better to wait and buy a FIDO 2.0 U2F
> device. Right now, it's like 5 years ago when you were buying some devices
> with USB 2.0 port, whereas USB 3.0 was released: manufacturers are happy to
> destock their obsolete technology, but not the consumers. So, for FIDO 2.0,
> you have to wait more than 2 months, before you could buy one FIDO U2F 2.0
> device.

a) FIDO 2.0 is referenced in this post only. No official information posted anywhere yet.
b) Are you implying that all U2F devices made to date will become obsolete and not supported? I.e. will 2.0 be not backward compatible?
Comment 41 User image Axel Nennker 2015-06-09 02:22:18 PDT
#offtopic
I think that devices / authenticators will not change with v2.

(In reply to cserpentis from comment #40)
> (In reply to HLFH from comment #38)
> > Btw, it is not advisable to buy right now an U2F key right now (Yubico,
> > Plug-Up, ...) because the FIDO 2.0 specification is on the way, that Windows
> > 10 will probably support it, Chrome OS will update its FIDO support to the
> > next FIDO 2.0 specification. So, it's better to wait and buy a FIDO 2.0 U2F
> > device. Right now, it's like 5 years ago when you were buying some devices
> > with USB 2.0 port, whereas USB 3.0 was released: manufacturers are happy to
> > destock their obsolete technology, but not the consumers. So, for FIDO 2.0,
> > you have to wait more than 2 months, before you could buy one FIDO U2F 2.0
> > device.
> 
> a) FIDO 2.0 is referenced in this post only. No official information posted
> anywhere yet.
> b) Are you implying that all U2F devices made to date will become obsolete
> and not supported? I.e. will 2.0 be not backward compatible?
Comment 42 User image HLFH 2015-06-09 02:49:16 PDT
a) FIDO 2.0 has not been released yet, FIDO 2.0 Specification is a draft. We could expect the final release before the end of 2015. In fact, FIDO Alliance has a FIDO 2.0 Technology Working Group: they work for FIDO 2.0 since December 2014. The co-chairmen and the affiliate members are working on it: Anthony Nadalin, Microsoft, Sampath Srinivas, Google, Ramesh Kesanupalli, Nok Nok Labs. As seen here: https://fidoalliance.org/working-groups/ ; so it's a subset of the FIDO Alliance members, and they have access to the current working drafts of the FIDO 2.0.

According to Brett McDowell, executive director of the FIDO Alliance, FIDO 2.0 should be released before Fall. If we are optimistic, FIDO 2.0 Final will be released at the same time as the General Availability of Windows 10 that will support FIDO 2.0 (https://blogs.windows.com/business/2015/02/13/microsoft-announces-fido-support-coming-to-windows-10/), so at the end of July. If we are not optimistic, FIDO 2.0 could be released in late Q4 2015. https://groups.google.com/a/fidoalliance.org/forum/#!topic/fido-dev/rhiY5UWF_N0

Google is actively working for the FIDO 2.0 specification. As soon as it will be released, Google Chrome will update its FIDO support to the 2.0 final specification. It has been confirmed at the European Identity Conference 2015, one month ago.

b) Thanks for the question. As seen on Twitter, even Yubico does not know if the U2F FIDO 1.0 devices will become obsolete, if just a firmware update could update it to the FIDO 2.0 spec, or if 2.0 will be entirely backward-compatible. https://twitter.com/shanytc/status/578231973656850432

So because Yubico does not know, I asked the question on the FIDO Dev community group. We could expect a answer before the end of the week. IMHO, U2F 1.0 devices will become obsolete, but we need confirmation from the executive director of the FIDO Alliance. https://groups.google.com/a/fidoalliance.org/forum/#!topic/fido-dev/zvS9BM8HXLQ
Comment 43 User image Mike Robinson 2015-06-09 17:22:50 PDT
(In reply to HLFH from comment #42)
> b) Thanks for the question. As seen on Twitter, even Yubico does not know if
> the U2F FIDO 1.0 devices will become obsolete, if just a firmware update
> could update it to the FIDO 2.0 spec, or if 2.0 will be entirely
> backward-compatible.

Thanks for all the information. However I just wanted to comment that upgrading firmware on Yubico devices is not possible (see https://www.yubico.com/faq/upgrade-yubikey-firmware/) so if 2.0 it isn't backwards compatible, people who have a 1.0 device will need to purchase a new one if they need 2.0 support.
Comment 44 User image V. Korn 2015-06-14 13:25:05 PDT
Ok, there is reply made by FIDO person for HLFH
"FIDO 2.0 is not being designed to render anything we've done before obsolete.  On the contrary, it is designed to spread FIDO to more client systems in the ecosystem by means of specific optimizations that make it easier for platforms (i.e. operating systems, web browsers, etc.) to bake in FIDO support "out of the box", enabling our vision of ubiquitous support for FIDO authentication.    Although some of the required optimizations may require the actual wire protocol to be different in 2.0, our strategy for ensuring backwards compatibility is tied to our recently launched FIDO Certification Program.  Going forward server vendors/implementers will be incentivized to provide backward compatibility for all FIDO Certified client devices, UAF 1.X, U2F 1.X, and 2.0.  This enables the 2.0 specifications to be fit-for-purpose to enable native platform support while helping to ensure full backward compatibility in the market going forward for all FIDO Certified authenticators and clients/browsers.

As to your question about implementers pushing out updates to their 1.X implementations to make them 2.0 compliant, this is really up to the implementation, by each FIDO vendor: FIDO Device vendors can decide to build their FIDO devices in a way that allows for upgrading the firmware to support 2.0.  

 	Brett McDowell"

I suppose this means "1.0 devices will still be supported"?
Comment 45 User image Anders Rundgren 2015-06-16 08:02:41 PDT
I think FIDO support in Firefox OS would be more interesting than a desktop implementation.
Comment 46 User image u541675 2015-06-16 10:58:23 PDT
(In reply to V. Korn from comment #44)
> 
> I suppose this means "1.0 devices will still be supported"?

First, I want to thank everyone involved in this effort to FIDO-enable FireFox and/or FireFox OS.  It is a great start having this standard supported in Chrome, but users need choice and it is great to think FireFox might be browser platform #2 to ship with support for FIDO U2F 1.0.  

To answer the question about 1.0 device support, I want to offer my full endorsement for U2F 1.0 implementation in FireFox now.  Not only will U2F 1.0 exist after FIDO 2.0 is out, but the implementation of U2F 1.0 in Mozilla's platforms now, will help the 2.0 implementation in the future as there should be quite a bit of code re-use.

So "YES", the strategy within FIDO Alliance is to foster the growth of this ecosystem starting with 1.0 clients, servers, and devices then expand that ecosystem through broader platform support with 2.0 and backwards compatibility for 1.0 clients and devices baked into FIDO server implementations that can support all previously certified FIDO 1.0 devices.

Hope that helps,
--Brett
Comment 47 User image V. Korn 2015-06-18 11:06:10 PDT Comment hidden (me-too)
Comment 48 User image Anders Rundgren 2015-06-18 11:13:33 PDT Comment hidden (off-topic)
Comment 49 User image Brad Hill 2015-06-18 11:19:33 PDT
+1 to not waiting for 2.0 APIs.  The U2F use case is independently valuable and likely to endure even as the more sophisticated APIs take shape and see deployment.  It is also relatively trivial for service providers to implement, but the motivation to do so is substantially less so long as its reach is Chromium-only.  A Firefox implementation would be a really big deal for organizations currently on-the-fence about adding U2F support alongside things like SMS, Google Authenticator and the like.
Comment 50 User image V. Korn 2015-06-20 10:51:57 PDT
(In reply to Brad Hill from comment #49)
> +1 to not waiting for 2.0 APIs.  The U2F use case is independently valuable
> and likely to endure even as the more sophisticated APIs take shape and see
> deployment.  It is also relatively trivial for service providers to
> implement, but the motivation to do so is substantially less so long as its
> reach is Chromium-only.  A Firefox implementation would be a really big deal
> for organizations currently on-the-fence about adding U2F support alongside
> things like SMS, Google Authenticator and the like.

Its not only organizations(and its users) who can use U2F to get additional security. For example plugins to implement U2F in Joomla CMS (https://www.akeebabackup.com/download/yubikey/yubikey-2-0-0.html) and WordPress already made. This means, that possible area of U2F use maybe much wider then it looks.
Comment 51 User image dennis 2015-06-21 00:07:29 PDT Comment hidden (advocacy)
Comment 52 User image Devdatta Akhawe [:devd] 2015-06-22 20:32:11 PDT Comment hidden (me-too)
Comment 53 User image luke@faraone.cc 2015-06-27 11:59:51 PDT Comment hidden (me-too)
Comment 54 User image Lukas 2015-06-29 14:44:20 PDT
Google just announced, that Google Apps will use this. http://googleappsupdates.blogspot.com/2015/06/a-special-offer-and-new-controls-for.html
Comment 55 User image Corey Richardson (:cmr) 2015-07-06 19:13:33 PDT Comment hidden (advocacy)
Comment 56 User image jolamb 2015-07-07 06:49:42 PDT Comment hidden (me-too)
Comment 57 User image Tony Arcieri 2015-07-07 19:56:03 PDT
I would also be rather excited to see this feature added to Firefox. We are considering an enterprise rollout of mandatory U2F for our SSO system at my employer (Square), so if Firefox doesn't support it this would entail banning employees from using Firefox.

I'd hate to see that!
Comment 58 User image riccardo 2015-07-15 17:42:18 PDT
Totally serious, with the best intentions: since the main objective of the FIDO Alliance is to make U2F successful, why don't they just hire a developer for 1-2 months to add support on Firefox, which is probably the biggest gain they can have for the money spent? (I ask here because surely someone from FIDO is reading this thread).
Comment 59 User image Gerhard Poul 2015-07-16 08:54:52 PDT
(In reply to riccardo from comment #58)
> Totally serious, with the best intentions: since the main objective of the
> FIDO Alliance is to make U2F successful, why don't they just hire a
> developer for 1-2 months to add support on Firefox, which is probably the
> biggest gain they can have for the money spent? (I ask here because surely
> someone from FIDO is reading this thread).

What is concerning for me is that this is not assigned and it is not clear to me who to contact even if I would want to contribute to this effort.
Comment 60 User image Nick Alexander :nalexander 2015-07-16 09:32:07 PDT
(In reply to Gerhard Poul from comment #59)
> (In reply to riccardo from comment #58)
> > Totally serious, with the best intentions: since the main objective of the
> > FIDO Alliance is to make U2F successful, why don't they just hire a
> > developer for 1-2 months to add support on Firefox, which is probably the
> > biggest gain they can have for the money spent? (I ask here because surely
> > someone from FIDO is reading this thread).
> 
> What is concerning for me is that this is not assigned and it is not clear
> to me who to contact even if I would want to contribute to this effort.

It's not assigned because we have nobody working on it.  (To be honest, assignment isn't even a guarantee somebody is working on it, or that the time-frame is relevant, etc.)  More specifically, this doesn't feature in any web platform or Fennec roadmap that I'm aware of.

However, I am interested in this ticket, watch the discussion (which lately is +1s -- valuable feedback but not technically actionable), and worked a little bit with Axel Nennker on an implementation, which fizzled.  I can help guide some of the integration into Fennec.  In general, mobile-firefox-dev [1] is a great place to start discussion, ask for help, etc.

The concrete proposed way to make this happen on Android has a lot of pre-requisites that I can't help with: landing a USB library into Gecko, for example, or implementing WebUSB.  It would help me to know if this could be done purely in Android Java.

[1] https://mail.mozilla.org/listinfo/mobile-firefox-dev
Comment 61 User image mike 2015-07-27 09:16:47 PDT Comment hidden (me-too)
Comment 62 User image Richard Barnes [:rbarnes] 2015-07-30 11:07:02 PDT
Nick is correct that there is nobody assigned to work on FIDO right now, at least in terms of MoCo.

Beyond issues of resource prioritization, the major barrier (for me at least) is that it's not clear that the current U2F API is at the right level of abstraction.  APIs that get added to the web have to have a good deal of longevity, because it is very hard to remove features from the web.  The current U2F API is totally specific to FIDO, and as nice as FIDO is, I'm not totally convinced that it's a forever solution.  (I think there is a solution to be found here.  Tanvi and I are starting to look at whether the proposed Credentials API might be a sensible framework.)

If people would like to contribute in the mean time, the main thing that is lacking in Gecko at the moment is a USB HID API.  That's the channel that FIDO uses to talk to hardware, and Gecko doesn't currently expose it.  If someone were to build an HID API that were accessible from privileged JS, then I think it would be straightforward to build an extension to do FIDO in the short run (e.g., by porting the Chrome extension), and it would help any more direct implementation of FIDO in the long run.
Comment 63 User image Nick Alexander :nalexander 2015-07-30 11:31:50 PDT
(In reply to Richard Barnes [:rbarnes] from comment #62)
> Nick is correct that there is nobody assigned to work on FIDO right now, at
> least in terms of MoCo.
> 
> Beyond issues of resource prioritization, the major barrier (for me at
> least) is that it's not clear that the current U2F API is at the right level
> of abstraction.  APIs that get added to the web have to have a good deal of
> longevity, because it is very hard to remove features from the web.  The
> current U2F API is totally specific to FIDO, and as nice as FIDO is, I'm not
> totally convinced that it's a forever solution.  (I think there is a
> solution to be found here.  Tanvi and I are starting to look at whether the
> proposed Credentials API might be a sensible framework.)

I know little about the Credentials API but think that it looks like a good direction to pursue.

> If people would like to contribute in the mean time, the main thing that is
> lacking in Gecko at the moment is a USB HID API.  That's the channel that
> FIDO uses to talk to hardware, and Gecko doesn't currently expose it.  If
> someone were to build an HID API that were accessible from privileged JS,
> then I think it would be straightforward to build an extension to do FIDO in
> the short run (e.g., by porting the Chrome extension), and it would help any
> more direct implementation of FIDO in the long run.

I agree with this assessment (as I hinted at in https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c60).  I'd like to offer (again) my help making a Android-only, Java-only solution happen.  If there's a way to do this in an Android App, there's easy progress to be made.
Comment 64 User image Jeffrey Walton 2015-07-30 11:36:31 PDT
(In reply to Richard Barnes [:rbarnes] from comment #62)
> Nick is correct that there is nobody assigned to work on FIDO right now, at
> least in terms of MoCo.
> 
> Beyond issues of resource prioritization, the major barrier (for me at
> least) is that it's not clear that the current U2F API is at the right level
> of abstraction.  APIs that get added to the web have to have a good deal of
> longevity, because it is very hard to remove features from the web.  The
> current U2F API is totally specific to FIDO, and as nice as FIDO is, I'm not
> totally convinced that it's a forever solution.  (I think there is a
> solution to be found here.  Tanvi and I are starting to look at whether the
> proposed Credentials API might be a sensible framework.)

Some might also argue FIDO has architectural defects that should be addressed. The design is effectively the TLS equivalent of RSA-key transport, where attackers can use a privileged position for the Chess Grandmaster attack. The adversary can just shepherd packets between the user and the server and the protocol is no wiser. (And others would argue that's a feature).
Comment 65 User image semenko 2015-07-30 11:48:43 PDT
(In reply to Jeffrey Walton from comment #64)
> Some might also argue FIDO has architectural defects that should be
> addressed. The design is effectively the TLS equivalent of RSA-key
> transport, where attackers can use a privileged position for the Chess
> Grandmaster attack. The adversary can just shepherd packets between the user
> and the server and the protocol is no wiser. (And others would argue that's
> a feature).

This is mitigated by TLS channel binding. See: http://www.browserauth.net/
Comment 66 User image Brad Hill 2015-07-30 11:53:03 PDT
BTLE for U2F was recently announced:
https://fidoalliance.org/fido-alliance-equips-u2f-for-mobile-and-wireless-applications/

If there is nobody to work on USB support in FF, maybe an easier first step would be to re-use the internal plumbing that supports https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API and build a U2F API on top of that.
Comment 67 User image Tony Arcieri 2015-08-04 23:54:32 PDT
(In reply to Jeffrey Walton from comment #64)
> Some might also argue FIDO has architectural defects that should be
> addressed.

While every claim you make is technically true, those are problems that are common to similar standards, and can be addressed by other IETF WGs as a layered approach. For example, U2F should work well in conjunction with whatever origin-bound certificate solution is produced by the Tokbind WG.

U2F definitely doesn't solve everything out of the gate, but I think it's disingenuous to suggest it has to.
Comment 68 User image Jeffrey Walton 2015-08-05 21:40:47 PDT Comment hidden (off-topic)
Comment 69 User image Tony Arcieri 2015-08-06 03:42:46 PDT Comment hidden (off-topic)
Comment 70 User image Jeffrey Walton 2015-08-06 05:06:22 PDT Comment hidden (off-topic)
Comment 71 User image mike 2015-08-06 07:01:51 PDT
Logistically, there are several manufacturers making FIDO U2F tokens: Yubikey, Hyperfido, Nitrokey. FIDO might not be a consensus based standards organization as some would wish, but this doesn't detract from the intrinsic technical merit of the U2F protocol. There is no silver bullet for authentication. Certainly passwords are here to stay. But we have to start giving people some better option. From an economic perspective, U2F offers a way for domains to adopt a token that they don't have to issue--people can buy one online from their favorite retailer. This overcomes one of the biggest hurdles to deployment--being able to use your token as a credential for more than one website. Also Google 2FA already supports U2F (you can register one or more tokens), and Microsoft also seems supportive. Whatever you think of these two giants, their blessing helps to provide some adoption critical mass.

A firefox plugin (or even native support) for U2F would help move the ball forward in a small but meaningful way.
Comment 72 User image Tom Geompse 2015-08-06 08:19:41 PDT Comment hidden (obsolete)
Comment 73 User image Zach Lym 2015-08-11 13:10:48 PDT
Agree with @Tom, I think that the FIDO v1 vs v2 might be off-topic as well.  It sounds like an incremental upgrade and since we are repurposing Chrome's code for the core logic, I seriously doubt v2 will require that much additional labor.  I would support keeping v1 behind a config flag so as to remove any concerns regarding long-term maintenance.
Comment 74 User image carl.hoerberg 2015-08-12 12:28:52 PDT
Dropbox added support for U2F (to their >400M users) today: https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
Comment 75 User image Axel Nennker 2015-08-13 07:19:45 PDT
To move forward with this bug I suggest to split work and create new bugs for Android and FirefoxOS.
Core/common stuff like webidl can stay here or move to a separate new bug.
libusb/libhid stuff can stay here or move to a separate new bug.

-  Implement the FIDO Alliance u2f javascript API on Android
   + forward parameters to java side
   1 send parameters through NFC to token, read response
   2 send parameters through BTLE to token, read response
   3 send parameters through openmobile API, read response
   + send response back to content script

-  Implement the FIDO Alliance u2f javascript API for FirefoxOS 
   + forward parameters to java side
   1 send parameters through NFC to token, read response
   2 send parameters through Bluetooth, read response
   3 send parameters through SecureElement API, read response
   + send response back to content script
Comment 76 User image Clint 2015-10-01 11:19:02 PDT
Github added support for U2F today:

https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
Comment 77 User image mark 2015-10-01 11:35:03 PDT
Microsoft is currently working on adding U2F to Edge ('In Development'):
https://dev.modern.ie/platform/status/fido20webapis/
Comment 78 User image Daner 2015-10-03 07:42:53 PDT
Yubico has a special offer for github users: https://www.yubico.com/github-special-offer/

Please grab a key and implement the support on FireFox ;-)
Comment 79 User image roidelapluie 2015-10-10 06:17:44 PDT Comment hidden (off-topic)
Comment 80 User image malu_pigi 2015-10-11 14:06:01 PDT Comment hidden (advocacy)
Comment 81 User image Nick Alexander :nalexander 2015-10-12 15:02:54 PDT
(In reply to malu_pigi from comment #80)
> It have been about a year now since this bug (feature request) was created,
> any updates on the current developments? Do you (Firefox) have any estimate
> on when this feature might land to the stable release users?

Sadly I have no information here, other than that I am not aware of any group inside of Mozilla prioritizing this.

billm,andym: could one of you comment on whether the Web Extensions APIs will expose USB access to extensions, and perhaps on what timeline?  That would allow interested fishers to catch their own fish.

Contributions gladly accepted!
Comment 82 User image Bill McCloskey (:billm) 2015-10-12 16:29:29 PDT
It would be nice to be able to do this as an extension. Chrome has an app API for USB:
https://developer.chrome.com/apps/usb
We don't have any plans to implement it though. So far I haven't seen demand for USB outside of this bug.
Comment 83 User image Stefan Neufeind 2015-10-12 16:38:33 PDT
Well, I know of one manufacturer who offers a webapp to reprogram networking-gear attached via USB. They use Chrome for that since they offer their WebUSB-API. Afaik it's an open and published standard? And if Firefox were to offer that USB-API as well ... :-)
Comment 84 User image Martin Giger [:freaktechnik] 2015-10-12 16:41:17 PDT
(In reply to Stefan Neufeind from comment #83)
> Well, I know of one manufacturer who offers a webapp to reprogram
> networking-gear attached via USB. They use Chrome for that since they offer
> their WebUSB-API. Afaik it's an open and published standard? And if Firefox
> were to offer that USB-API as well ... :-)
See bug 674718 for that API.
Comment 85 User image matt 2015-10-13 08:35:23 PDT Comment hidden (me-too)
Comment 86 User image matt 2015-10-13 08:35:40 PDT Comment hidden (me-too)
Comment 87 User image malu_pigi 2015-10-13 11:20:33 PDT Comment hidden (advocacy)
Comment 88 User image asq 2015-10-14 00:25:02 PDT Comment hidden (advocacy)
Comment 89 User image dennis 2015-10-14 00:50:11 PDT Comment hidden (spam)
Comment 90 User image Charlie 2015-10-22 21:31:48 PDT
My new U2F token just arrived from this promotion from Github and Yubikey announced three weeks ago:
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication

The setup instructions are here:
https://www.yubico.com/support/documentation/how-to-use-your-yubikey-with-github/

The first bullet under “Required Pieces for Setting Up Your U2F-Compliant YubiKey with GitHub” says “Latest version of Google Chrome browser.”

I prefer Firefox mainly for reasons of https://www.mozilla.org/en-US/about/manifesto/ but this turn of events is concerning.

I will subscribe to this issue and leave the yubikey in a drawer for now, looking forward to the day Firefox supports U2F authentication.
Comment 91 User image bpeters.284 2015-10-23 03:28:38 PDT Comment hidden (advocacy)
Comment 92 User image Tom Geompse 2015-10-23 03:49:26 PDT Comment hidden (advocacy)
Comment 93 User image richi 2015-10-23 04:40:09 PDT
I decided to redirect my annual mozilla donation to the bounty : 
https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api
If half of the subscribers of this bug would do that, they have and incentive to prioritize.
Comment 94 User image Jeffrey Walton 2015-10-23 05:08:21 PDT Comment hidden (off-topic)
Comment 95 User image Jeroen Hoek 2015-10-23 05:20:49 PDT Comment hidden (advocacy)
Comment 96 User image Michael Kliewe 2015-10-23 05:29:55 PDT Comment hidden (advocacy)
Comment 97 User image J. Ryan Stinnett [:jryans] (use ni?) 2015-10-23 05:32:29 PDT
Please leave bug comments for technical discussion of this issue.  Bugzilla is not the right place to debate what Mozilla should do.

Mailing lists are a better place to discuss use cases, priorities, and such. For example, the dev-platform or firefox-dev lists seem appropriate here.
Comment 98 User image Charlie 2015-10-23 09:28:41 PDT Comment hidden (me-too)
Comment 99 User image Charlie 2015-10-24 09:27:54 PDT Comment hidden (advocacy)
Comment 100 User image Pawel Chmielowski 2015-10-24 09:36:55 PDT
I just published experimental extension that allow to use yubico as second factor in u2f, it can be found here: https://addons.mozilla.org/pl/firefox/addon/u2f-support-add-on/ (i also made source code public and it can seen here: https://github.com/prefiks/u2f4moz)

This extension was create in just couple afternoons, and it was not tested much, and it was almost exclusively used on linux, so macos and windows versions could still have some problems.

It should work on http://demo.yubico.com/u2f, and if you spoof user agent to present your browser as chrome, you can also use it on dropbox, doesn't work with github - code on that page works only in chrome.

People brave enough to test it, please report issues as github tickets.
Comment 101 User image soumagne.alexis 2015-10-24 11:54:36 PDT Comment hidden (off-topic)
Comment 102 User image mozilla 2015-10-24 13:23:02 PDT Comment hidden (off-topic)
Comment 103 User image Martin 'Nexus' Mlynář 2015-10-24 13:59:27 PDT Comment hidden (off-topic)
Comment 104 User image u540843 2015-10-24 14:02:07 PDT Comment hidden (off-topic)
Comment 105 User image Frédéric MARTIN 2015-10-24 15:14:05 PDT
1) First, I put 50$ on this bounty, I will convince other people to do so... but please, 
everyone, let's all participate ! (there is still works to do!)

https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api

2) Regarding the first beta plugin, thanx Pawel ! that's a great start !
On http://demo.yubico.com/u2f, it kind-of-works with Yubico tokens but not correctly with tokens from Plugup/happlink or from Neowave that are not supposed to be present from the beginning (no button). I will make further tests and reports with other products too through github tickets like Pawel Chmielowski asked.
Comment 106 User image V. Korn 2015-10-24 18:52:55 PDT Comment hidden (off-topic)
Comment 107 User image mikejonesey 2015-10-25 02:52:49 PDT Comment hidden (off-topic)
Comment 108 User image Garrett Robinson [:grobinson] 2015-10-26 08:24:33 PDT
Please take further discussion of the extension elsewhere, this bug is for discussing a native implementation in Firefox.
Comment 109 User image mike 2015-10-26 08:27:59 PDT
@pawel Gluu would be happy to host this project on our github, http://github.com/gluufederation and donate QA resources to help test it with various U2F devices on the Gluu Server...
Comment 110 User image Garrett Robinson [:grobinson] 2015-10-26 08:32:06 PDT
Speaking of a native implementation: in Comment 62, Richard Barnes pointed out that "the main thing that is lacking in Gecko at the moment is a USB HID API". I filed Bug 1198330 a while back to address the first part of adding a USB HID API to Gecko: incorporating a low-level USB HID library into the Firefox codebase. Once we have a low-level library that can speak the HID protocol directly to devices, we can create a high-level API (nsIHidService or what have you) that we can then expose to chrome script to implement U2F in the manner that Chrome did (via an extension).

I've submitted a patch to Bug 1198330 [0] that builds HIDAPI (the same HID library used by Yubico's libu2f-host) into mozilla-central. I'm not sure who to ask for a review, so if anybody on this bug thinks they can do it or know someone who can, go for it!

p.s. For some reason I can't add 1198330 as a dependency of this bug. If anybody else knows why I can't edit the "Depends on:" field, please let me know!

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1198330#c2
Comment 111 User image Jason Bradford 2015-10-29 10:55:58 PDT
If you want me to connect you with the people who invented the FIDO code, please let me know who I should introduce. 4 months ago, they expressed interest in us enabling FIDO functionality in FFox and would likely assist, definitely answer questions to make this a reality.
Comment 112 User image Ben Toews 2015-10-29 11:00:39 PDT Comment hidden (off-topic)
Comment 113 User image Eugene Crosser 2015-10-29 23:58:34 PDT
Please let me add something constructive (albeit tangential) to this derailed discussion ;-)

Many devices, notably phones, but also notebooks and desktops, have NFC sensors. U2F has can be used [over NFC](https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-nfc-protocol.html), and at least recent Yubikey NEOs support this standard.

It would be advantageous to design Firefox U2F support in layers, so that both "raw" USB HID and [pcsc](https://pcsclite.alioth.debian.org/) could be used. Pcsc Lite is apparently the most widely used cross-platform middleware for both NFC and serial smartcard access.
Comment 114 User image Frédéric MARTIN 2015-10-30 04:33:27 PDT
>Please let me add something constructive (albeit tangential) to this derailed discussion ;-)
>Many devices, notably phones, but also notebooks and desktops, have NFC sensors. 
>U2F has can be used [over NFC](https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-nfc-protocol.html), and at least recent Yubikey NEOs support this standard. 
> It would be advantageous to design Firefox U2F support in layers, so that
> both "raw" USB HID and [pcsc](https://pcsclite.alioth.debian.org/) could be
> used. Pcsc Lite is apparently the most widely used cross-platform middleware
> for both NFC and serial smartcard access


FIDO U2F over BLE or NFC supports are different subjects and these supports will be mostly used directly inside smartphone apps (and probably not even much inside smartphones browsers)... and even there, PCSC is out of scope, but I don't won't to discuss this here :) Note : Yubico do not yet support the new U2F over NFC specifications (noone officially does), they made their own tests and demonstrations with their RFID enabled models (dual NXP chip based) but on a day to day basis, these key owners are using USB. The first compatibility tests with the new BLE and NFC specifications are currently being done by few manufacturers, focusing on smartphone applications market.

On our side here, let's focus on asking for a simple standard FIDO U2F support inside Dekstop Firefox... A year passed without a real Mozilla reaction, let's stay simple and ask them to support existing FIDO U2F USB Security keys.
Comment 115 User image Matt H 2015-11-03 09:57:12 PST Comment hidden (advocacy)
Comment 116 User image arnarbi 2015-11-03 10:34:01 PST Comment hidden (off-topic)
Comment 117 User image ein.hacker 2015-11-04 14:38:17 PST Comment hidden (off-topic)
Comment 118 User image J. Ryan Stinnett [:jryans] (use ni?) 2015-11-04 14:51:41 PST
(In reply to Matt H from comment #115)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #97)
> > Please leave bug comments for technical discussion of this issue.  Bugzilla
> > is not the right place to debate what Mozilla should do.
> 
> This is the only place people can comment! So I expect more will. 

Mailing lists in fact are the place where Firefox priorities are discussed today.

> Mailing
> lists are inaccessible and invisible to most people. 

I understand what you are saying, but that does not change what communication channels are used by the Mozilla project today.  If you wish to affect the priority of this feature, I would recommend discussing it in the right place, which is firefox-dev mailing list and not this bug's comments.

> I found
> https://mail.mozilla.org/pipermail/firefox-dev/ but it's not obvious how to
> search it or reply to posts.

A searchable archive of the mailing list is available at https://groups.google.com/forum/#!forum/firefox-dev.  A believe you'll need to subscribe to the list itself at https://mail.mozilla.org/listinfo/firefox-dev before posting a message, though perhaps it is possible through the Google Groups interface (I've never tried).
Comment 119 User image Matthew N. [:MattN] (PM if requests are blocking you) 2015-11-04 16:49:31 PST
firefox-dev isn't the best mailing list anyways as this support would be added to the platform. mozilla.dev.platform would be a better list: https://www.mozilla.org/en-US/about/forums/#dev-platform
Comment 120 User image Charlie 2015-11-04 16:53:32 PST
(In reply to Matthew N. [:MattN] from comment #119)
> firefox-dev isn't the best mailing list anyways as this support would be
> added to the platform. mozilla.dev.platform would be a better list:
> https://www.mozilla.org/en-US/about/forums/#dev-platform

Here is a thread on that list where FIDO U2F is mentioned:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/u2f/mozilla.dev.platform/zdGJlDCiepU/Nce60hRlLQAJ
Comment 121 User image Jeroen Hoek 2015-11-05 00:22:42 PST
I have started a thread on mozilla.dev.platform about Fido U2F:

https://groups.google.com/forum/#!topic/mozilla.dev.platform/WR5E2Xd4Vdg

Please contribute to the discussion about the prioritizing this issue there, and do point out anything I may have omitted relevant to the issue at hand.
Comment 122 User image Stephen Pollei 2015-11-06 17:28:21 PST Comment hidden (me-too)
Comment 123 User image andrei 2015-11-09 09:20:14 PST Comment hidden (me-too)
Comment 124 User image David Baron :dbaron: ⌚️UTC-8 2015-11-19 07:31:36 PST
W3C is working on chartering a working group to develop standards for authentication; the draft charter is at https://w3c.github.io/websec/web-authentication-charter

Today the W3C announced that the FIDO specifications have been submitted to W3C as input to that work:
http://www.w3.org/Submission/2015/02/
http://www.w3.org/Submission/2015/02/Comment/

(Note that this also means the specifications are on a path to being developed under the W3C's patent policy.)
Comment 125 User image Lawrence Mandel [:lmandel] (use needinfo) 2015-12-01 17:34:06 PST
Release Note Request (optional, but appreciated)
[Why is this notable]:
The FIDO Alliance has been developing standards for hardware-based authentication of users by websites. Their work is getting significant traction, so the Mozilla Foundation has decided to join the FIDO Alliance. Work has begun in the W3C to create open standards using FIDO as a starting point. We are proposing to implement the FIDO U2F API in Firefox in its current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for hardware-based user authentication known as “Universal Two-Factor” or U2F. This standard allows a website to verify that a user is in possession of a specific device by having the device sign a challenge with a private key that is held on the hardware device. The browser’s role is mainly (1) to route messages between the website and the token, and (2) to add the origin of the website to the message signed by the token (so that the signature is bound to the site).

Several major websites now support U2F for authentication, including Google, Dropbox, and Github. The W3C has begun the process of forming a “WebAuthentication” working group that will work on a standard for enhanced authentication using FIDO as a starting point.

[Suggested wording]: FIDO Universal Two-Factor API for hardware-based website authentication

[Links (documentation, blog post, etc)]:
https://fidoalliance.org/
https://fidoalliance.org/specifications/download/
http://w3c.github.io/websec/web-authentication-charter
Comment 126 User image Pierre Radermecker 2015-12-08 11:39:35 PST Comment hidden (advocacy)
Comment 127 User image mike 2015-12-10 09:55:40 PST Comment hidden (me-too)
Comment 128 User image Anders Rundgren 2015-12-30 23:24:44 PST Comment hidden (off-topic)
Comment 129 User image Daner 2015-12-31 00:41:25 PST Comment hidden (off-topic)
Comment 130 User image Tom Geompse 2015-12-31 00:47:08 PST Comment hidden (off-topic)
Comment 131 User image Anders Rundgren 2015-12-31 00:59:08 PST Comment hidden (off-topic)
Comment 132 User image Frédéric MARTIN 2015-12-31 07:08:49 PST Comment hidden (off-topic)
Comment 133 User image mike 2015-12-31 07:20:31 PST Comment hidden (off-topic)
Comment 134 User image Anders Rundgren 2015-12-31 07:29:39 PST Comment hidden (off-topic)
Comment 135 User image Frédéric MARTIN 2015-12-31 07:45:27 PST Comment hidden (off-topic)
Comment 136 User image andrei 2015-12-31 08:03:17 PST Comment hidden (off-topic)
Comment 137 User image Frédéric MARTIN 2015-12-31 08:12:33 PST Comment hidden (off-topic)
Comment 138 User image Joseph P. Hillenburg 2015-12-31 08:14:06 PST Comment hidden (off-topic)
Comment 139 User image mike 2015-12-31 08:16:02 PST Comment hidden (off-topic)
Comment 140 User image mike 2015-12-31 08:16:26 PST Comment hidden (off-topic)
Comment 141 User image Anders Rundgren 2015-12-31 23:49:21 PST Comment hidden (off-topic)
Comment 142 User image terje 2016-01-01 01:52:16 PST Comment hidden (off-topic)
Comment 143 User image Anders Rundgren 2016-01-01 02:44:25 PST Comment hidden (off-topic)
Comment 144 User image mashkin 2016-01-01 03:16:17 PST Comment hidden (off-topic)
Comment 145 User image Jeffrey Walton 2016-01-01 03:44:51 PST Comment hidden (off-topic)
Comment 146 User image Thom Wiggers 2016-01-01 04:44:56 PST
Can people please take this off-topic discussion elsewhere? You're spamming my mailbox with stuff that's in no way related to getting the U2F API implemented in Firefox.
Comment 147 User image Anders Rundgren 2016-01-01 05:09:36 PST Comment hidden (off-topic)
Comment 148 User image Thom Wiggers 2016-01-01 05:12:55 PST Comment hidden (off-topic)
Comment 149 User image Anders Rundgren 2016-01-01 05:25:48 PST Comment hidden (off-topic)
Comment 150 User image m.bachmann 2016-01-01 10:49:53 PST Comment hidden (advocacy)
Comment 151 User image Jason Bradford 2016-01-04 13:24:23 PST Comment hidden (off-topic)
Comment 152 User image Anders Rundgren 2016-01-04 19:55:54 PST Comment hidden (off-topic)
Comment 153 User image mike 2016-01-04 22:30:30 PST Comment hidden (off-topic)
Comment 154 User image Tony Arcieri 2016-01-04 22:40:13 PST Comment hidden (off-topic)
Comment 155 User image javucho1000 2016-01-05 06:55:51 PST Comment hidden (off-topic)
Comment 156 User image Frédéric MARTIN 2016-01-05 08:09:23 PST Comment hidden (off-topic)
Comment 157 User image Jason Bradford 2016-01-05 14:34:05 PST Comment hidden (off-topic)
Comment 158 User image Tony Arcieri 2016-01-05 22:18:51 PST Comment hidden (off-topic)
Comment 159 User image Frédéric MARTIN 2016-01-06 00:44:59 PST Comment hidden (off-topic)
Comment 160 User image Anders Rundgren 2016-01-06 13:15:31 PST Comment hidden (off-topic)
Comment 161 User image Frédéric MARTIN 2016-01-07 08:08:53 PST Comment hidden (off-topic)
Comment 162 User image Anders Rundgren 2016-01-08 01:32:35 PST Comment hidden (off-topic)
Comment 163 User image Jason Bradford 2016-01-08 10:31:50 PST Comment hidden (off-topic)
Comment 164 User image Tony Arcieri 2016-01-08 10:32:12 PST Comment hidden (off-topic)
Comment 165 User image Ian Young 2016-01-08 11:58:52 PST Comment hidden (typo)
Comment 166 User image Ian Young 2016-01-08 12:02:02 PST Comment hidden (off-topic)
Comment 167 User image Alex Willmer 2016-01-11 07:51:17 PST
FTR there's now an addon for U2F support https://addons.mozilla.org/en-GB/firefox/addon/u2f-support-add-on/, not my work and I make no claims about it's correctness.
Comment 168 User image Martin Giger [:freaktechnik] 2016-01-11 07:54:24 PST Comment hidden (off-topic)
Comment 169 User image Jason Bradford 2016-01-19 11:36:27 PST Comment hidden (advocacy)
Comment 170 User image Mad Mac 2016-01-25 03:09:03 PST
I checked out this extension  https://addons.mozilla.org/en-GB/firefox/addon/u2f-support-add-on/, with authorizing on https://github.com/ - works great. Now, if Google has made support for ...
Comment 171 User image Frédéric MARTIN 2016-01-25 03:24:10 PST Comment hidden (obsolete)
Comment 172 User image My1 2016-01-29 06:23:17 PST Comment hidden (off-topic)
Comment 173 User image Erwann Abalea 2016-01-29 06:53:51 PST Comment hidden (off-topic)
Comment 174 User image My1 2016-01-29 07:11:32 PST Comment hidden (off-topic)
Comment 175 User image Frédéric MARTIN 2016-01-29 07:20:59 PST Comment hidden (off-topic)
Comment 176 User image Frédéric MARTIN 2016-01-29 07:46:59 PST Comment hidden (off-topic)
Comment 177 User image Frédéric MARTIN 2016-01-29 08:04:42 PST Comment hidden (off-topic)
Comment 178 User image Mark Capella [:capella] 2016-01-29 08:10:52 PST Comment hidden (obsolete)
Comment 179 User image Frédéric MARTIN 2016-01-29 08:48:57 PST Comment hidden (off-topic)
Comment 180 User image My1 2016-02-01 04:47:46 PST Comment hidden (off-topic)
Comment 181 User image Frédéric MARTIN 2016-02-05 15:37:31 PST Comment hidden (off-topic)
Comment 182 User image halindrome 2016-03-08 06:39:49 PST Comment hidden (advocacy)
Comment 183 User image Cliff DesPeaux 2016-05-24 02:00:33 PDT Comment hidden (advocacy)
Comment 184 User image Anders Rundgren 2016-06-04 04:06:30 PDT Comment hidden (off-topic)
Comment 185 User image Marco Slater 2016-06-16 08:16:45 PDT Comment hidden (advocacy)
Comment 186 User image mike 2016-06-16 09:11:14 PDT Comment hidden (advocacy)
Comment 187 User image tspencer 2016-06-21 13:44:41 PDT Comment hidden (advocacy)
Comment 188 User image Pawel Kraszewski 2016-06-22 00:08:29 PDT Comment hidden (off-topic)
Comment 189 User image terje 2016-06-22 01:03:35 PDT Comment hidden (off-topic)
Comment 190 User image My1 2016-06-22 01:26:11 PDT Comment hidden (off-topic)
Comment 191 User image Frédéric MARTIN 2016-06-22 01:32:00 PDT Comment hidden (off-topic)
Comment 192 User image terje 2016-06-22 01:37:03 PDT Comment hidden (off-topic)
Comment 193 User image My1 2016-06-22 01:40:04 PDT Comment hidden (off-topic)
Comment 194 User image Daner 2016-06-22 01:43:47 PDT Comment hidden (off-topic)
Comment 195 User image Pawel Kraszewski 2016-06-22 01:46:39 PDT Comment hidden (off-topic)
Comment 196 User image Frédéric MARTIN 2016-06-22 01:53:41 PDT Comment hidden (off-topic)
Comment 197 User image My1 2016-06-22 01:56:38 PDT Comment hidden (off-topic)
Comment 198 User image Pawel Kraszewski 2016-06-22 01:59:32 PDT Comment hidden (off-topic)
Comment 199 User image terje 2016-06-22 02:01:09 PDT Comment hidden (off-topic)
Comment 200 User image Frédéric MARTIN 2016-06-22 02:15:58 PDT Comment hidden (off-topic)
Comment 201 User image Anders Rundgren 2016-06-22 07:13:28 PDT Comment hidden (off-topic)
Comment 202 User image m.bachmann 2016-06-22 08:56:45 PDT Comment hidden (off-topic)
Comment 203 User image Anders Rundgren 2016-06-22 09:04:22 PDT Comment hidden (off-topic)
Comment 204 User image tspencer 2016-06-29 16:47:16 PDT Comment hidden (off-topic)
Comment 205 User image tspencer 2016-06-29 17:23:37 PDT
After further reading it appears that the HID API library integration (Bug 1198330) is the largest hurdle at this point. I suppose I should take my question about blockers there.

Frédéric, your final bullet mentioned possible TLS Channel ID protection requirements, do you know if there is any new information on that topic?
Comment 206 User image u550630 2016-06-29 22:16:40 PDT
"TLS Channel ID protection is a requirement for Google authentication server => implement it if needed"

We should implement it either way, don't you think?
Comment 207 User image Frédéric MARTIN 2016-06-30 02:54:28 PDT
Hi Tspencer, 
Hi japerweiss.

Regarding optional TLS Channel ID protection implementation inside Firefox, I asked for it badly on other forum dev threads and I got rather non-sens answers from Mozilla devs. They said they want to wait for a  standard that will come soon (that has nothing to do with FIDO U2F... facepalm). So I hoped that this was mandatory on Google authentification servers. I asked Google team about it: they only used TLS Channel ID protection option for very few people inside their own team, not for the standard user, so I was not able to use this as an argument and I gave up. Now I am just waiting for FIDO U2F implementation on Firefox. As far as I know, mozilla devs do not plan to implement optional TLS Channel ID, so you'll have to ask for it if you want it too. 
To be fair : It does not add security on already deployed server that do not use it (Google, GitHub, DropBox...) but if one day you are planning to deploy FIDO U2F on your own sensible server, you'll probably have to make a choice and if you want the highest level of security with the best protection against MITM attacks, you'll probably have to refuse Firefox users.
Comment 208 User image Frédéric MARTIN 2016-06-30 03:15:35 PDT Comment hidden (off-topic)
Comment 209 User image Tony Arcieri 2016-06-30 09:12:03 PDT
TLS channel ID is defunct. The new replacement standard is called Token Binding, and it's being standardized through the IETF:

https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04

Chrome is shipping an implementation of an earlier revision of the spec:

https://www.chromestatus.com/feature/5097603234529280

It can be enabled at:

chrome://flags/#enable-token-binding

I'd be happy to open a separate bugzilla issue for this if one doesn't exist already.
Comment 210 User image Frédéric MARTIN 2016-06-30 14:47:13 PDT Comment hidden (off-topic)
Comment 211 User image Jason 2016-08-06 18:33:28 PDT Comment hidden (advocacy)
Comment 212 User image Baptiste Mille-Mathias 2016-08-07 00:13:04 PDT Comment hidden (offtopic)
Comment 213 User image Jason 2016-08-07 08:09:39 PDT Comment hidden (offtopic)
Comment 214 User image mike 2016-08-07 08:18:33 PDT
Jason, if you actually read the thread, you'd see there is a plugin: https://addons.mozilla.org/en-GB/firefox/addon/u2f-support-add-on/ that works pretty well (not in Private mode).
Comment 215 User image Laurentiu Nicola 2016-08-07 08:19:34 PDT
(In reply to Jason from comment #213)
> Yeah, that's the response I expected. That attitude is exactly why Firefox
> is in slow motion and increasingly losing marketshare to faster-moving
> vendors.
> 
> "OMG YOU do it" is the same brilliance that got Linux where it is in the
> desktop market: nowhere.

"I want this too" comments will always be shot down on the issue trackers of open-source projects. Bugzilla has a "vote" option you can use to show what features you're interested in. (Although I've never seen those votes making a difference.)

I'd love to see a UserVoice page for Firefox and or some other proof that users' feedback doesn't fall off into a black hole, but this is not the place to discuss it.
Comment 216 User image Jason 2016-08-07 08:37:57 PDT Comment hidden (advocacy)
Comment 217 User image Nibbles Dev Team 2016-08-07 09:53:18 PDT Comment hidden (advocacy)
Comment 218 User image Chad 2016-08-07 10:22:34 PDT
After Nicolas polite response you'd think even the more narcissistic users would think twice before broadcasting their thoughts to ~400 devs on a bug tracking board.
Comment 219 User image Tom Geompse 2016-08-07 11:07:33 PDT Comment hidden (advocacy)
Comment 220 User image mobile.microalex 2016-08-07 11:26:52 PDT Comment hidden (offtopic)
Comment 221 User image Tom Geompse 2016-08-07 11:39:40 PDT Comment hidden (offtopic)
Comment 222 User image Kevin Cox [:kevincox] 2016-08-07 11:58:07 PDT
I've refrained from commenting for a while but I'm afraid this discussion of Mozilla/Firefox process doesn't belong in this bug. If you wish to provide constructive criticism about how Firefox is developed there are mailing lists for that.

Please remember that this issue isn't being worked on due to lack of interest, it is pretty clear to me that this is a desired feature by everyone in this thread. The problem is that all available resources are being used elsewhere in places that are deemed more critical by the people providing those resources. If you want to provide resources yourself I'm sure they would be welcomed. You can contribute patches yourself, or you can hire someone to do that for you. Please don't complain about things not being worked on when the problem is due to lack of resources, all you are doing with your comments is consuming more. If you want to be helpful contributing is likely the best way.

Thanks, Kevin

Note: I am not affiliated with Mozilla in any way.
Comment 223 User image Anders Rundgren 2016-08-07 12:15:58 PDT
(In reply to Tom Geompse from comment #221)

> Meanwhile I will do U2F with Native Messaging (FF50). Because it rocks.

Native Messaging indeed rocks and would IMO have been a better path to U2F than building support directly in the browser. However, Native Messaging haven't gotten any love from the "true" Web architects so it appears to be a temporary solution.

https://bugzilla.mozilla.org/show_bug.cgi?id=1267362
Comment 224 User image Uwe Mock 2016-08-07 12:38:16 PDT Comment hidden (offtopic)
Comment 225 User image David Keeler [:keeler] (use needinfo?) 2016-08-22 13:13:36 PDT
*** Bug 268835 has been marked as a duplicate of this bug. ***
Comment 226 User image Asa Dotzler [:asa] 2016-10-06 11:44:58 PDT
It looks like Yubico is recommending people switch to Chrome because Firefox lacks this support. https://twitter.com/DrSynAck/status/783957757053562880
Comment 227 User image Jason 2016-10-06 11:49:56 PDT
Well, it wouldn't make sense to recommend a browser, like Firefox, that doesn't support a feature.
Comment 228 User image Anders Rundgren 2016-10-06 22:03:28 PDT
There is very little proof that the 2FA world of the future in general will be powered by specific authenticator devices.  File- and TEE-based keys will be the mainstream.  Mozilla could start this transition.
Comment 229 User image Uwe Mock 2016-10-06 23:53:47 PDT
Anders, I do not know  of any service or system that uses a file based key for 2FA, and TEE as a concept for 2FA was completely new to me.
Comment 230 User image Anders Rundgren 2016-10-07 00:07:50 PDT
Hi Uwe, 500 million Chinese users of mobile payment systems use file based keys for authorizing transactions.  In Sweden (my country of origin), half of the population use a mobile phone based PKI client for logging in to e-government services, on-line banking, and most recently for authorizing Person-2-Person payments.

From my (citizen/consumer) perspective, file-based keys appear to be close to a de-facto standard which FIDO won't be able to change.  With TEE-protected keys, security of virtualized tokens will meet most organizations' needs.
Comment 231 User image Uwe Mock 2016-10-07 00:15:56 PDT
Anders, thanks for pointing this out. The only file based authentication system I am aware of is the ELSTER system used by the German financial authorities, but this is single factor authentication, not 2FA.
Comment 232 User image Uwe Mock 2016-10-07 00:35:54 PDT
One more point on that - even if we're moving towards a philosophical discussion on MFA.

A file based second factor is just another "I know" factor from my point of view ("I know what that file must contain"). The "I have" factor should not be easily copyable, and this should typically be a hardware device (such as a bank card or a USB token).
Comment 233 User image Anders Rundgren 2016-10-07 01:01:05 PDT
Uwe, yeah the definition of what 2FA is apparently varies :-)

You are essentially saying that this is not good enough:
https://developer.android.com/reference/android/security/keystore/KeyProtection.html

Reality check:
French banks only offer user-id/passwords for authentication to on-line services.  In addition they allow you giving these credentials to third-party service providers acting on your behalf!

I think security experts also are unfair solely blaming the CEO of Yahoo! for the recent theft of 500 million passwords when the ultra-advanced computing platforms that we have today doesn't support 2FA out-of-the-box.  Aren't these devices actually UNFIT for the tasks they are marketed to be used for?
Comment 234 User image Frédéric MARTIN 2016-10-07 01:27:49 PDT
Hi Uwe and all, we all know -yes, Anders, you know it too- that file based auth is not secure nor easy to deploy and that TEE is a practical joke (Everyone should try to deploy his own TEE based solution before talking about how great TEE is... please...) We should all stop feeding the swedish Troll, we already have Linkedin for that, you can join the party there :) FIDO U2F is an excellent solution, U2F USB tokens are here. They work. U2F NFC cards are here. They work (on Android only of course). I am testing the first U2F Bluetooth (some with USB too) devices prototypes and again: great all in one solutions (iOS support is coming, FIDO Alliance provides iOS source for specs tests now). I am even working on using FIDO API with tweaked non-FIDO devices to provides enhanced features... so please stop answering Anders here and for personal reply mail me at fred@neowave.fr. *Stop using this bugzilla thread*
Comment 235 User image Anders Rundgren 2016-10-08 23:06:17 PDT
Frederic et al,

U2F seems to be designed for virtualization since the domain concept performs the shielding needed rather than relying on complex access control schemes like GlobalPlatform.

My new Huawei P9 Lite Android (V6) phone claims having "hardware backed keys" (presumably via some kind of TEE-scheme), so we are probably only a few Android/Chrome upgrades away from actually having U2F support out-of-the-box (but still in the box).

Anders
Swedish Troll - https://www.youtube.com/watch?v=zAG5OvGZZOs
Comment 236 User image Jeffrey Walton 2016-10-08 23:33:49 PDT
> My new Huawei P9 Lite Android (V6) phone claims having "hardware backed
> keys" (presumably via some kind of TEE-scheme), so we are probably only a
> few Android/Chrome upgrades away from actually having U2F support
> out-of-the-box (but still in the box).

Likely ARMv8 and AArch64 or Aarch32 execution environments with trust zones, supervisor mode, etc. Looking at the P9 specs, its an Cortex-A53, which is ARMv8.

Jeff
Comment 237 User image Anders Rundgren 2016-10-08 23:59:29 PDT
It is still unclear to me how embedded security solutions like above will deal with third-party browsers since there probably should be some kind of trust relation between the browser and OS.

Apple have restricted third-party apps from using vital parts of the security platform Apple created for their Apple Pay system.
Comment 238 User image Jeffrey Walton 2016-10-09 02:04:45 PDT
(In reply to Anders Rundgren from comment #237)
> It is still unclear to me how embedded security solutions like above will
> deal with third-party browsers since there probably should be some kind of
> trust relation between the browser and OS.

My bad... I was not making pro/con args or stating anything other than the likely candidates that provided the security features.

> Apple have restricted third-party apps from using vital parts of the
> security platform Apple created for their Apple Pay system.

Be careful here... Its easy to conflate or commingle vendor lock-in, anti-competitive practices and control of the data with security implementation. Google does it too. I imagine Microsoft is also doing it on the Windows platform, and Amazon is doing it on their platform. Its one of the reasons ISIS is no longer viable.

As far as I know, with a sufficiently adequate platform (like ARMv8 and an aware OS), all you need is a secure applet to handle the transaction. Any consumer program should be able to call on the services and effect a transaction as long as the user authorizes it. That Apple, Google, et al _only_ allows their programs to do it is just the lock-in and anti-competitive practices.
Comment 239 User image Anders Rundgren 2016-10-09 02:49:39 PDT
(In reply to Jeffrey Walton from comment #238)

<snip>

> As far as I know, with a sufficiently adequate platform (like ARMv8 and an
> aware OS), all you need is a secure applet to handle the transaction. Any
> consumer program should be able to call on the services and effect a
> transaction as long as the user authorizes it.

I'm not sure I fully buy into this.  It is the *relying party* that ultimately trusts client keys, right?  If keys are used by for RPs unknown programs isn't there is a risk that *their* users in some way are screwed (which RPs of course do not want)?

I may be (totally) wrong, but to me U2F appears to be sharing this particular problem with its more traditional cousins.
Comment 240 User image V. Korn 2016-10-14 15:01:55 PDT
Another genius decision - make U2F available only in e10s mode - https://bugzilla.mozilla.org/show_bug.cgi?id=1297552#c12
This is especially funny since Mozilla constantly have to disable e10s first for ru locales due bugs, then for users "which seen tab spinner to frequent".
Comment 241 User image Anders Rundgren 2016-10-15 13:04:09 PDT
Intel seems to have an excellent solution for storing U2F keys:
https://software.intel.com/en-us/sgx
Comment 242 User image Jeffrey Walton 2016-10-15 13:20:24 PDT
(In reply to Anders Rundgren from comment #241)
> Intel seems to have an excellent solution for storing U2F keys:
> https://software.intel.com/en-us/sgx

As far as I know, all the browsers lack protected storage. The only storage options available are the indexed-db type.

Data has three states: (1) data at rest, (2) data in transit and (3) data on display. Lack of protected storage is one of the reasons web apps are mostly relegated to low value data. They don't do a good job of protecting the data in state (1). They also do a rather poor job for state (2) due to curiosities like "Public Key Pinning Extension for HTTP with Overrides" (RFC 7469).
Comment 243 User image Anders Rundgren 2016-12-02 20:37:39 PST
Apparently my request for embedded U2F (transcended into W3C Web Authentication) support is/was already in the planning phase:
https://groups.google.com/forum/#!msg/mozilla.dev.platform/F0rCRF8z87E/oODctynwCwAJ

That's awesome!

Anders
Comment 244 User image Jason 2016-12-24 18:30:14 PST
Google determines that security keys, like the standard described in this thread, are the best version of 2FA in terms of people actually using it consistently:

http://arstechnica.com/security/2016/12/this-low-cost-device-may-be-the-worlds-best-hope-against-account-takeovers/
Comment 245 User image Anders Rundgren 2016-12-24 22:08:40 PST
(In reply to Jason from comment #244)
> Google determines that security keys, like the standard described in this
> thread, are the best version of 2FA in terms of people actually using it
> consistently:
> 
> http://arstechnica.com/security/2016/12/this-low-cost-device-may-be-the-
> worlds-best-hope-against-account-takeovers/

Yes, it seems that the people subscribing to this issue believe that 50K Googlers are defining the "market", while 5M Swedes and 500M Chinese using embedded "App" based security solutions do not.

Another way of describing this is that the US (together with France) is the great laggard when it comes to large scale use of 2FA.

This in no way means that FIDO/U2F is bad, I'm just questioning the market's interest in buying external security tokens, particularly for consumers/citizen solutions.

Related Estonian eID project:
http://www.zdnet.com/article/android-ios-secure-id-estonia-says-its-taking-digital-authentication-to-new-levels/

Related Luxenbourg banking project:
https://www.bil.com/byebyetoken/index-ios-en.html

Related Apple project:
http://www.recode.net/2016/12/6/13863670/apple-pay-digital-id-cards-transit-japan

The French "disaster" project:
https://www.linkedin.com/pulse/la-france-country-without-identity-anders-rundgren
Comment 246 User image Uwe Mock 2016-12-24 23:38:10 PST
Anders,

you're saying that people are not interested in buying a hardware item that is currently entirely useless because there is no software support. This is exactly what this thread is trying to change.

I bought a hardware token just because I'm a techie, and it was quite cheap. I have it in the drawer so I can use it once there is software support in the browser that I usually use.

With your type of argument, you could also claim that people have no interest in electric cars because fuel based cars are such a huge success. This is ridiculous.
Comment 247 User image Anders Rundgren 2016-12-25 04:59:44 PST
(In reply to Uwe Mock from comment #246)
> Anders,
> 
> you're saying that people are not interested in buying a hardware item that
> is currently entirely useless because there is no software support. This is
> exactly what this thread is trying to change.
> 
> I bought a hardware token just because I'm a techie, and it was quite cheap.
> I have it in the drawer so I can use it once there is software support in
> the browser that I usually use.
> 
> With your type of argument, you could also claim that people have no
> interest in electric cars because fuel based cars are such a huge success.
> This is ridiculous.

No, this is an (deliberate?) incorrect interpretation of my message which simply is that Mozilla should rather consider the 99℅+ market for U2F.  Google will most certainly do that as well but right now they cannot since that would create bad vibes within FIDO. Mozilla are seldom first with anything so this looks like an OPPORTUNITY!
Comment 248 User image Jeremiah Lee 2016-12-25 12:53:56 PST
I don't work at Google. My employer is considering switching to U2F and I don't want to have to switch to Chrome.
Comment 249 User image github 2016-12-25 13:16:49 PST
Have you seen that there seems to be already support for U2F in Firefox?
Comment 250 User image My1 2016-12-25 13:20:03 PST
there isnt really U2F Support "in" firefox, there's "just" an addon. and even though it helps it isnt as great as direct browser support
Comment 251 User image github 2016-12-25 14:03:34 PST
I don't use the add-on at all. It's a plain Firefox installation 50.1.0 and I'm able to use U2F in Fastmail, Github and Gmail.
Comment 252 User image My1 2016-12-25 14:06:17 PST
this is surprising, well actually I down'ed myself to ESR because Instantfox doesnt work anymore, but maybe I should try to set up a portable Firefox and try. but thanks for the info
Comment 253 User image aj 2016-12-25 15:38:44 PST
(In reply to github from comment #251)
> I don't use the add-on at all. It's a plain Firefox installation 50.1.0 and
> I'm able to use U2F in Fastmail, Github and Gmail.

I am on FF 50.1.0 and I tried Github @ https://github.com/settings/two_factor_authentication/configure but it shows : 

>  This browser doesn’t support the FIDO U2F standard yet. We recommend updating to the latest Google Chrome to start using security key devices.
Comment 254 User image Frédéric MARTIN 2016-12-27 07:33:28 PST
Let's have an all in one post / news :

(In reply to github from comment #251)
> I don't use the add-on at all. It's a plain Firefox installation 50.1.0 and
> I'm able to use U2F in Fastmail, Github and Gmail.

1)
No. You made a mistake somewhere. Firefox still do not support FIDO U2F natively.
Not in the stable branch (50.1.0) not in the beta (51 beta 10) no in the alpha (53 alpha 1)

Firefox devs are still working on FIDO U2F support. They did not give up. It will take some time.

For now, the only solution for firefox is to use this third-party addon (thanx again Paweł Chmielowski):
https://addons.mozilla.org/fr/firefox/addon/u2f-support-add-on/
This is working great but not on all servers (AFAIK, server side filter issues, nothing related to the addon).

Fun fact about U2F addons: since Apple still doesn't give a f*** about anything, there is now a first FIDO U2F add-on for Safari on OS X and macOS Sierra (Sierra is not "OS X" anymore. Please just don't ask.)

(In reply to Anders Rundgren from comment #247)
> > blah blah

2)
My favorite Swedish Troll is back ! Merry Xmas to you Anders! (and to all of you by the way!)

More seriously, there are already smart phone app based FIDO U2F solutions, so... your comments makes no sens at all: you are / will be able to use FIDO U2F (over BLE) smartphone apps if you want. Everyone can be happy !

Speaking about large deployment in China and so on, I am in contact with several major actors there and tested different implementations... FIDO U2F is happily welcomed there too. Feitian/FTSafe even recently decided to join FIDO alliance board members.

--

Regarding FIDO U2F dev status and FIDO news...

3)
New recent December milestone : FIDO U2F 1.1 specifications promoted to Implementation Draft Specification
• Change USB transport to conform to ISO7816-4
• NFC (ISO7816-4) support
• Bluetooth Low Energy support

Out of scope here, but first NFC and BLE products are working great. I don't know Firefox agenda about this kind of non-USB support yet. I guess it will come later.

4)
FIDO 2 / WebAuthn

There are hopes (not officially confirmed yet, but the will seems to be really back/present now!) that FIDO U2F solutions will be compatible with the new FIDO2 / WebAuthn specifications after all one way or another. More info on this "soon" (c)

--
Fred
Comment 255 User image Anders Rundgren 2016-12-27 08:47:49 PST
(In reply to Frédéric MARTIN from comment #254)

> (In reply to Anders Rundgren from comment #247)
> > > blah blah
> 
> 2)
> My favorite Swedish Troll is back ! Merry Xmas to you Anders! (and to all of
> you by the way!)
> 
> More seriously, there are already smart phone app based FIDO U2F solutions,
> so... your comments makes no sens at all: you are / will be able to use FIDO
> U2F (over BLE) smartphone apps if you want. Everyone can be happy !

No, I think way more people would be happy if they could use U2F without any investment also on a PC. The huge work Mozilla put into WebCrypto ought to match some 75℅ of the code needed.

From a product management point of view it makes perfect sense to take such a path.
Comment 256 User image Bart Genuit 2017-01-20 12:42:08 PST
Just contributed to the bounty here:
https://www.bountysource.com/issues/10401143-implement-the-fido-alliance-u2f-javascript-api

Come on guys, let's get this thing on the rails!
Comment 257 User image Dan Callahan [:callahad] 2017-01-26 08:14:44 PST
Facebook just announced support for U2F: https://www.facebook.com/notes/facebook-security/security-key-for-safer-logins-with-a-touch/10154125089265766

However, according to Hacker News comments, it does not appear to be offered to Firefox users even with the U2F add-on installed.
Comment 258 User image Adi 2017-01-26 08:24:07 PST
(In reply to Dan Callahan [:callahad] from comment #257)
> Facebook just announced support for U2F:
> https://www.facebook.com/notes/facebook-security/security-key-for-safer-
> logins-with-a-touch/10154125089265766
> However, according to Hacker News comments, it does not appear to be offered
> to Firefox users even with the U2F add-on installed.

for me it worked to register and use my Yubikeys on FB but i had to use the User Agent Switcher to force Firefox to pretend it was Chrome, after that it worked just fine with the U2F support addon.

Facebook is blocking the Firefox user agents from using U2F.
Comment 259 User image dev 2017-01-26 08:32:20 PST
(In reply to Adi from comment #258)
> Facebook is blocking the Firefox user agents from using U2F.

This totally makes sense from a UI/UX perspective. The majority of Firefox users don't use the plugin, so displaying the option to them will lead to unnecessary confusion. 

(On the other hand, a additional check for the plugin should be possible, but is probably not their highest priority, given the adoption rate of the plugin.)

I am happy that Facebook jumped on board, especially given the fact of it's increasing importance as single sing-on provider for other platforms. I also think this could be seen as another sign to give the Firefox implementation a higher priority. ;-)
Comment 260 User image Fabrizio 2017-01-26 08:51:04 PST
(In reply to Adi from comment #258)

> Facebook is blocking the Firefox user agents from using U2F.

How is it supposed to work ? You mean with U2F add-on right ? In this case, (no flame) how can you trust an add-on to manage a so important security aspect ? I am NOT saying that the author will spy .. I just want to understand ...
I am waiting an official Mozilla release.
Thanks
Comment 261 User image Frédéric MARTIN 2017-01-26 09:04:02 PST
(In reply to Fabrizio from comment #260)
> (In reply to Adi from comment #258)
> 
> > Facebook is blocking the Firefox user agents from using U2F.
> 
> How is it supposed to work ? You mean with U2F add-on right ? In this case,
> (no flame) how can you trust an add-on to manage a so important security
> aspect ? I am NOT saying that the author will spy .. I just want to
> understand ...
> I am waiting an official Mozilla release.
> Thanks

For your information, this add-on is open source :
https://github.com/prefiks/u2f4moz

and the real security (accounts keys, challenge signature) 
are done by the U2F token, usually inside its secure element / smart card chipset.
Comment 262 User image Adi 2017-01-26 09:26:44 PST
(In reply to Fabrizio from comment #260)
> I am waiting an official Mozilla release.
> Thanks

Firefox already has some bits of U2F built-in for testing and they are functional with a browser built-in software token - you can enable them via about:config - the U2F internal API is functional it's just the USB communications bit that's not finished yet.

If you want to test the u2f soft token built-in into Firefox (yes, even FF v50 has this) then enable in about:config

security.webauth.u2f
security.webauth.u2f_enable_softtoken

and reload the page. Try testing U2F now.
(make sure to disable softtoken when you're finished with tests)

The U2F API works, but beware that the soft token is only for testing. The token key has a lifetime of just 24 hours and is valid only for 24 hours before and after from the moment it's generated. (+/- 24 hours to allow for time sync variations)
 After that, the token key expires, is reset and a new key is generated when it's requested next so it won't be valid for long-term use. It's perfectly fine for testing u2f web site functions though.

Also, the built-in software token doesn't need the u2f support addon to be installed, just turn on those browser preferences.
Comment 263 User image My1 2017-01-26 10:19:16 PST
if you ask me there should be just a js call or whatever which u2f browsers answer with a true or whatever so websites dont need to keep up with what browsers do and dont support u2f, but just call that "U2F ping" as I may call it and if it answers then we can sho u2f if not, well, then not, obviously, or rather there should be general functions regarding whether js feature xy is available or not
Comment 264 User image Brad Hill 2017-01-26 10:39:50 PST
Hi, Facebook U2F implementation team here. We would love to have people using U2F with Firefox on Facebook.  

Launching a feature like this on a site as complicated as Facebook is a big project and we prioritized getting it out to users as soon as possible.  Doing feature-detection of a U2F API instead of User Agent sniffing would have required additional engineering effort due to how our system already works.

Given that the U2F add-on has only been installed in the low thousands of times ever, it just wasn't something we were able to prioritize supporting, and we don't want to have a broken experience for everyone else on stock Firefox.  It isn't ideal, but I am confident that the people who know how to install that add-on or flip the prefs to turn on built-in support can also spoof their User Agent string for now, and I did personally test and make bugfixes for this to work.  Hopefully we won't have to do this for much longer.
Comment 265 User image My1 2017-01-26 10:47:43 PST
@Brad Hill one way of avoiding a too bad experience for anyone would be if the user is on a Firefox with a compatible version that you tell them that they can use u2f with that addon and a button to tell FB that you know, acknowledge the warning and continue or something like that.
Comment 266 User image My1 2017-01-26 10:49:45 PST
or you could just say that "U2F may not work with your browser unless an add-on or similar is used" that lets users continue no matter the browser so if they have a browser which happens to play U2F either via addon or whatever can just click through and get their security.
Comment 267 User image Adi 2017-01-26 10:52:52 PST
(In reply to My1 from comment #263)
> if you ask me there should be just a js call or whatever which u2f browsers
> answer with a true or whatever[...snip...]

that "JS call" is a work in progress to become a W3C Standard but it's not finished yet.

https://www.w3.org/TR/webauthn/#api

basically, in the future a web site will be able to use JS to check if the browser provides a WebAuthentication API interface.

work on that standard is not finalized yet, so in the meantime web sites use whatever they can to identify browsers that support this.
Comment 268 User image Jeffrey Walton 2017-01-26 18:33:45 PST
(In reply to Fabrizio from comment #260)
> (In reply to Adi from comment #258)
> 
> > Facebook is blocking the Firefox user agents from using U2F.
> 
> How is it supposed to work ? You mean with U2F add-on right ? In this case,
> (no flame) how can you trust an add-on to manage a so important security
> aspect ? I am NOT saying that the author will spy .. I just want to
> understand ...
> I am waiting an official Mozilla release.

+1. I don't like conferring trust. Its a core security feature, and the browser should supply it.

It would be different if Mozilla performed the security review on the plugin and accepted the risk. But they don't vet the plugin, and they shed the risk. Mozilla's actions and position indicate users should not trust it either.

Its nothing personal against this plugin or the others. Conferring trust is a bad idea, and its gotten folks into trouble more than once.

Jeff
Comment 269 User image Anders Rundgren 2017-01-27 06:41:59 PST Comment hidden (offtopic)
Comment 270 User image Frédéric MARTIN 2017-01-27 07:24:02 PST
hi Anders again, please, again, keep your Troll tendencies out of this thread. :)
We all know you believe software protection is good enough for many people... but here we are talking about U2F, a new standard, pushed and adopted by many web services providers through hardware / secure elements. This is not BS, this is standard simple PKI with REALLY secure key storage and usage. If you don't want to talk about official FIDO U2F hardware support inside Firefox, please go to Linkedin, I will continue to read you there :) The soft token is only for testing, for now, everyone want to have nearly the same security level through different browsers when FIDO U2F is involved. Thanx.
Comment 271 User image m.bachmann 2017-01-27 07:32:31 PST
> hi Anders again, please, again, keep your Troll tendencies out of this thread. :)

I couldn't agree more. Since so long, whenever somebody tries to get productive on the topic, you, Anders, talk about your software protection stuff. Open your own thread or smth, please don't interfere here where we talk about U2F implementation. Thank you!
Comment 272 User image Adi 2017-01-27 07:40:53 PST
(In reply to Anders Rundgren from comment #269)
> To me this sounds like complete BS since the code most likely is derived
> from the WebCrypto API. If WebCrypto ever was a good idea (?), a "soft
> token" U2F would be just fine.

for testing u2f functions when developing a website you are right, a soft token is just fine as it supplements the physical presence of a hardware token. Web site developers can use it to test that their sites work with U2F without having to buy U2F keys.

for security though, it's just as vulnerable as any other password since the private key of the software token would be vulnerable to copying from disk/memory and other local-system attacks. This is why the softtoken is valid for maximum 24 hours. 

On a physical U2F key the private key never leaves the token as it is stored inside a hardware secure element on chip. The hardware key will only sign requests for authentication but will never reveal the private key that it uses for this process. Basically, an U2F key is a HSM that requires user interaction and approval for each signing operation.
Comment 273 User image Anders Rundgren 2017-01-27 08:05:51 PST Comment hidden (offtopic)
Comment 274 User image Tony Arcieri 2017-01-27 09:03:06 PST
I am (and many others are) subscribed to this issue to see updates on Firefox U2F progress.

The off-topic trolling by Anders Rundgren is extremely annoying. Are any of the moderators capable of banning him so we can keep the issue on-track?
Comment 275 User image Anders Rundgren 2017-01-27 09:15:14 PST
I will remove myself from this list.  It seems anyway to be focusing on the less than 0.5% of the Mozilla user base that will buy a USB token.
Comment 276 User image Jason Bradford 2017-01-27 10:43:06 PST
To be clear, U2F is not = to USB tokens. Multiple mobile devices are shipped as functional U2F authenticators. The recently-released Macs and quite a few Windows machines with biometric sensors and TPM/Secure elements are natively capable of being U2F authenticators. Whether this thread's intent to enable U2F functionality for anything beyond a USB key is outside my scope of awareness but this claim is technically false. There are millions od U2F-capable authenticators currently in use on the internet and it is simply up to the developers of application to choose to enable that functionality or not.
Comment 277 User image Jason 2017-01-28 04:55:04 PST Comment hidden (obsolete)

Note You need to log in before you can comment on or make changes to this bug.