Summary

  • WebAuthn Level 4’s remoteClientDataJSON draft is disabled by default and requires a per-origin grant, but an allowed local origin is not evidence that the remote client correctly validated the remote origin and RP ID.
  • A deployment should keep a hash-bound cross-client validation receipt while preserving the draft’s intended division of labour; the local user agent need not repeat the remote client’s full check.

The important line in the 15 September 2026 First Public Working Draft of Web Authentication Level 4 is not a new cryptographic primitive. It is a transfer of responsibility.

In the ordinary WebAuthn model, a browser derives the caller’s origin from its own execution context. The relying-party identifier, or RP ID, normally has to equal the origin’s effective domain or be a registrable-domain suffix of it, subject to the separate related-origins procedure. The browser constructs clientDataJSON; the authenticator signs a hash of those bytes; and the relying party checks the ceremony type, challenge, expected origin and RP ID hash.

A web-based remote desktop disrupts that neat locality. The website asking for authentication is running on the remote host, while the authenticator is attached to the user’s local device. If the local browser rebuilds the client data from its own context, it records the origin of the remote-desktop web client, not the origin of the relying party inside the remote session. Even harmless differences in JSON ordering, optional fields or whitespace can also change the hash and break verification.

The proposed remoteClientDataJSON extension solves that transport problem by accepting the complete client-data string from the remote side. The local browser parses it, uses it for registration or authentication, and must not add, remove or modify its contents. It sets the serialized client data to the supplied string so the authenticator signs the same bytes that the remote machine expects.

This is not an unguarded override. The draft makes publickey-credentials-remote-client-data-json both a powerful feature and a Permissions Policy-controlled feature. Its default permission state is denied; its stated default allowlist is 'none'. A user agent must expose only per-origin configuration and must not offer an “allow every origin” switch. The text points to managed browser or device policy, or an explicit origin-specific user choice in browser settings, rather than an opportunistic prompt during the ceremony.

Those are substantive safeguards. They answer a local question: may this calling origin invoke the extension here? They do not answer the remote question: did the remote client accurately identify the RP origin and correctly decide that the stated RP ID was allowed for it?

The algorithm makes that distinction explicit. Unless permission is granted, the local browser rejects the operation. It also requires an explicit RP ID and parses the supplied JSON. But it then skips the usual test between that RP ID and the origin inside the remote data. The draft says the local client is delegating all RP-ID-related origin checks to the remote client. Its security section is equally direct: the user agent must trust the caller to supply the remote origin accurately and must trust the remote client to perform the RP ID validation honestly and correctly.

The extension’s Boolean output is deliberately narrow. A value of true says that the extension was acted upon. It does not identify a remote session, name a validation policy, show which related-origin evidence was consulted, or carry the result of a remote validation algorithm. Byte fidelity is similarly narrow: it establishes that the local browser did not silently reconstruct the client data. It cannot establish that the origin claim already present in those bytes was truthful or authorised.

Cryptographic success must not be made to carry more meaning than it has. An authenticator signature binds the result to the supplied client-data hash and authenticator data. The relying party still has mandatory work: it checks the type and challenge, validates the client-data origin, and checks the RP ID hash it expects. Those controls are vital. Yet a successful RP decision may still leave an operational gap if the organisation later needs to reconstruct which remote client performed the delegated RP ID decision, which policy version governed it, and which remote channel was involved.

That gap is not proof of a vulnerability. The document is a First Public Working Draft, not a report of browser deployment, interoperability or incident. Publication starts public review; the W3C status section says it does not imply endorsement and that the draft may change. An open W3C WebAuthn repository issue also tracks a terminology dependency: the intended disabled-by-default behaviour is clear, while 'none' was not yet defined as a normative default-allowlist term in the dependent Permissions Policy draft. The issue requests no behaviour change.

The right governance response is therefore not to undo the delegation. The remote side has context the local browser may not possess, including related-origin material and platform-specific app-association rules. Requiring the local user agent to independently reproduce every remote check would rebuild the very mismatch the extension is designed to avoid.

Instead, deployments should create a cross-client origin-validation receipt at the handoff. It should bind the local calling origin and permission grant to the remote session and authenticated channel; record the remote origin, RP ID, validation algorithm and policy version; reference any related-origin or app-association evidence; and include a hash of the exact remoteClientDataJSON. The RP server’s validation result should close the chain. Exceptions, expiry, revocation and later corrections should remain visible rather than overwriting the original decision.

The receipt is a deployment control, not a proposed addition to the WebAuthn conformance algorithm. Its purpose is to keep distinct facts distinct: local capability was authorised; remote validation was performed; bytes were preserved; a user interacted with an authenticator; and the RP accepted or rejected the result. A single green “WebAuthn succeeded” event cannot safely stand in for all five.

Sources