WebAuthn Level 4 published as a Working Draft

On 15 September 2026 the Web Authentication Working Group published a First Public Working Draft of Web Authentication Level 4, announced the same day in the W3C news feed. The draft’s own status section states that this First Public Working Draft, published on 15 September 2026, begins public review of Web Authentication Level 4, and that it builds on Web Authentication Level 3, published as a W3C Recommendation on 25 August 2026. The status section also states that the changes since Level 3 are documented in a “Changes since Web Authentication Level 3” section of the draft itself (W3C news, 15 September 2026).

What the draft publishes

The standing of the document, the substantive changes it records against Level 3, and the extension those changes introduce are taken in turn below, each in the specification’s own terms.

The standing of the document

The draft is published on the Recommendation track, and its status section states that publication as a First Public Working Draft does not imply endorsement by W3C and its Members. It further states that this is a draft document and may be updated, replaced, or obsoleted by other documents at any time, and that it is inappropriate to cite the document as other than a work in progress. The same section states that the document was produced by a group operating under the W3C Patent Policy, and that it is governed by the 18 August 2025 W3C Process Document (Web Authentication Level 4, First Public Working Draft).

The draft records its place in the series. It gives the dated version URL as https://www.w3.org/TR/2026/WD-webauthn-4-20260915/, lists the previous versions as the Level 3 Recommendation of 25 August 2026, the Level 2 Recommendation of 8 April 2021, and the Level 1 Recommendation of 4 March 2019, and points at an editor’s draft and an implementation report. Its editors are listed as Tim Cappalli of Okta, Akshay Kumar of Microsoft, Emil Lundberg of Yubico, Matthew Miller of Cisco, Pascoe of Apple, Nina Satragno of Google, and David Waite of Ping Identity (Web Authentication Level 4, First Public Working Draft).

The W3C news item quotes the specification’s abstract. It states that the specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications for the purpose of strongly authenticating users; that one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application; that the user agent mediates access to authenticators and their public key credentials in order to preserve user privacy; that authenticators are responsible for ensuring that no operation is performed without user consent; and that authenticators provide cryptographic proof of their properties to Relying Parties via attestation (W3C news, 15 September 2026).

The substantive changes against Level 3

The draft records its changes against Level 3 in a changes appendix. Under substantive changes it records a requirement that authenticator extension outputs for the prf extension not contain cleartext PRF outputs, and an extension of the Virtual Authenticator “Add Credential” and “Set Credential Properties” commands with explicit signCount handling, including the ability to create, update, or remove a signature counter (Web Authentication Level 4, First Public Working Draft).

Under new features in the same appendix it records the addition of the remoteClientDataJSON registration and authentication extension for remote-desktop WebAuthn operations, described there as including a default-denied powerful feature, a policy-controlled feature whose default allowlist is 'none', and security considerations for clients. The editorial changes listed alongside are the addition of explicit anchors to the client-data construction and serialization steps used by that extension in the credential creation and authentication algorithms, and the definition of a JSON “Set User Verified Parameters” object for the Set User Verified Virtual Authenticator command (Web Authentication Level 4, First Public Working Draft).

What the remoteClientDataJSON extension does

The draft’s section for the extension describes a remote desktop web client as letting users interact with the native desktop environment of a remote host from a local client web application. It states that the registration and authentication extension allows a user to use a WebAuthn authenticator connected to the local client platform in order to sign into a website in a browser, or an app running on a remote host, in a remote desktop web client, and that this allows web-based remote desktop web clients to execute remote WebAuthn requests locally. It gives the extension identifier as remoteClientDataJSON, its operation applicability as registration and authentication, and its client extension input as a DOMString member added to AuthenticationExtensionsClientInputs (Web Authentication Level 4, First Public Working Draft).

The draft states the extension’s permission model in the same section. It states that the extension is a powerful feature that requires explicit per-origin permission before use, and that user agents SHOULD NOT prompt the user for this permission at request time; instead the grant is administered through device management policy, for which it gives managed browser profiles, managed browser instances, and managed devices that enumerate specific remote desktop web client origins as examples, or through explicit per-origin user opt-in in WebAuthn client settings. It states that this permission MUST be configured per-origin and MUST NOT offer the capability to permit all origins (Web Authentication Level 4, First Public Working Draft).

The draft names the features and gives their defaults. It states that the extension defines a powerful feature and a policy-controlled feature, both identified by the name "publickey-credentials-remote-client-data-json", that the default allowlist for the policy-controlled feature is 'none', and that the default permission state is "denied", meaning the extension is not available by default and must be explicitly enabled. It notes that since no additional aspects are defined, the permission descriptor type defaults to PermissionDescriptor, and shows a remote desktop web client checking the grant with navigator.permissions.query({ name: "publickey-credentials-remote-client-data-json" }) and testing for a state of "granted" (Web Authentication Level 4, First Public Working Draft).

