chore(spec-watch): upcoming WebAuthn changes to anticipate #926

Purpose

Tracking issue for the WebAuthn work accepted or in progress upstream that is not yet actionable, so that it is not rediscovered later. Nothing here requires code today. Each item should get its own issue once the corresponding text becomes normative.

Last upstream review: 2026-08-30. No normative change has been merged in w3c/webauthn since 2026-07-30 (w3c/webauthn#2382), so there is no compliance gap to close. Everything below is either an open pull request or a discussion.

Framework status as of 2026-08-30: every issue opened from this review has been merged. The remaining content of this issue is pure watch material, plus a single open follow-up (#854).

Level 3 is moving to Recommendation

w3c/webauthn#2399 was closed on 2026-08-26: the Level 3 transition request is through, and the Working Group has stated that no new feature will be incorporated into the Recommendation. Level 4 is the next version. Every item in this issue therefore lands in Level 4, which means it should be planned against 6.0.0 and later rather than treated as a Level 3 erratum.

Explainers moved into the repository and actively worked on

The W3C wiki explainers were migrated into the repository in April 2026 (w3c/webauthn#2398), which makes the following visible as pull requests.

• Algorithm policy and PQC migration: now backed by a normative pull request, Support Algorithm Migration w3c/webauthn#2437 (updated 2026-08-26, closes [PQ] Post Quantum Crypto and WebAuthn Transition for RP w3c/webauthn#2417), which carries the algPolicy extension and acceptedAlgs in the assertion options. The explainers (algPolicy Extension and acceptedAlgs Explainer Update w3c/webauthn#2438, #2440, #2455) and the post-quantum migration explainers (#2433, #2449) remain the background material. This is still the most structuring item to come: it changes how a Relying Party negotiates and rotates signature algorithms, which touches options building, credential storage and the verification manager.
• Immediate mode and Ambient credentials (explainers Update the Immediate Mode explainer w3c/webauthn#2407, #2435, normative pull request Add Immediate uiMode w3c/webauthn#2291 "Add Immediate uiMode"): affects the client-side flow and therefore the Stimulus controller and the options exposed by the bundle. The uiMode: "immediate" option itself is already implemented (feat(options): support uiMode: "immediate" on navigator.credentials.get() (Credential Management ED) #856); what is left is whatever the normative text adds on top of it.
• Credential Manager Trust Group (CMTG) Key extension (Add "Credential Manager Trust Group (CMTG) Key" extension w3c/webauthn#2377, still open): closest thing to a successor of attestation for synced credentials. To watch closely. cmtgKey extension should allow returning more than one key to facilitate rotating keys to a new algorithm w3c/webauthn#2472 (2026-08-28) proposes that an assertion be allowed to return more than one CMTG key, so that a passkey can be rotated to a new algorithm while the trust of the old key transfers to the new one. Consequence for us: the extension output must be modelled as a collection from day one, not as a single key. Virtual authenticator support is tracked in Add virtual authenticator support for CMTG keys w3c/webauthn#2445.
• Cross Device Fallback URL extension (Add Cross Device Fallback URL extension for hybrid transport authentication w3c/webauthn#2380, updated 2026-08-27, closes Add hybrid fallback URL extension w3c/webauthn#2341): a fallback URL for hybrid transport, with a Chromium implementation commitment recorded. A new client extension input for the options builders.

Post-quantum work to watch

• [PQ] Default Algorithems for Authenticators perhaps need updating. w3c/webauthn#2448 (updated 2026-08-26, absorbing the closed pkOptions.pubKeyCredParams default will be unsafe after Q-day w3c/webauthn#2462): the default pubKeyCredParams of ES256 and RS256 is being reconsidered, with P-384 and possibly ML-DSA-44 proposed, and a discussion on whether the default should exist at all. Since feat(cose): accept the RFC 9864 fully-specified algorithm identifiers #923 the default verification manager is ES256 plus ESP256 plus RS256, declared identically in CeremonyStepManagerFactory and in CheckSignature; it should follow whatever the Working Group settles on.
• [PQ] SHA-256 usage w3c/webauthn#2471 (2026-08-26): CollectedClientData and the RP ID hash are fixed to SHA-256, with no agility, which CNSA 2.0 does not approve for general use. The proposals range from a formal exception to a signed extension carrying stronger hashes. Would touch CheckRelyingPartyIdIdHash and every client data hash computation.
• [PQ] Add new batch attestation type for Merkle tree certificates w3c/webauthn#2456 (updated 2026-08-29): a batch attestation type based on Merkle tree certificates, which brings the batch certificate back to roughly 736 bytes. Would need a new AttestationStatementSupport, and raises open questions on the relationship with the FIDO MDS as the trust root.
• [PQ] Post Quantum Crypto and WebAuthn Transition for RP w3c/webauthn#2417: the Relying Party transition issues, notably the inability to hold two credentials using different algorithms for the same RP ID and user handle. Partially eased by feat(credential-record): add the optional rpId member (W3C PR #2258) #922, which added the optional rpId member on the credential record, but the multiple-algorithm case is still open upstream.

Accepted but requiring no change here

• Add .well-known/webauthn registration w3c/webauthn#2376: .well-known/webauthn is now a formally registered well-known URI. Already served by AllowedOriginsController.
• Delete inaccurate recommendation to abort on unfocus w3c/webauthn#2367: the recommendation to abort a ceremony on loss of focus was removed. The Stimulus controller never implemented it.
• Additional privacy recommendations for getClientCapabilities w3c/webauthn#2357 and #2391: privacy considerations for getClientCapabilities() and cross-origin usage. Documentation only.
• Address cross-origin create() in §5.10 w3c/webauthn#2231: cross-origin create() clarifications, already covered by the top origin validators.
• Update Virtual Authenticator API to better emulate synced passkey behavior w3c/webauthn#2382: the Virtual Authenticator API now emulates synced passkey behaviour, which may be useful for browser-driven functional tests.
• Consider deprecating COSE algorithm identifier -7 in favour of -9. w3c/webauthn#2469, closed on 2026-08-19: the Working Group declined to migrate the API to the RFC 9864 identifiers, because a -7 carried inside signed authenticator data cannot be converted to -9. This is the scope that was implemented in feat(cose): accept the RFC 9864 fully-specified algorithm identifiers #923: accept the new identifiers when an authenticator returns them, keep the legacy ones in pubKeyCredParams.
• Hints should not take precendence over transports in an authentication ceremony w3c/webauthn#2465: whether hints should take precedence over credential transports during an authentication ceremony. Client-side user experience only.
• Multiple independent applications on one host w3c/webauthn#2457 and #2458: feature proposals on multiple independent applications sharing a host, and on deprioritizing a credential provider that already holds an excluded credential. No Relying Party change.
• the Virtual Authenticator clarifications (Virtual Authenticator's add credential should probably support more algorithms than ECDSA w3c/webauthn#2446, #2447, #2450, #2452, #2453, #2459, #2464, #2468) only become relevant if browser-driven functional tests are added.

Already tracked separately

• remoteClientDataJSON extension (remoteClientDataJSON Extension w3c/webauthn#2375): see feat(extensions): support remoteClientDataJSON for remote desktop web clients (WebAuthn ED) #854, still open, milestone 6.0.0. This is the only actionable item left from the whole review.
• in-field language and direction metadata deprecation (Deprecate in-field language/direction metadata w3c/webauthn#2308): was tracked in PublicKeyCredentialEntity.name deprecation error #902, closed and released in 5.3.7.

Issues opened from this review

All closed. Nothing is left to do on this list.

Opened on 2026-08-20:

• fix(authenticator-data): FLAG_RFU2 still masks the BE and BS bits #920 FLAG_RFU2 still masks the BE and BS bits, fixed by fix: Webauthn Level 3 compliance fixes #931, released in 5.3.6
• chore(deprecation): deprecate the reserved-for-future-use accessors and the WebauthnToken arguments #921 deprecate the reserved-for-future-use accessors, done by chore(deprecation): deprecate the reserved-for-future-use accessors and the WebauthnToken arguments #948, milestone 5.4.0
• feat(credential-record): add the optional rpId member (W3C PR #2258) #922 optional rpId on the credential record, done by feat(credential-record): add the optional rpId member (W3C PR #2258) #949, milestone 5.4.0
• feat(cose): accept the RFC 9864 fully-specified algorithm identifiers #923 RFC 9864 fully-specified algorithm identifiers, done by feat(cose): accept the RFC 9864 fully-specified algorithm identifiers #951 on top of feat: support the RFC 9864 fully-specified algorithm identifiers cose-lib#157, milestone 5.4.0
• fix(prf): evalByCredential keys are not base64url encoded #924 evalByCredential keys are not base64url encoded, fixed by fix: Webauthn Level 3 compliance fixes #931, released in 5.3.6
• chore(prf): align with the generalized PRF processing model (W3C PR #2298 and #2372) #925 generalized PRF processing model, done by chore(prf): align with the generalized PRF processing model #950, milestone 5.4.0

Opened on 2026-08-30:

• feat(origins): scope the allowed origins per ceremony (W3C issue #2466) #942 scope the allowed origins per ceremony, from Document risks of allowing multiple origins w3c/webauthn#2466, done by feat(origins): pin the ceremony to the origin it was started on #953, milestone 5.4.0

Related, closed in the same batch: #858 on the 5 eTLD+1 labels limit for Related Origins, done by #952.

What is left

1. Nothing normative to implement. The next upstream review should look for a normative merge in w3c/webauthn more recent than Update Virtual Authenticator API to better emulate synced passkey behavior w3c/webauthn#2382 (2026-07-30).
2. feat(extensions): support remoteClientDataJSON for remote desktop web clients (WebAuthn ED) #854 (remoteClientDataJSON) is the only open follow-up, kept on 6.0.0 until the extension stabilizes.
3. Watch list, in decreasing order of impact: algPolicy and acceptedAlgs (Support Algorithm Migration w3c/webauthn#2437), the CMTG Key extension as a collection (Add "Credential Manager Trust Group (CMTG) Key" extension w3c/webauthn#2377 and #2472), the Cross Device Fallback URL extension (Add Cross Device Fallback URL extension for hybrid transport authentication w3c/webauthn#2380), the pubKeyCredParams defaults ([PQ] Default Algorithems for Authenticators perhaps need updating. w3c/webauthn#2448), and hash agility ([PQ] SHA-256 usage w3c/webauthn#2471).