W3C opened public review of Web Authentication Level 4 on September 15, less than a month after Level 3 became a Recommendation. The two milestones concern different stages of the standards process. Reading only the level number would miss the distinction between an endorsed specification and a developing successor.
The Level 4 announcement describes an interface through which web applications use public-key credentials to authenticate users. It also invites feedback on the new draft. The August 25 announcement for Level 3 identifies that version as a W3C Recommendation and points to Level 4 as the place for subsequent feature development.
For anyone documenting an authentication project, those dates answer a narrow but useful question: which document had reached which status? They do not, by themselves, answer whether a particular application supports a feature or whether its sign-in flow works on a customer's device.
What each status establishes
The September 15 Level 4 specification explicitly begins public review. Its status section says that publication at this stage does not represent W3C or member endorsement. The text remains subject to change or replacement. References to this version therefore need to retain its draft status rather than silently describe it as an adopted standard.
The August 25 Level 3 specification records endorsement following the W3C consensus process and recommends deployment as a Web standard. It also states that its substance is unchanged from the Candidate Recommendation Snapshot dated May 26. That gives the August event a more precise meaning: a status milestone need not also be the date when technical provisions first appeared.
These distinctions matter when describing change. A higher level identifies a successor document. A later publication date identifies a newer publication. Neither fact, standing alone, establishes that a given technical requirement changed between two versions.
Keep the document and the implementation identifiable
Consider a hypothetical team preparing a sign-in release. Its design notes could cite the dated Level 3 Recommendation as a reference while tracking a Level 4 proposal separately. The test record could then identify the application build, browser and authenticator used for a specific sign-in attempt. These are proposed documentation practices, not observations about a real company or extra requirements attributed to W3C.
Such a record would let another engineer ask two different questions. Does the design cite the intended specification? Does the tested implementation behave as expected in the recorded environment? Answering the first would not settle the second. Equally, one successful demonstration would not establish support across every environment the product claims to serve.
A report on new WebAuthn capabilities needs a closer comparison of the relevant provisions and evidence from implementations. The publication notices and document-status sections support a chronology and a maturity distinction; they are not a browser-support survey.
For a release note written now, the useful detail is consequently specific: name the level, include the document date and describe its status accurately. Any claim about shipped support or observed behaviour then needs its own evidence. That keeps the September drafting milestone visible without turning it into an unverified product-launch claim.