remoteClientDataJSON WebAuthn extension

[bobomb]

WebKittens

@pascoej

Title of the proposal

remoteClientDataJSON WebAuthn extension

URL to the spec

https://w3c.github.io/webauthn/#sctn-remote-client-data-json-extension

URL to the spec's repository

https://github.com/w3c/webauthn

Issue Tracker URL

No response

Explainer URL

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebAuthnRemoteClientDataJSON/explainer.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#1432

WebKit Bugzilla URL

No response

Radar URL

No response

Description

remoteClientDataJSON is a new WebAuthn client extension (merged into the
WebAuthn editor's draft via w3c/webauthn#2375) that lets an authorized
remote-desktop web client supply a complete, verbatim clientDataJSON string to
the local WebAuthn client, instead of having the browser reconstruct it from
component fields. The provided bytes are used as-is when computing
clientDataHash = SHA-256(clientDataJSON) and are returned verbatim in
response.clientDataJSON.

It is a narrowly scoped, default-deny, per-origin-authorized capability for
remote desktop (RDP) forwarding. It supersedes the input-override behavior of the
existing remoteDesktopClientOverride extension.

The problem

Remote Desktop web clients forward WebAuthn ceremonies from a remote session to
an authenticator that is only reachable on the user's local machine:

[Relying Party e.g. accounts.example.com]
    |  WebAuthn (in the remote session)
    v
[RDP host / remote session]
    |  RDP WebAuthn virtual channel
    v
[RDP web client on the local machine e.g. myrdc.example]
    |  navigator.credentials.{create,get}
    v
[Local browser + local authenticator]

The interoperability break: platform WebAuthn APIs used by RDP hosts (e.g. the
Windows WebAuthn API) consume a complete clientDataJSON blob provided by the
caller, whereas the browser builds clientDataJSON itself from separate
fields. When the RDP host hands an already-serialized clientDataJSON to the web
client, the web client cannot reproduce it byte-for-byte through today's API. Any
difference — whitespace, key ordering, future fields, encoding choices — changes
the hash, so the relying party's signature verification over clientDataHash
fails.

The existing remoteDesktopClientOverride extension only lets the caller override
the origin (and sameOriginWithAncestor); the browser still assembles the final
JSON, so it does not solve byte-exact passthrough and turns clientDataJSON
assembly into an ongoing cross-spec synchronization problem.