I've created a design doc for this feature to give context: WebAuthn remoteClientDataJSON Extension — Chromium Design Doc - Google Docs <https://docs.google.com/document/d/18qcAo02oQNerkYMbRAos6FG3srUu4_1yvLILeAqCMUs/edit?tab=t.0#heading=h.7nki9mck5t64> 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 <https://chromium-review.googlesource.com/c/chromium/src/+/7848162/2> 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 <https://chromium-review.googlesource.com/c/chromium/src/+/7849830/2> 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." On Friday, May 15, 2026 at 11:56:26 AM UTC-4 Ari Chivukula wrote: > 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 > [email protected] on the early side (before pursuing experiment > or launch). > > ~ Ari Chivukula (Their/There/They're) > > On Fri, Apr 24, 2026, 13:06 Chromestatus <[email protected]> > wrote: > >> *Contact emails* >> [email protected], [email protected], [email protected] >> >> *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 >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebAuthentication%22> >> >> *Web Feature ID* >> webauthn <https://webstatus.dev/features/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 >> <https://chromestatus.com>. >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69eba302.710a0220.18de8c.0119.GAE%40google.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69eba302.710a0220.18de8c.0119.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f359d804-09ea-4713-95d6-c954868a1399n%40chromium.org.
