Intent to Implement: FIDO U2F JavaScript API

574 views
Skip to first unread message

Kimberly Paulhamus

unread,
Oct 28, 2016, 3:57:03 PM10/28/16
to blin...@chromium.org, Juan Lang, Casey Piper

Contact emails

kpaul...@google.com, juan...@google.com, pip...@google.om


Spec

Review Draft: FIDO U2F JavaScript API (although this spec has been approved as an Implementation Draft, it hasn't been re-published yet).


Summary

A web platform API to support Universal Second Factor (U2F).


This allows developers to register 2F devices and sign challenges with registered devices.


Motivation

These APIs are currently available to developers via a component extension. We are committed to supporting this API and believe it's a better experience for developers if we provide this functionality as a real API in Chrome instead of through an extension hack.


Interoperability and Compatibility Risk

Firefox: Shipped
Edge: No public signals
Safari: No public signals
Web developers: Positive


Low risk. Google already offers this API via the u2f Chrome extension and an open-sourced Polyfill library (refer to https://u2fdemo.appspot.com/ and https://github.com/google/u2f-ref-code/). Multiple web properties have integrated with U2F, and Mozilla additionally supports this API.


Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will be supported on all platforms except for Android WebView.


OWP launch tracking bug

https://crbug.com/660458


Link to entry on the feature dashboard

https://www.chromestatus.com/features/6413248798654464


Requesting approval to ship?

No

Boris Zbarsky

unread,
Oct 28, 2016, 4:24:15 PM10/28/16
to Kimberly Paulhamus, blin...@chromium.org, Juan Lang, Casey Piper
On 10/28/16 3:56 PM, 'Kimberly Paulhamus' via blink-dev wrote:
> Interoperability and Compatibility Risk
>
> Firefox: Shipped

That... does not seem to be correct. Firefox has an experimental
implementation of a FIDO U2F API, this experimental implementation does
not, at first glance, match the draft you linked to [1], and the
experimental implementation is hidden behind a preference which is not
turned on for any channels right now.

> Low risk. Google already offers this API via the u2f Chrome extension
> and an open-sourced Polyfill library (refer to
> https://u2fdemo.appspot.com/and
> https://github.com/google/u2f-ref-code/). Multiple web properties have
> integrated with U2F, and Mozilla additionally supports this API.

Just as a warning, the web property integration with "u2f" (whatever
that means to those web properties) makes it _more_ likely that there is
compat risk than if no one were using anything with this general name in
the wild. I know for a fact that if I flip the U2F API pref in Firefox
then some parts of the Dropbox website stop working, for example. I
haven't checked whether that's because the experimental implementation
in Firefox is lacking, or because Firefox and Dropbox have different
expectations for how the API works, or something else.

-Boris

[1] Note that matching the draft would mean that you could never get
your hands on a u2f object, which rather severely limits the usefulness
of the API as described in the draft. This draft needs some work.

Boris Zbarsky

unread,
Oct 28, 2016, 4:34:31 PM10/28/16
to Kimberly Paulhamus, blin...@chromium.org, Juan Lang, Casey Piper
On 10/28/16 4:24 PM, Boris Zbarsky wrote:
> [1] Note that matching the draft would mean that you could never get
> your hands on a u2f object, which rather severely limits the usefulness
> of the API as described in the draft. This draft needs some work.

It's also pretending to use Web IDL but actually using some other
similar interface definition language it made up, I think.

And it's also not defining anywhere what the methods in the API it
defines actually _do_. That makes it hard to evaluate whether the
optional but also nullable numbers it's passing around actually make
sense, but more importantly makes it hard to know what an implementation
should actually do.

Like I said, needs some work. ;)

-Boris

Boris Zbarsky

unread,
Oct 28, 2016, 5:27:32 PM10/28/16
to Kimberly Paulhamus, blin...@chromium.org, Juan Lang, Casey Piper, Richard Barnes
On 10/28/16 3:56 PM, 'Kimberly Paulhamus' via blink-dev wrote:
> Firefox: Shipped

OK, I have just talked to Richard (cced) about what our (Mozilla's)
position is on this API. It is the following, if I understand correctly:

1) We have an implementation of the FIDO U2F API behind a pref so people
can experiment with it.

2) We plan to ship the API being developed at
https://w3c.github.io/webauthn/ once it stabilizes.

3) We have no plans to ship the FIDO U2F API, now or in the future.

