Intent to Prototype: WebAuthn remoteClientDataJSON Extension

[Chromestatus]

Contact emails

jam...@microsoft.com, Zachar...@microsoft.com, ti...@micrsosoft.com

Explainer

https://github.com/bobomb/MSEdgeExplainers/blob/9838480febdc51033b46e2d9d7a9d1813df890f1/WebAuthnRemoteClientDataJSON/explainer.md

Specification

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

Summary

Allows a caller to provide a complete clientDataJSON string for a WebAuthn ceremony, which the browser passes through to the authenticator without modification. This enables remote desktop web clients to forward WebAuthn requests with the exact clientDataJSON from the remote host, preventing signature verification failures caused by differences between the browser-constructed and host-provided clientDataJSON.

Blink component

Blink>WebAuthentication

Web Feature ID

webauthn

Motivation

The remoteClientDataJSON extension for the Web Authentication API allows a caller to provide a complete clientDataJSON string for a WebAuthn ceremony, which the browser passes through to the authenticator without modification. This enables remote desktop web clients to forward WebAuthn requests with the exact clientDataJSON from the remote host, preventing signature verification failures caused by differences between the browser-constructed and host-provided clientDataJSON.

Initial public proposal

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

Goals for experimentation

None

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/506062130

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5127601250238464?gate=6194074211188736

This intent message was generated by Chrome Platform Status.

[Ari Chivukula]

In the explainer, the default for the new permissions policy is 'none', however I don't believe this is currently supported in the codebase except as a speculative prototype: https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/permissions_policy/permissions_policy_features.h;drc=5e79508c687fc220ac05fb45dfc582ae69ebfb42;l=41

Implementing it would require its own launch and spec change. It might be worth seeking feedback specifically on that point from chrome-privac...@google.com on the early side (before pursuing experiment or launch).

~ Ari Chivukula (Their/There/They're)

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69eba302.710a0220.18de8c.0119.GAE%40google.com.

[Mofidul Jamal]

I've created a design doc for this feature to give context:  WebAuthn remoteClientDataJSON Extension — Chromium Design Doc - Google Docs
I've filled in most of the relevant sections, a few missing sections I will add to soon.

I had a few questions:

1. The authorized remote origin list will piggyback off the existing enterprise policy, but there will also be a flag to set them for non enterprise environments. Do you feel this is appropriate? The authorization mechanism will be via the existing WebAuthenticationRemoteDesktopAllowedOrigins, the new remoteClientDataJSON feature flag (either set via experimental features or when shipped hardcoded to enabled), and optionally an allowed origins flag in case the enterprise policy is not available. I believe this is in line with the text of the spec, which requires the origin list to be configurable, either via enterprise policy or explicit user opt-in. I haven't settled what to do when both the enterprise origin allowlist is set and the origin allowlist is set via flag for this new feature, but I am leaning towards only using the enterprise policy origin list and ignoring the flag in that case.
2. Can the feature remain in experimental state with the permissions policy default allowlist of `self` until the permissions policy default allowlist of `none` is implemented? In patchset 2 of  [webauthn] Add remoteClientDataJSON IDL and Blink bindings (7848162) · Gerrit Code Review I've opted to give this feature it's own flag instead of re-using an existing flag, and have set it to experimental. Together with  [webauthn] Process remoteClientDataJSON in browser (7849830) · Gerrit Code Review this is the minimum viable change required to perform origin overriding using the remoteClientDataJSON extension.
I felt it was approriate to set the feature to experimental, as the runtime enabled feature doc guidelines mentions the following about experimental features: "Often a feature will be set to experimental status long before it's implementation is complete, and while there is still substantial churn on the API design.  Features in this state are not expected to work completely, just do something of value which developers may want to provide feedback on."