Intent to Ship: WebAuthentication API: ResidentKeyRequirement and credProps extension

[Martin Kreichgauer]

Contact emails

mart...@google.com, nsat...@chromium.org, a...@chromium.org

Explainer

https://github.com/w3c/webauthn/issues/991

Specification

https://w3c.github.io/webauthn/#dom-authenticatorselectioncriteria-residentkey

API spec

Yes

Design docs

https://github.com/w3c/webauthn/pull/1191

Summary

Adds support for the AuthenticatorSelectionCriteria.residentKey property to specify during Web Authentication API (WebAuthn) credential registration whether a client-side discoverable credential should be created. Also adds support for the WebAuthn "credProps" extension, which indicates to the Relying Party whether a created credential is client-side discoverable.

Blink component

Blink>WebAuthentication

TAG review

N/A (minor API change)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Support on Windows >= 1903 depends on Microsoft implementing it in Windows. Support on Android depends on Android's WebAuthn library supporting it. Android WebView does not support WebAuthn.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Debuggability

This feature will be supported by Chrome's Virtual Authenticator API implementation.

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

No

Support on Windows >= 1903 depends on Microsoft implementing it in Windows. Support on Android depends on Android's WebAuthn library supporting it. Android WebView does not support WebAuthn.

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

Yes. (Pending CL:2508878)

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1117630

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5701094648840192

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/hHV_nrVc-To/m/fjcfKB7zBwAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Fri, Nov 6, 2020 at 12:57 AM 'Martin Kreichgauer' via blink-dev <blin...@chromium.org> wrote:

Contact emails

mart...@google.com, nsat...@chromium.org, a...@chromium.org

Explainer

https://github.com/w3c/webauthn/issues/991

That's not an explainer. I'm sure I can get all that information from reading through the dozens of comments on the issue and the PR, but it'd be extremely helpful to me and other reviewers (as well as the general public) if you could sum up what this change is supposed to be doing, what are its implications on the API shape and how are developers supposed to be using it.

If writing it up in an explainer is too much overhead for some reason and would be relatively short, an inline explanation would work as well.

Specification

https://w3c.github.io/webauthn/#dom-authenticatorselectioncriteria-residentkey

API spec

Yes

Design docs

https://github.com/w3c/webauthn/pull/1191

Summary

Adds support for the AuthenticatorSelectionCriteria.residentKey property to specify during Web Authentication API (WebAuthn) credential registration whether a client-side discoverable credential should be created. Also adds support for the WebAuthn "credProps" extension, which indicates to the Relying Party whether a created credential is client-side discoverable.

Blink component

Blink>WebAuthentication

TAG review

N/A (minor API change)

That's not typically a valid reason to skip TAG review.

Was the change reviewed by someone? (e.g. in a WG) 

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Support on Windows >= 1903 depends on Microsoft implementing it in Windows. Support on Android depends on Android's WebAuthn library supporting it. Android WebView does not support WebAuthn.

Gecko: No signal

WebKit: No signal

Could you ask for signals?  

Web developers: No signals

Do we have reason to believe users of the API actually need this change and will use it once shipped?

 

Debuggability

This feature will be supported by Chrome's Virtual Authenticator API implementation.

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

No

Support on Windows >= 1903 depends on Microsoft implementing it in Windows. Support on Android depends on Android's WebAuthn library supporting it. Android WebView does not support WebAuthn.

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

Yes. (Pending CL:2508878)

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1117630

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5701094648840192

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/hHV_nrVc-To/m/fjcfKB7zBwAJ

This intent message was generated by Chrome Platform Status.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEa135x9a5h8oeNdqjD_%3D8uYC_EmL0Mnar4ncoUWO0pJKg%40mail.gmail.com.

[Joe Medley]

Martin,

Are you wanting to ship this in 88 or 89?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--

[Martin Kreichgauer]

On Sun, Nov 8, 2020 at 12:07 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Fri, Nov 6, 2020 at 12:57 AM 'Martin Kreichgauer' via blink-dev <blin...@chromium.org> wrote:

Contact emails

mart...@google.com, nsat...@chromium.org, a...@chromium.org

Explainer

https://github.com/w3c/webauthn/issues/991

That's not an explainer. I'm sure I can get all that information from reading through the dozens of comments on the issue and the PR, but it'd be extremely helpful to me and other reviewers (as well as the general public) if you could sum up what this change is supposed to be doing, what are its implications on the API shape and how are developers supposed to be using it.

If writing it up in an explainer is too much overhead for some reason and would be relatively short, an inline explanation would work as well.

This is a small API tweak that originated from discussions in the WebAuthn WG. It is motivated by the fact that users on the web may have security keys with different capabilities (e.g. U2F vs FIDO2 keys), and so a given WebAuthn request can't always be fulfilled by the authenticator the user has at hand. In particular, a website can't know in advance whether a user's security key supports client-side discoverable credentials (which are necessary for password-less login), or only non-discoverable credentials (which are regular 2FA sign-in credentials). Websites that want to  support both types of credentials would have to present the user with two separate security key enrollment flows, of which one could potentially fail. With this API tweak however, a website is able to request either a password-less login credential or a second-factor credential; and the browser decides which type to create based on what type of security key the user presents. 

I also have a short explanation in the "Motivation" section of the ChromeStatus entry. I'll paste that here. Happy to expand more or spin it off into a standalone document somewhere if you think that would be helpful!