-Boris

Juan Lang

unread,
Oct 28, 2016, 5:28:42 PM10/28/16
to Boris Zbarsky, Kimberly Paulhamus, blink-dev, Casey Piper, Richard Barnes
2016-10-28 14:27 GMT-07:00 Boris Zbarsky <bzba...@mit.edu>:
On 10/28/16 3:56 PM, 'Kimberly Paulhamus' via blink-dev wrote:
Firefox: Shipped

OK, I have just talked to Richard (cced) about what our (Mozilla's) position is on this API.  It is the following, if I understand correctly:

1) We have an implementation of the FIDO U2F API behind a pref so people can experiment with it.

Yep. We misspoke about the status. Sorry about that.
 
2) We plan to ship the API being developed at https://w3c.github.io/webauthn/ once it stabilizes.

Understood.

3) We have no plans to ship the FIDO U2F API, now or in the future.

Thanks for clarifying your position.
--Juan 

smaug

unread,
Oct 28, 2016, 7:26:27 PM10/28/16
to Kimberly Paulhamus, blin...@chromium.org, Juan Lang, Casey Piper, jjo...@mozilla.com
On 10/28/2016 10:56 PM, 'Kimberly Paulhamus' via blink-dev wrote:
> Contact emails
>
> kpaul...@google.com <mailto:kpaul...@google.com>, juan...@google.com <mailto:juan...@google.com>, pip...@google.om <mailto:pip...@google.om>
>
>
> Spec
>
> Review Draft:FIDO U2F JavaScript API <https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html>(although
> this spec has been approved as an Implementation Draft, it hasn't been re-published yet).
>
>
> Summary
>
> A web platform API to support Universal Second Factor (U2F).
>
>
> This allows developers to register 2F devices and sign challenges with registered devices.
>
>
> Motivation
>
> These APIs are currently available to developers via a component extension. We are committed to supporting this API and believe it's a better
> experience for developers if we provide this functionality as a real API in Chrome instead of through an extension hack.
>
>
> Interoperability and Compatibility Risk
>
> Firefox: Shipped
this is not right. It is behind a pref which isn't enabled by default.


> Edge: No public signals
> Safari: No public signals
> Web developers: Positive
>
>
> Low risk. Google already offers this API via the u2f Chrome extension and an open-sourced Polyfill library (refer to https://u2fdemo.appspot.com/and
> https://github.com/google/u2f-ref-code/). Multiple web properties have integrated with U2F, and Mozilla additionally supports this API.
>
>
> Ongoing technical constraints
>
> None.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> This feature will be supported on all platforms except for Android WebView.
>
>
> OWP launch tracking bug
>
> https://crbug.com/660458
>
>
> Link to entry on the feature dashboard <https://www.chromestatus.com/>
>
> https://www.chromestatus.com/features/6413248798654464
>
>
> Requesting approval to ship?
>
> No
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

PhistucK

unread,
Oct 29, 2016, 4:58:48 AM10/29/16
to Kimberly Paulhamus, blink-dev, Juan Lang, Casey Piper

On Fri, Oct 28, 2016 at 10:56 PM, 'Kimberly Paulhamus' via blink-dev <blin...@chromium.org> wrote:
open-sourced Polyfill library

​Where is that? Or do you meant the open source Chrome extension?​



PhistucK

PhistucK

unread,
Oct 29, 2016, 5:03:32 AM10/29/16
to Kimberly Paulhamus, blink-dev, Juan Lang, Casey Piper
So Firefox is opposed and there are no public signals from others. Looks like a bad idea.


PhistucK

PhistucK

unread,
Oct 29, 2016, 5:04:47 AM10/29/16
to Kimberly Paulhamus, blink-dev, Juan Lang, Casey Piper
Also, can the positive web developer signals be backed somehow?


PhistucK

Rick Byers

unread,
Oct 31, 2016, 10:34:20 AM10/31/16
to PhistucK, Kimberly Paulhamus, blink-dev, Juan Lang, Casey Piper, Emily Schechter, Mike West
Hi Kimberly,
Thanks for posting this intent, and for working on these use cases.  I think we can all agree that fixing auth on the web not to rely on passwords is incredibly important and urgent for the health of the web!  +Mike and Emily from the web platform security team who have a lot of experience getting consensus between browser vendors on credential/security web APIs.

Can you comment on the relationship between the W3C Web Authentication API and the FIDO API?  I see the Google editors of the FIDO spec are also editors on the W3C spec.  Is the plan that the W3C API will support all the same use cases as the FIDO API?  I.e. is there any reason that we'd want to support both APIs long term, or is one strictly a superset of the other?

The primary goal of blink's "intent" process for new APIs is to minimize the risk that we'll ship something that'll end up being a Chrome-only API indefinitely (since our mission is to improve the whole web, and we know developers generally don't adopt browser-specific APIs).  In addition to Boris's feedback (thanks Boris!) I see a number of other interoperability warning signs with the FIDO API.  For example, in the web standards we've learned that the best way to reduce interop risk is to encourage public discussion between the desired implementors as early as possible.  From the FIDO spec I can't seem to find any public list of open spec issues, and it seems the only way to provide feedback on the spec is via a "contact us" form. Has there been any public discussion on the API with Microsoft, Apple or Mozilla that you can point to?

Absent public support from at least one other browser vendor, I'd consider the interoperability risk to be very high, and so unlikely something we'd want to ship.

Rick



Jochen Eisinger

unread,
Oct 31, 2016, 10:36:52 AM10/31/16
to Rick Byers, PhistucK, Kimberly Paulhamus, blink-dev, Juan Lang, Casey Piper, Emily Schechter, Mike West
Thanks for the detailed responses!

In addition to what Rick mentions, I think it would be good to also discuss the relation to the credential management API.

best
-jochen

Juan Lang

unread,
Oct 31, 2016, 1:57:07 PM10/31/16
to PhistucK, Kimberly Paulhamus, blink-dev, Casey Piper

PhistucK

unread,
Oct 31, 2016, 2:01:32 PM10/31/16
to Juan Lang, Kimberly Paulhamus, blink-dev, Casey Piper
Calling it a "polyfill" is a bit of a stretch... It is not a strictly web based, it requires a Chrome extension or application. But thank you.


PhistucK

Juan Lang

unread,
Oct 31, 2016, 2:37:39 PM10/31/16
to Rick Byers, PhistucK, Kimberly Paulhamus, blink-dev, Casey Piper, Emily Schechter, Mike West
Hi Rick,

2016-10-31 7:33 GMT-07:00 Rick Byers <rby...@chromium.org>:
Hi Kimberly,
Thanks for posting this intent, and for working on these use cases.  I think we can all agree that fixing auth on the web not to rely on passwords is incredibly important and urgent for the health of the web!  +Mike and Emily from the web platform security team who have a lot of experience getting consensus between browser vendors on credential/security web APIs.

Can you comment on the relationship between the W3C Web Authentication API and the FIDO API?  I see the Google editors of the FIDO spec are also editors on the W3C spec.  Is the plan that the W3C API will support all the same use cases as the FIDO API?  I.e. is there any reason that we'd want to support both APIs long term, or is one strictly a superset of the other?

The W3C Web Authentication API is a superset of the FIDO API. Over the long term, we want to provide a path for web developers to move to web standards. That is, n years from now, we think web developers would be using the Web Authentication API rather than the FIDO API.

At the same time, when Chrome launched U2F support, it did so without having gone through a public API discussion. Sending this intent to implement was in part motivated by a desire to rectify that. We would also like to implement U2F in a way compatible with how Mozilla is doing so, so web developers don't have to make a choice between their approach and ours.

The primary goal of blink's "intent" process for new APIs is to minimize the risk that we'll ship something that'll end up being a Chrome-only API indefinitely (since our mission is to improve the whole web, and we know developers generally don't adopt browser-specific APIs).  In addition to Boris's feedback (thanks Boris!) I see a number of other interoperability warning signs with the FIDO API.  For example, in the web standards we've learned that the best way to reduce interop risk is to encourage public discussion between the desired implementors as early as possible.  From the FIDO spec I can't seem to find any public list of open spec issues, and it seems the only way to provide feedback on the spec is via a "contact us" form. Has there been any public discussion on the API with Microsoft, Apple or Mozilla that you can point to?

