Intent to Ship: WebAuthentication API

523 views
Skip to first unread message

kpaul...@chromium.org

unread,
Mar 19, 2018, 5:55:58 PM3/19/18
to blink-dev

Contact emails

eng...@chromium.com, kpaul...@chromium.com

 

Explainer

See the intro to the spec.

 

Spec

https://w3c.github.io/webauthn/

Tag Review

 

Summary

In M67, we intend to ship the Web Authentication API with support for FIDO U2F authenticators over USB (currently behind a the "WebAuthentication" feature flag). The API gives Web applications user-agent-mediated access to authenticators for the purposes of generating and challenging application-scoped (eTLD+k) public-key credentials. Support for other transports (BLE) and CTAP 2.0 devices to follow later this year (planned for M68).

 

Link to “Intent to Implement” blink-dev discussion

Intent to Implement

 

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

This feature is supported on Windows, Mac, Linux, and Chrome OS. Support for Android in a later release (implementation on-going, slated for M67 for U2F and M68 for CTAP 2.0).

 

Demo link

https://webauthndemo.appspot.com/

 

 

Risks

Interoperability and Compatibility

This feature has low risk. Edge and Firefox both have implementations in development.

 

Edge: In development

Firefox: In development, Intent to Ship

Safari: No official signals

Web developers: No signals

 

Ergonomics

This API is an extension of the Credential Management API.

 

Activation

The basic usage of this feature is fairly straightforward. The main challenge lies in properly validating responses from authenticators. However, the spec itself is fairly hefty. The demo server (linked above) is open source (https://github.com/google/webauthndemo) and is a useful reference for developers, but more developer-focused documentation would definitely benefit adoption.

 

Is this feature fully tested by web-platform-tests?

 

This feature is currently only partially tested by web platform tests. Test coverage for most aspects of the spec would need hardware authenticator devices attached to the system in specific states.

 

Complete end-to-end testing will need a testing API that permits disconnecting the implementation from the real world, and setting up virtual authenticator devices (with the ability to configure their internal device state). This will be akin to the Web USB/Web Bluetooth Testing APIs.

 

Test suite results

 

Entry on the feature dashboard

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

 

Requesting approval to ship?

Yes


mk...@chromium.org

unread,
Mar 21, 2018, 6:20:51 AM3/21/18
to blink-dev
LGTM1. I'm very much looking forward to getting this out the door. The collaboration between Edge, Firefox, and Chrome makes it pretty likely that we'll end up with interoperable implementations quickly, and that we'll be able to use that opportunity to deprecate and remove the existing U2F extension.

On the "web developer" signals, I'm fairly certain that GitHub, at least has expressed solid interest in migrating. My understanding is that y'all have talked to the `accounts.google.com` folks as well?

Jochen Eisinger

unread,
Mar 21, 2018, 6:21:47 AM3/21/18
to mk...@chromium.org, blink-dev
lgtm2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2ba9b88d-1925-4d79-9447-e80069058f97%40chromium.org.

TAMURA, Kent

unread,
Mar 21, 2018, 11:00:49 PM3/21/18
to Jochen Eisinger, Mike West, blink-dev
LGTM3.




--
TAMURA Kent
Software Engineer, Google


kpaul...@chromium.org

unread,
Mar 22, 2018, 5:47:37 PM3/22/18
to blink-dev, joc...@chromium.org, mk...@chromium.org
Hey Mike, thanks for pointing that out. Yep, we've definitely talked with them!
Reply all
Reply to author
Forward
0 new messages