Summary

  • W3C's proposed Web Authentication charter would place WebAuthn-mediated signing of arbitrary data in scope, using signing keys associated with but distinct from authentication credential keys.
  • The proposal names agentic AI and verifiable digital credentials as examples, while continuing to exclude low-level private-key access and standalone general-purpose cryptographic APIs beyond the listed mediated features.
  • Scope is not maturity. At the reporting cutoff the charter review is open, Level 4 has no First Public Working Draft, the sign pull request is a draft, and the explainer reports no user research or browser-implementor signals.
  • A public feature-admission receipt should connect the charter authority to the exact proposal, consent and key-separation claims, message semantics, reviews, tests, independent implementations, Recommendation status and actual adoption.

A charter can open a door without choosing what comes through it

The current Web Authentication Working Group charter is built around a recognisable purpose: strong authentication for web applications. Its scope covers origin-bound key pairs, proof that a browser can use a private key, recovery, backup and related enhancements. It excludes low-level access to cryptographic operations or key material.

The replacement under review changes that boundary. Item 11 would permit signing data beyond the standard WebAuthn authentication structure. It describes raw signing mediated by WebAuthn, with signing keys related to—but distinct from—the credential keys used for authentication. It cites agentic AI and verifiable digital credential ecosystems as examples. Two more new items concern trust signals about credential managers and confidentiality for extensions.

This is a consequential choice of venue. A web API able to produce signatures compatible with other cryptographic protocols is not merely another way to log in. It could support wallets, authorization tokens, software-release signing and other applications that need a hardware-bound key without giving JavaScript the private material.

But the institutional act now underway is narrower. W3C invited review of a proposed charter on 10 August. Comments remain open until 23:59 UTC on 7 September, and the existing charter has been extended to 30 October. At this cutoff there is no approved replacement charter. Even approval would answer only whether the Working Group may develop this class of feature. It would not select the present API, settle its risks or require a browser to implement it.

That distinction matters because the charter itself preserves it. Web Authentication Level 4 is the proposed normative deliverable. The page says no First Public Working Draft has been published and gives Q4 2028 as an expected completion date. The road from mandate to deployed code is still long by design.

“Arbitrary” describes the capability, not the user's intention

Ordinary WebAuthn assertions do not sign a relying party's challenge as naked input. The authenticator signs a defined construction containing authenticator data and a hash of client data. The raw-signing proposal is deliberately different: its output is a signature over the input supplied by the application, unaltered.

That generality creates its value. Existing verifiers do not all understand a WebAuthn assertion envelope. A conventional signature over a specified message can fit protocols that already verify signatures. A hardware-backed key may stay outside JavaScript while a web application participates in those protocols.

The proposal also tries to carry WebAuthn's strongest boundaries across the gap. The signing key must be distinct and cryptographically unrelated to the parent credential key, so a malicious relying party cannot ask the new feature to manufacture a valid authentication assertion. Origin binding is meant to stop the signing key becoming a cross-site tracking handle. User-presence and user-verification requirements are fixed when the signing key is created. The web-facing layer is not supposed to expose unattended signing, even though the lower client-to-authenticator layer may serve native applications that use it.

Those are meaningful design commitments. They are not the same as proving what a person approved.

The explainer makes transaction confirmation a non-goal. It assumes the material may be opaque binary data and does not require a trusted interface to show it intelligibly before signature. A successful ceremony can therefore prove that a particular key operated under a specified presence or verification policy. It does not, by itself, prove that the user read a document, approved an agent's proposed action, understood a payment, or assented to the legal meaning later attached to the signature.

This is not a defect smuggled out of the record; it is a declared boundary. Governance fails when a later product claim erases it. “User verified” is a ceremony property. “User understood this payload” is a different proposition. “An autonomous agent was authorized to choose this payload” is different again.

The proposal still has evidence to earn

The public explainer says no user research has been performed. Its stakeholder table records no signals from Chrome, Firefox, Safari or Edge. One authenticator implementor and one relying-party implementor are listed positively. No signal is not rejection; it is an unresolved state.

The linked sign extension remains a draft pull request assigned to the Level 4 First Published Working Draft milestone. Its history is active. In September 2024, the author reported rough internal proof-of-concept components and no commitments from other Working Group participants at that time. Subsequent discussion and referenced experiments show that more work exists. They do not turn the checked record into an open implementation report demonstrating two independent interoperable implementations.

W3C's process supplies the missing sequence. A major scope change needs Advisory Committee review and a W3C Decision. A First Public Working Draft begins public standards-track work and has patent consequences. Horizontal review must examine accessibility, internationalization, privacy and security. Candidate Recommendation is the stage for final review and implementation experience. Recommendation requires further evidence and a W3C Decision. Deployment then depends on implementors and relying parties.

None of those states is ceremonial surplus. Each answers a different question:

State Question answered
Charter scope May this group do the work?
Draft proposal Is there a concrete design to inspect?
FPWD Has standards-track publication begun?
Horizontal review Have cross-cutting risks been examined?
Open tests Can claims be checked consistently?
Independent implementations Does the feature interoperate beyond one stack?
Recommendation Has the W3C process endorsed this specification?
Deployment Did implementors and users adopt it in running systems?

Heng Lu's running-code argument is useful at this precise boundary. A publication can organize future work; it does not make a later change operationally real. The application here is limited. W3C is not an RIR and a web standard is not a number-resource registry. The transferable discipline is simply that document status, implementation evidence and adoption must not impersonate one another.

One feature needs one admission receipt

The proposed charter already contains general success criteria. Raw signing deserves a feature-level record because its promise depends on a chain of claims that can drift apart.

The receipt should identify the charter clause and its status; the exact explainer and specification revision; whether the operation signs full input, a pre-hash or another envelope; the algorithm and domain-separation convention; the relationship between parent and signing keys; the origin boundary; the fixed user-presence and user-verification policy; what is and is not displayed to the user; what attestation proves; linkability and fingerprinting analysis; browser, authenticator and relying-party signals; horizontal-review issues and dispositions; open-test coverage; independent implementation evidence; unresolved objections; and the

current W3C maturity state.

It should not contain private keys, device identifiers, personal test data or exploitable implementation detail. Nor should it become an extra committee empowered to veto work already governed by the W3C Process. It is a joined public index into records that already ought to exist.

The value is correction. If the charter changes, the first row changes. If transaction confirmation becomes a goal, the user-control row changes. If a browser says “negative,” the implementor state changes without rewriting “no signal” as historical opposition. If tests expose protocol confusion, the result and disposition remain attached. If the feature is dropped, it ends in a legible terminal state rather than lingering as a charter sentence cited out of time.

Sources

  1. W3C call for review of the proposed Web Authentication charter
  2. Proposed Web Authentication Working Group charter
  3. Current Web Authentication Working Group charter
  4. Web Authentication Level 3 Recommendation
  5. Raw-signing extension explainer
  6. Draft sign extension pull request #2078
  7. W3C Process Document, 18 August 2025
  8. Heng Lu, Running-Code Primacy
  9. Heng Lu, Minimum Initial Specification, Localized Future Decision and Voluntary Adoption