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
Link to entry on the feature dashboard
https://www.chromestatus.com/features/6413248798654464
Requesting approval to ship?
NoOn 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.
3) We have no plans to ship the FIDO U2F API, now or in the future.
open-sourced Polyfill library
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.
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.
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.
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.--JuanDavidAt 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.