Intent to Implement & Ship: [webdriver] Better signature counter support for WebAuthn virtual authenticators

[Nina Satragno]

Contact emails

nsat...@chromium.org

Explainer

https://github.com/w3c/webauthn/issues/2363

Specification

https://github.com/w3c/webauthn/pull/2382

Summary

The Web Authentication API specifies a series of webdriver commands to support testing. These commands set up "virtual authenticators" that behave as if they were connected to the user agent and can service WebAuthn operations. https://github.com/w3c/webauthn/pull/2382 introduced two changes related to signature counters:

* The Add Credential command can now take a null `signCount` parameter. This specifies that the virtual authenticator will set the signature counter to zero on every subsequent get assertion operation, matching the behaviour of synced passkey providers.

* A new `signCount` parameter to the Set Credential Properties command that lets callers override the signature counter on the authenticator to test simulated duplicated authenticators.

We are requesting permission to ship these webdriver-only changes. Webdriver classic is a little special in that there doesn't seem to be a sane way to flag guard the changes (and developers can set whatever flags they want anyway!). Thus, in attempting to follow the exciting webdriver WP launch process, we are asking for permission before landing any code.

Blink component

Blink>WebAuthentication

Web Feature ID

N/A

Motivation

Better support testing code that checks signature counters.

Initial public proposal

https://github.com/w3c/webauthn/issues/2363

Search tags

webauthn, webdriver, signature counter

TAG review

N/A This is a small webdriver feature.

TAG review status

Not applicable

Goals for experimentation

No experimentation.

Risks

Interoperability and Compatibility

Safari and Firefox both support the automation API. Firefox isn't very active in the spec, but a webkit engineer has approved the spec change.

Gecko: N/A Too small of a feature to wait for this.

WebKit: N/A Too small of a feature to wait for this.

Web developers: MasterKale@ (Duo / Cisco) authored the spec change.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

This is a webdriver feature.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
On Chrome, the WebAuthn webdriver API is only supported on desktop.

Is this feature fully tested by web-platform-tests?

We'll land WPTs once the feature lands. I can't find any sane way to flag-guard a webdriver classic change of this nature.

Flag name on about://flags

None.

Finch feature name

None.

Non-finch justification

This is a webdriver feature.

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/533056772

Estimated milestones

153

Anticipated spec changes

None.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4812056424480768?gate=6110516641660928

This intent message was generated by Chrome Platform Status.

--

Nina Satragno

[Rick Byers]

Looks like a trivial webdriver-only addition to me. 

Spec PR seems to have broad support in the WG and is just waiting on a 2nd implementation commitment (not something our process should block on). 

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0jiomsDBgLmcFb-wKnMYiiD5YYGPKcecdAVS4ZnUOecX_9-g%40mail.gmail.com.

[Vladimir Levin]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9rGDvS7A%2BtqQFdK-L9zJHumDOT8P67BY8tM29CvchEiw%40mail.gmail.com.

[Chris Harrelson]

LGTM3

Assuming the spec PR will land before shipping?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2OHaU5aRC0Voc%3D88QDxJMkVUBnCwLoW5kFt8%3DBTXxrfFw%40mail.gmail.com.

[Chris Harrelson]

On Wed, Jul 22, 2026 at 2:10 PM Rick Byers <rby...@chromium.org> wrote:

On Wed, Jul 22, 2026 at 4:31 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

Assuming the spec PR will land before shipping?

Perhaps. But it sounds like they're blocking landing the PR on 2nd implementation support, which I think means we should not block our I2S on the PR landing, right?

If that's the case then yes I agree.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_qzSRzzMna%2BupdqWkP%2Bk2Xu1rU-m3tj960ktX6zmodhg%40mail.gmail.com.

[Rick Byers]

On Wed, Jul 22, 2026 at 4:31 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

Assuming the spec PR will land before shipping?

Perhaps. But it sounds like they're blocking landing the PR on 2nd implementation support, which I think means we should not block our I2S on the PR landing, right?