Summary

  • W3C formally opened refinement of a new WebAppSec charter on 7 August 2026, estimated the process through approximately 4 September and extended the current charter through 30 October.
  • The public draft lists 17 normative specifications. Sixteen say Expected completion: Undetermined; Fetch Metadata names incorporation into WHATWG Fetch but supplies no date.
  • An undetermined date is not proof of delay, abandonment or inadequate resources. W3C Process asks for expected milestone dates where available, not fabricated certainty.
  • Charter scope, publication maturity, repository activity, implementation evidence and patent-process dates are different records. None should be allowed to impersonate a delivery forecast.
  • A linked milestone ledger should give each deliverable a next competent decision, dependency, forecast class, owner, review date and variance history while permitting unknown as a valid state.

A two-year mandate without a row-level clock

W3C’s 7 August notice began formal refinement of a proposed Web Application Security Working Group charter. The public period was expected to run for about four weeks, through approximately 4 September. To keep the existing group authorized while the proposal moves, W3C extended the current charter to 30 October 2026.

Those are three distinct clocks. The refinement estimate governs discussion of the proposal. The extension preserves current authority. The proposed charter would run for two years after an eventual Call for Participation. None supplies a completion date for the specifications inside the draft.

The normative list has seventeen rows. Fetch Metadata Request Headers is expected to be incorporated into WHATWG Fetch, but no date is attached. The remaining sixteen—from Trusted Types and Content Security Policy Level 3 to Device Bound Session Credentials and Web Cryptography Level 2—each state Expected completion: Undetermined.

The count excludes three tentative deliverables and non-normative activity. It also says nothing about whether a track is healthy. Some documents are mature maintenance work; some depend on another standards venue; some are newer security mechanisms; some may advance when implementation, testing or horizontal review evidence changes. A common label does not create a common schedule.

This is why the headline number needs a boundary. Sixteen undetermined completion fields do not mean sixteen missed deadlines. The fields contain no deadlines to miss. They show that the authority instrument gives readers little row-level basis for monitoring change across a large portfolio.

The draft is not the charter in force

The Strategy issue opened in April and remains publicly marked as being in charter refinement. It records proposed additions including Web Cryptography Level 2 and Device Bound Session Credentials as normative work, a tentative single-sign-on application of DBSC and broader coordination with IETF and CFRG. Completed horizontal-review labels show that review activity occurred; they do not turn the proposal into an approved charter.

The issue body retains an older expectation that refinement would end on 1 August. The later formal notice supplies the current public estimate. The discrepancy is a versioned planning record, not evidence by itself of procedural failure.

Under the W3C Process, refinement is a consensus-seeking step around a proposal. Major changes later require Advisory Committee Review and a W3C Decision. The Call for Review must identify important changes and carry the disposition of refinement comments. A final decision and Call for Participation establish the new charter state.

The current charter extension is therefore a continuity measure. It lets the existing group keep working while the proposed authority is considered. It does not silently approve the new normative list, and a merged GitHub pull request does not do so either.

That boundary matters operationally. A security team can rely on an approved charter to understand what work a group is permitted to conduct. It cannot rely on a draft row as a promise that a browser feature will ship, interoperate or reach a later W3C maturity on a particular date.

Four records that answer different questions

A charter answers: what may this Working Group do, under what duration, with what decision process, dependencies, participation commitments and intellectual-property framework? W3C Process asks it to include expected milestone dates where available. The qualifier protects the record from false precision.

The WebAppSec publication page answers a different question: what is the public maturity of the group’s documents now? A repository answers how editors and contributors are changing a specification. Tests and implementer signals answer whether independent implementations may support a transition. Horizontal review answers whether specialist concerns have been raised and addressed.

Patent Policy states create another lineage. Adopted Draft and Exclusion Draft dates can trigger participant obligations and exclusion opportunities. Those dates matter, but they are not completion commitments. Reusing one as a delivery date would confuse legal-process metadata with an operational forecast.

The draft itself points readers toward the publication page for current status and toward the relevant repositories for milestones. That separation is sensible. Its weakness is that the reader must assemble seventeen separate histories to learn whether undetermined means an active dependency, maintenance without a planned transition, a forecast under review or simply no public forecast owner.

The result can mislead in both directions. Optimistic readers may treat inclusion in a two-year charter as a delivery promise. Skeptical readers may treat an undated field as evidence of failure. Neither inference is supported by the charter.

Preserve uncertainty in a milestone ledger

The smallest useful addition is not a compulsory date. It is a linked per-deliverable milestone ledger. Each row should name the stable specification and repository, current document maturity, last formal transition, applicable adopted- or exclusion-draft state, next competent decision and dependencies or external destination.

It should also record horizontal-review state, implementation and testing evidence, and one forecast class: dated, window, dependency-bound, maintenance-only or unknown. A forecast needs an accountable owner and a last-reviewed date. When the forecast changes, the old state and reason should remain visible.

Fetch Metadata shows why a dependency field matters. “Incorporate into WHATWG Fetch” describes a destination, not a date. A ledger could identify the upstream decision that must occur, the responsible venue, the last check and the next review without pretending that W3C controls another body’s calendar.

The same discipline can distinguish a specification maintained under existing authority from a new feature waiting for two intents to implement, testing evidence or horizontal review. It can also state that a Working Group expects Candidate Recommendation Snapshots without implying that every row is promised to become a W3C Recommendation.

At charter end, every row should have a disposition: completed transition, continuing maintenance, moved to another venue, recharter proposed, scope removed or still unknown. That closes the authority cycle without rewriting earlier uncertainty as if it had always been predictable.

Sources

  1. W3C formal notice of WebAppSec charter refinement
  2. Public 2026 WebAppSec charter draft
  3. WebAppSec rechartering Strategy issue
  4. Current WebAppSec charter
  5. W3C Process
  6. WebAppSec publications
  7. Public charter-draft pull request
  8. W3C Patent Policy
  9. Heng Lu, The Policy Mirror