WebAuthn Level 3 is a Recommendation, which means the passkey surface stops moving
The W3C published Level 3 on August 25. The text carries no substantive change since the Candidate Recommendation of May 26, and everything new is pushed to Level 4 — which is the point of the milestone rather than a footnote to it.
Source
Web Authentication: An API for accessing Public Key Credentials Level 3 is now a W3C RecommendationW3C News · Original published August 25, 2026
A Recommendation is not a new feature. It is a promise that the text you build against will not shift under you, and for an API that guards sign-in that promise is the whole value. The Web Authentication Working Group published Level 3 of the credential API on August 25, and stated plainly that new work moves to Level 4.
What is inside the frozen text
Level 3 defines the API for creating and using public key credentials, which is the machinery behind passkeys. Alongside the registration and authentication ceremonies it carries a method for asking the client what it can do, getClientCapabilities, and two helpers that turn server-sent JSON into the option objects the ceremonies expect, parseCreationOptionsFromJSON and parseRequestOptionsFromJSON.
It also defines the signal methods, signalUnknownCredential, signalAllAcceptedCredentials and signalCurrentUserDetails, which let a site tell the credential store that something on the server side has changed, and the rules for validating related origins.
What the milestone does not tell you
A Recommendation says the specification is stable. It says nothing about which browsers implement which part of it, and that is the question a site actually has to answer before it removes a password field. The status line and the support line are two different things, and the second one has to be checked against the browsers, not against the standard.
The Working Group's own note frames the release the same way: Level 3 succeeds Level 2, and the next batch of features has already been moved out of it.
Sources
Related
Safari 27.0 ships an MCP server, so a coding agent can drive the browser itself
WebKit published the feature list on September 17, 2026, and it is the longest the team has written: 83 features, up from 58 at the first beta in June, and 844 quality fixes against the 525 announced at WWDC. The headline for anyone who builds with a coding agent is the Safari MCP server, which hands the agent the DOM, network requests, screenshots and console output from a real Safari window. Customizable Select turns the real select element into something you can fully restyle, and scroll anchoring stops the page from jumping when content loads in above what you are reading.
WebKit Blogverified
Safari Technology Preview 252 adds named-feature() and lets SVG reach a filter in another file
The preview build came out on September 11, 2026 and covers WebKit changes between 319252@main and 320112@main. Eleven features are new, and two of them extend the same job: how a stylesheet, and then a script, finds out what the engine underneath can do. The named-feature() function asks about a behavior that has no syntax of its own, and the registry behind it holds exactly two entries today. SVG also gained external resources, so the url() reference can finally point at a filter, mask or gradient stored in another document.
WebKitverified
Interop 2027 proposals close on September 23, and untested ideas do not qualify
The call for Interop 2027 Focus Area proposals opened on September 3, 2026 and closes on September 23, 2026. Proposals are filed as issues on the web-platform-tests/interop repository, and two conditions decide almost everything: the technology must already have a mature standard, and it must be testable, because the test results are what the dashboard scores. Anything that fails the second condition is steered toward an Interop Investigation instead. Twenty days is the whole window, and the evidence a good proposal needs takes longer than an evening to assemble.
WebKitverified