No :p Unfortunately the FIDO Alliance doesn't allow non-members to open new spec issues directly. While we've spoken with Mozilla and Microsoft about the API draft, those discussions were either not recorded (when they happened face to face) or they happened in the FIDO Alliance.

Absent public support from at least one other browser vendor, I'd consider the interoperability risk to be very high, and so unlikely something we'd want to ship.

Understood. Thanks for that feedback.
--Juan 

David Benjamin

unread,
Oct 31, 2016, 2:45:20 PM10/31/16
to Juan Lang, Rick Byers, PhistucK, Kimberly Paulhamus, blink-dev, Casey Piper, Emily Schechter, Mike West
On Mon, Oct 31, 2016 at 2:37 PM 'Juan Lang' via blink-dev <blin...@chromium.org> wrote:
Hi Rick,

2016-10-31 7:33 GMT-07:00 Rick Byers <rby...@chromium.org>:
Hi Kimberly,
Thanks for posting this intent, and for working on these use cases.  I think we can all agree that fixing auth on the web not to rely on passwords is incredibly important and urgent for the health of the web!  +Mike and Emily from the web platform security team who have a lot of experience getting consensus between browser vendors on credential/security web APIs.

Can you comment on the relationship between the W3C Web Authentication API and the FIDO API?  I see the Google editors of the FIDO spec are also editors on the W3C spec.  Is the plan that the W3C API will support all the same use cases as the FIDO API?  I.e. is there any reason that we'd want to support both APIs long term, or is one strictly a superset of the other?