Motivation
"Client-side discoverable credentials" are a type of WebAuthn credential that can be challenged by a Relying Party (RP) without needing to provide the credential ID in the WebAuthn API request. Browsers display a list of all discoverable credentials from a given authenticator (external security key or built-in) and let the user choose one to sign in with.

Chrome already supports registration of client-side discoverable WebAuthn credentials via the boolean AuthenticatorSelection.requireResidentKey property. The WebAuthn Level 2 spec adds an alternative, enum-valued residentKey property. Two values of that enum, "discouraged" and "required", correspond exactly to the boolean values of requireResidentKey. The third, middle value ("preferred") lets the RP express that the browser should try to create a client-side discoverable credential, but that it may fall back to a non-discoverable credential if the authenticator presented by the user doesn't support it (e.g. a U2F/CTAP1 security key).

The credProps extension (https://w3c.github.io/webauthn/#credprops) can be used to report at registration time whether the newly created credential is client-side discoverable or not. This is useful for the RP in the "preferred" case.

 

Specification

https://w3c.github.io/webauthn/#dom-authenticatorselectioncriteria-residentkey

API spec

Yes

Design docs

https://github.com/w3c/webauthn /pull/1191

Summary

Adds support for the AuthenticatorSelectionCriteria.residentKey property to specify during Web Authentication API (WebAuthn) credential registration whether a client-side discoverable credential should be created. Also adds support for the WebAuthn "credProps" extension, which indicates to the Relying Party whether a created credential is client-side discoverable.

Blink component

Blink>WebAuthentication

TAG review

N/A (minor API change)

That's not typically a valid reason to skip TAG review.

Was the change reviewed by someone? (e.g. in a WG) 

Yes, it was reviewed in the WebAuthn WG. It got published in WebAuthn Level 2, which is currently in Working Draft stage: https://www.w3.org/TR/webauthn-2/

 

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Support on Windows >= 1903 depends on Microsoft implementing it in Windows. Support on Android depends on Android's WebAuthn library supporting it. Android WebView does not support WebAuthn.

Gecko: No signal

WebKit: No signal

Could you ask for signals?  

I reached out to folks from those organizations and will update the thread if there are indeed signals.

 

Web developers: No signals

Do we have reason to believe users of the API actually need this change and will use it once shipped?

Yes. The FIDO Alliance recently published a best practices document for building authentication systems using security keys and the WebAuthn API. One of the use cases described there explicitly requires the residentKey=preferred option. Based on discussions

[Martin Kreichgauer]

(Hit send to early here.) Based on discussions within the Working Group, I believe participants that also use WebAuthn for sign-in on their sites find this feature useful.

[Martin Kreichgauer]

Hi Joe,

I marked it 88 for now, but depends on the timeline of this approval.

Cheers,

Martin

[Akshay Kumar]

We, at Microsoft, supports this change and are in process of implementing it for our next Windows release. 

Thanks

Akshay

Microsoft

[Daniel Bratell]

LGTM1

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4a935331-8041-4389-a58c-a207ef15da87n%40chromium.org.

[Mike West]

LGTM2.

This mechanism seems like a reasonable way of giving developers control over the kinds of credentials they accept, while not unnecessarily revealing information about the devices a user has available (as the implementation continues to be user-mediated).

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcc90e83-a54f-f758-8215-8b41c3d93abe%40gmail.com.

[Yoav Weiss]

Alex's reasoning on TAG reviews seems to apply here as well. Could y'all ask for a TAG review?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdxA6Rt5ph1Ken%2B64vCUrjwFoXByaxEjDaWh3V41O%2BhcQ%40mail.gmail.com.

[Martin Kreichgauer]

On Thu, Nov 12, 2020 at 12:51 PM Yoav Weiss <yo...@yoav.ws> wrote:

Alex's reasoning on TAG reviews seems to apply here as well. Could y'all ask for a TAG review?

In that case, I would prefer to hold off until that exception process is clarified. It is not clear to me that getting through a TAG review would be any quicker, and in any case we don't have any hard milestone requirement/deadline for this.

  

[Alex Russell]

Thanks Martin.

IIRC the TAG may have discussed an FYI process this week (I need to sync up with Alice to find out how that went), but we've anticipated that any exception process would still require filing an FYI which the TAG could skim and pull into a full review if they deem it worthwhile so it seems valuable to perhaps file one now regardless. If the FYI process ends up the way we hope, we can "downgrade" the request shortly.

Regards

[Martin Kreichgauer]

We circled back with the WebAuthn WG and we're now planning to submit WebAuthn Level 2 as a whole to TAG on behalf of the WG. Then we'll reference the "main" TAG review in the individual Intent-To-* emails as we launch Level 2 features. Level 2 as a whole is probably incremental enough that I would label it FYI if that were an option.

(More generally, I wonder if as a WG, we should have submitted L2 to TAG earlier. Probably something to keep in mind for the future.)

Cheers,
Martin

[Martin Kreichgauer]

We now have a TAG review request for WebAuthn Level 2.

[Alex Russell]

The API OWNERs discussed again and would like to see the TAG thread updated with the resolution in issue #1302. 

Pending that LGTM1, and expect OWNERS will likely approve for 89 when we meet again in January. Does that match your expected timeline?

Regards

[Alex Russell]

Thanks to Martin for correcting me and noting that this is, indeed, LGTM3.

[Martin Kreichgauer]

Thanks. Yes, approval for 89 would be great.