The draft’s security considerations address the extension’s effect on the trust model. They state that the extension enables a remote desktop web client to proxy Web Authentication API requests on behalf of a remote Relying Party, and that this fundamentally alters the trust model of the Web Authentication API in the ways it then names: origin substitution, where the user agent accepts an origin supplied by the calling remote desktop web client rather than deriving it from the current execution context, so that any user agent granting the permission must trust that the caller accurately and honestly supplies the origin of the remote Relying Party; RP ID validation, which is delegated to the remote client because that client has the context needed to account for related origins and platform-specific app deployment models; and a required per-origin configuration mechanism, with user agents obliged to provide configuration only on a per-origin basis via user agent policy. The same section states that user agents granting the extension SHOULD clearly communicate to users when a remote-desktop-proxied WebAuthn operation is in progress, so that users understand that their authenticator is being used on behalf of a remotely hosted application (Web Authentication Level 4, First Public Working Draft).

Why it matters for PWA developers

MDN documents the availability of the API this draft extends. MDN records the Web Authentication API as Baseline widely available, states that the feature is well established and works across many devices and browser versions, and dates its availability across browsers to September 2021, with a footnote that some parts of the feature may have varying levels of support. MDN also states that the API is available only in secure contexts, in some or all supporting browsers (MDN, Web Authentication API).

MDN also documents what that API is for. MDN describes WebAuthn as an extension of the Credential Management API that enables strong authentication with public key cryptography, enabling passwordless authentication and secure multi-factor authentication without SMS texts, and states that on the web, passkeys are implemented using the Web Authentication API. It names protection against phishing as a benefit, on the grounds that an attacker who creates a fake login website cannot log in as the user because the signature changes with the origin of the website (MDN, Web Authentication API).

The draft states what the extension does to the origin a WebAuthn operation runs against. It states that under remoteClientDataJSON the user agent accepts an origin supplied by the calling remote desktop web client rather than deriving it from the current execution context, and that RP ID validation is delegated to that remote client. It states that the extension’s default permission state is "denied", that the permission MUST be configured per-origin, and that user agents SHOULD NOT prompt the user for it at request time (Web Authentication Level 4, First Public Working Draft).

The draft also sets out what the specification offers a Relying Party. It states that users and accounts can be secured using widely compatible, easy-to-use multi-factor authentication; that the Relying Party does not need to provision authenticator hardware to its users, because each user can independently obtain any conforming authenticator and use it with any number of Relying Parties; that the Relying Party can optionally enforce requirements on an authenticator’s security properties by inspecting the attestation statements returned; that authentication ceremonies are resistant to man-in-the-middle attacks; and that the Relying Party can automatically support multiple types of user verification, naming PIN and biometrics, with little or no code change (Web Authentication Level 4, First Public Working Draft).

The draft states the standing of both documents in the series. Level 3 is the Recommendation the draft says it builds on, dated 25 August 2026, and Level 4 is a First Public Working Draft which the same status section states may be updated, replaced, or obsoleted by other documents at any time, and which it is inappropriate to cite as other than a work in progress (Web Authentication Level 4, First Public Working Draft).

Related entries on this site

• Web app manifest: for readers adding Web Authentication sign-in to an installed PWA, this page is where OpenPWA documents the web app manifest.
• Service workers: for the same readers, this page is where OpenPWA documents service workers.
• By feature: MDN notes that parts of the Web Authentication API have varying levels of support, and this page is where OpenPWA tracks support per capability.

Open and unverified

• When, or whether, Level 4 advances beyond First Public Working Draft is not confirmed.
• Whether any browser ships the remoteClientDataJSON extension, and on what terms, is not confirmed.
• Whether the changes recorded against Level 3 affect an existing registration or authentication flow that does not use the prf extension or the Virtual Authenticator commands is not confirmed.
• How a user agent is expected to clearly communicate that a remote-desktop-proxied operation is in progress is not confirmed.
• Which parts of the Web Authentication API have the varying levels of support MDN footnotes on its Baseline status is not confirmed.
• Whether the origin substitution the draft describes bears on the phishing resistance MDN attributes to the Web Authentication API is not confirmed.
• Whether the draft’s default-denied, per-origin permission model is intended as a response to that origin substitution is not confirmed.

Sources

• First Public Working Draft: Web Authentication: An API for accessing Public Key Credentials Level 4 (w3.org)
• Web Authentication: An API for accessing Public Key Credentials Level 4, W3C First Public Working Draft 15 September 2026 (w3.org)
• Web Authentication: An API for accessing Public Key Credentials Level 3 (w3.org)
• Web Authentication API (developer.mozilla.org)