The W3C Web Authentication API is a superset of the FIDO API. Over the long term, we want to provide a path for web developers to move to web standards. That is, n years from now, we think web developers would be using the Web Authentication API rather than the FIDO API.

By superset, do you mean superset in functionality or in the API itself? At a glance, it looks like the FIDO API defines window.u2f.sign and window.u2f.register along with a low-level postMessage based API (which sends dictionaries with type keys "u2f_register_request" and "u2f_sign_request"). I don't see any of those in the W3C Web Authentication API.

David

Juan Lang

unread,
Oct 31, 2016, 2:54:24 PM10/31/16
to David Benjamin, Rick Byers, PhistucK, Kimberly Paulhamus, blink-dev, Casey Piper, Emily Schechter, Mike West
2016-10-31 11:45 GMT-07:00 David Benjamin <davi...@chromium.org>:
On Mon, Oct 31, 2016 at 2:37 PM 'Juan Lang' via blink-dev <blin...@chromium.org> wrote:
Hi Rick,

2016-10-31 7:33 GMT-07:00 Rick Byers <rby...@chromium.org>:
Hi Kimberly,
Thanks for posting this intent, and for working on these use cases.  I think we can all agree that fixing auth on the web not to rely on passwords is incredibly important and urgent for the health of the web!  +Mike and Emily from the web platform security team who have a lot of experience getting consensus between browser vendors on credential/security web APIs.

Can you comment on the relationship between the W3C Web Authentication API and the FIDO API?  I see the Google editors of the FIDO spec are also editors on the W3C spec.  Is the plan that the W3C API will support all the same use cases as the FIDO API?  I.e. is there any reason that we'd want to support both APIs long term, or is one strictly a superset of the other?

The W3C Web Authentication API is a superset of the FIDO API. Over the long term, we want to provide a path for web developers to move to web standards. That is, n years from now, we think web developers would be using the Web Authentication API rather than the FIDO API.

By superset, do you mean superset in functionality or in the API itself? At a glance, it looks like the FIDO API defines window.u2f.sign and window.u2f.register along with a low-level postMessage based API (which sends dictionaries with type keys "u2f_register_request" and "u2f_sign_request"). I don't see any of those in the W3C Web Authentication API.

Good point! I mean superset in functionality.

For those not following along with the U2F APIs on a daily basis:
The FIDO U2F API defines a "high level" API, with window.u2f.sign and window.u2f.register methods. This is the approach taken by Mozilla.
It also defines the low-level postMessage-based API, which is what Chrome implements.

As you say, the W3C Web Authentication API defines neither of these constructs. Instead, we expect people will be able to call the W3C Web Authentication APIs in a way that yields results compatible with the FIDO U2F APIs. See e.g. this commit and this issue for some modifications to the web authentication API to support this usage.
--Juan

Rick Byers

unread,
Oct 31, 2016, 3:41:22 PM10/31/16
to Juan Lang, David Benjamin, PhistucK, Kimberly Paulhamus, blink-dev, Casey Piper, Emily Schechter, Mike West
On Mon, Oct 31, 2016 at 2:54 PM, Juan Lang <juan...@google.com> wrote:
2016-10-31 11:45 GMT-07:00 David Benjamin <davi...@chromium.org>:
On Mon, Oct 31, 2016 at 2:37 PM 'Juan Lang' via blink-dev <blin...@chromium.org> wrote:
Hi Rick,

