Summary

  • W3C published Web Authentication Level 3 as a Recommendation on 25 August 2026 and linked a fixed 26 June implementation-report snapshot.
  • The report declares 53 tests and 415 subtests across named Chrome, Firefox, Safari preview and Edge builds. It records products, environments, dates and one WPT revision, but not implementation lineage by feature.
  • The final transition request says part of Chrome's implementation differs from Edge's. The useful next step is not to discount either browser, but to identify which feature, component path and evidence make a result independent for the decision at hand.

Four columns answer one question well

On 25 August, W3C published Web Authentication: An API for accessing Public Key Credentials — Level 3 as a Recommendation. The document defines an API for creating and using scoped public-key credentials through user agents and authenticators. Its status section says W3C recommends wide deployment, and that no substantive changes were made after the Candidate Recommendation Snapshot of 26 May.

The Recommendation does something valuable for evidence custody: it links a fixed implementation report rather than leaving readers only with a live dashboard. That page says it is a snapshot as of 26 June and warns that it is not maintained. It names 53 tests and 415 subtests in the WebAuthn portion of web-platform-tests.

It also records unusually specific execution context. Chrome 151 and Firefox 154 alpha ran on Linux on 25 June; Safari 246 preview ran on macOS and Edge 151 on Windows on 26 June. All four entries point to WPT commit d41367df1e. Below that header, the matrix gives each product its own PASS, FAIL, TIMEOUT, ERROR, NOTRUN or missing outcome.

Those columns answer a concrete question: what did this named product build report in this environment against this test revision? They do not, by themselves, answer a different Process question: which results demonstrate independent interoperable implementations of a specification feature?

That distinction is not an accusation about browser architecture. A product can combine a browser engine, operating-system facilities, authenticator paths and vendor-specific components. Two products can share some implementation and differ elsewhere. Independence can therefore change with the feature and the layer being tested. Counting mastheads is too coarse; declaring two products the same everywhere is equally coarse.

The transition record knows the distinction exists

The final Recommendation transition request links both the live WPT results and the fixed snapshot. Immediately underneath, it says: “Please note that part of the implementation in Chrome is different from that in Edge.”

The sentence matters because it refuses a simplistic inference in the opposite direction. Chrome and Edge should not automatically be collapsed into one result. Some relevant implementation is different. But the note does not say which part, which feature, which test group or which component boundary it describes. Nor does it identify the evidence for that classification or state whether a particular Chrome-Edge pair was relied on as the independent pair for a transition proposition.

The Working Group's 18 March minutes show that this was not an invisible concern. Under “Testing,” one participant recorded technical differences in Edge from “normal Chrome.” The discussion then asked whether Microsoft Authenticator operated through Android or iOS and described those as two implementations at the WebAuthn layer for an extension. The minutes later record consensus to propose Recommendation after pending issues were resolved, with no objections.

This is evidence of active reasoning, not neglect. Yet the reasoning loses resolution as it moves from meeting discussion to the public transition receipt. A technical difference becomes “part” of an implementation. A layer-specific question becomes a one-line product caveat. The fixed result matrix and the caveat sit beside one another without a join key.

The transition itself was completed openly. The issue records Team approval on 17 July, the close of Advisory Committee review on 18 August with consensus and no Formal Objections, approval for publication on 19 August and the Recommendation URL on 25 August. None of that should be rewritten as provisional. The question is whether a future reviewer can reproduce the implementation-independence proposition that informed the completed decision.

Independence is not a browser count

W3C Process deliberately avoids a mechanical formula. Implementation experience is meant to show that a specification is clear, complete and relevant enough for independent interoperable implementations of each feature to be realised. The Team may consider whether each feature is implemented, whether implementations are independent and interoperable, whether people other than the specification authors built them, whether they are publicly deployed, whether evidence spans the ecosystem and whether difficulties have been reported.

Those are related questions, not interchangeable columns. A passing test result can demonstrate observed behaviour. It cannot, without more provenance, establish authorship independence or implementation lineage. A different operating system can be material to one feature and irrelevant to another. A shared test-suite commit improves comparability but says nothing about whether the code under test is independent.

The matrix also contains mixed outcomes. That is normal evidence, not a league table. A FAIL may reflect an unsupported feature, an implementation difference or a test expectation needing investigation; a TIMEOUT or missing result says still less. Recommendation transition does not require every cell in every product to be green, and this Article does not invent such a requirement.

What the public record needs is narrower: preserve the reasons why selected observations satisfy the independence proposition for the feature and decision in question.

Add a per-feature independence key

A useful key could sit beside the test report without exposing proprietary code. For each feature or test group used as implementation evidence, it would name the fixed specification and test revisions, the product and build, the relevant implementation layer, and the bounded independence claim. It would link a public architecture source where one exists or record an accountable attestation where detail cannot be public.

The row should then state the interoperability observation and whether the result was relied on for transition. If Chrome and Edge exercise different code for one extension, the record should say so for that extension. If they share the relevant path for another feature, the record should not let two product columns silently become two independent implementations. Firefox, Safari, Android, iOS, authenticators and relying-party software should be treated with the same feature-level discipline rather than as permanent yes-or-no identity labels.

This is not a new approval gate. The W3C Team keeps the contextual judgment that the Process assigns it. The key simply separates three propositions already present in the evidence: where a test ran, what behaviour was observed, and why the implementation counts as independent for a stated purpose.

Lu Heng's Minimum Initial Specification note supplies the broader restraint. A recommendation is a coordination artifact; implementation, validation, deployment and adoption remain distinct facts. The same restraint should apply one level earlier. A browser label is evidence of a tested product, not a self-proving account of the implementation beneath it.

Sources