Intent to Implement and ship: aligning U2F attestation with webauthn

[Adam Langley]

Chrome has never supported the FIDO U2F API directly. However, it does ship with an internal extension and it's possible to implement the U2F API by using postMessage to send messages to this extension if you know its ID.

Chromium/Blink is implementing the W3C webauthn specification which will ultimately subsume the U2F API and have cross-browser support. As part of that transition we are aligning attestation behaviour between webauthn and our pseudo-U2F support.

This does not involve any Blink changes but a handful of sites do implement U2F by postMessaging our internal extension, thus web developers may need to be aware of this.

Starting with Chrome 66 an additional member of the RegisterRequest object is supported that mirrors AttestationConveyancePreference from webauthn. Sites that have been using the U2F API will experience a change in behavior as the default will no longer cause the device's attestation information to be returned. To get the old behavior, sites should add an "attestation" member to the RegisterRequest object with the value "direct". However, they should note that this will trigger a permission prompt. This new behaviour is the same as specified by webauthn.

Only a single site is known to care about the attestation information in U2F and we will be contacting them directly in advance of this.

There is an enterprise policy option to additionally control things. For full details, see https://www.chromium.org/security-keys

This is https://www.chromestatus.com/features/5667614588141568

Cheers

AGL

[Rick Byers]

Thanks for the heads up, and for working to replace U2F with webauthn.

From a blink process perspective, I'm not too concerned with how we're changing the implementation details of a Chrome-specific extension which sites could have been depending on (especially when it's part of a plan to finally eliminate the hack of depending on a pre-installed extension!).  LGTM1

--
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/CAL9PXLyKS2xwuUBbzeB8iUdBx9JKc9hZvBXgXNV6CiVAcrQ4jA%40mail.gmail.com.

[Mike West]

LGTM2.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_hAxUVT8KCv94fBjeZZ0B8cMn8DOqpBNEKogzAFy-dBg%40mail.gmail.com.

[Ben Toews]

Thanks for the update Adam. We at GitHub are pretty excited to see browsers moving forward with webauthn. For our U2F implementation, we don't particularly care about the attestation certificate, so I'd prefer not to add the new, but I'm curious how it is being removed from the RegisterResponse. The length of the attestation certificate isn't specified in the RegisterResponse, so the RP needs to parse the certificate in order to find the offset of the signature.

[Chris Harrelson]

LGTM3

--

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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fe4048cd-adc9-4786-b31b-e9f01448f7c6%40chromium.org.