2016-10-31 7:33 GMT-07:00 Rick Byers <rby...@chromium.org>:
Hi Kimberly,
Thanks for posting this intent, and for working on these use cases.  I think we can all agree that fixing auth on the web not to rely on passwords is incredibly important and urgent for the health of the web!  +Mike and Emily from the web platform security team who have a lot of experience getting consensus between browser vendors on credential/security web APIs.

Can you comment on the relationship between the W3C Web Authentication API and the FIDO API?  I see the Google editors of the FIDO spec are also editors on the W3C spec.  Is the plan that the W3C API will support all the same use cases as the FIDO API?  I.e. is there any reason that we'd want to support both APIs long term, or is one strictly a superset of the other?

The W3C Web Authentication API is a superset of the FIDO API. Over the long term, we want to provide a path for web developers to move to web standards. That is, n years from now, we think web developers would be using the Web Authentication API rather than the FIDO API.

By superset, do you mean superset in functionality or in the API itself? At a glance, it looks like the FIDO API defines window.u2f.sign and window.u2f.register along with a low-level postMessage based API (which sends dictionaries with type keys "u2f_register_request" and "u2f_sign_request"). I don't see any of those in the W3C Web Authentication API.

Good point! I mean superset in functionality.

For those not following along with the U2F APIs on a daily basis:
The FIDO U2F API defines a "high level" API, with window.u2f.sign and window.u2f.register methods. This is the approach taken by Mozilla.
It also defines the low-level postMessage-based API, which is what Chrome implements.

As you say, the W3C Web Authentication API defines neither of these constructs. Instead, we expect people will be able to call the W3C Web Authentication APIs in a way that yields results compatible with the FIDO U2F APIs. See e.g. this commit and this issue for some modifications to the web authentication API to support this usage.
--Juan
 

David
 
At the same time, when Chrome launched U2F support, it did so without having gone through a public API discussion. Sending this intent to implement was in part motivated by a desire to rectify that. We would also like to implement U2F in a way compatible with how Mozilla is doing so, so web developers don't have to make a choice between their approach and ours.

The primary goal of blink's "intent" process for new APIs is to minimize the risk that we'll ship something that'll end up being a Chrome-only API indefinitely (since our mission is to improve the whole web, and we know developers generally don't adopt browser-specific APIs).  In addition to Boris's feedback (thanks Boris!) I see a number of other interoperability warning signs with the FIDO API.  For example, in the web standards we've learned that the best way to reduce interop risk is to encourage public discussion between the desired implementors as early as possible.  From the FIDO spec I can't seem to find any public list of open spec issues, and it seems the only way to provide feedback on the spec is via a "contact us" form. Has there been any public discussion on the API with Microsoft, Apple or Mozilla that you can point to?

No :p Unfortunately the FIDO Alliance doesn't allow non-members to open new spec issues directly. While we've spoken with Mozilla and Microsoft about the API draft, those discussions were either not recorded (when they happened face to face) or they happened in the FIDO Alliance.

Absent public support from at least one other browser vendor, I'd consider the interoperability risk to be very high, and so unlikely something we'd want to ship.

Understood. Thanks for that feedback.

Thanks for the details Juan!

Note that I appreciate the desire to get something out there for web sites to use as fast as possible.  I think we've learned from the failure of the web to react fast enough to the shift to mobile and we have a number of new strategies to help better balance fast innovation with consensus building.  For example, rather than investing in a native Chrome implementation of the FIDO API, you might want to consider doing an origin trial for some early version / subset of the Web Authentication API.  Perhaps it's even possible we could find an minimum-viable subset of the Web Authentication API which could ship in Chrome 100% (without unreasonable interop risk) in whatever timeframe you were hoping to get the FIDO API shipped?

Juan Lang

unread,
Nov 4, 2016, 6:22:07 PM11/4/16
to Rick Byers, David Benjamin, PhistucK, Kimberly Paulhamus, blink-dev, Casey Piper, Emily Schechter, Mike West
Hi folks,

Yes. Thanks everyone for your input and suggestions! We've decided not to continue with the U2F API, and instead to focus our effort on the webauthn APIs being developed in the W3C. Expect to hear more from us in the not too distant future.

Thanks again!
--Juan
Reply all
Reply to author
Forward
0 new messages