- From: Matthew Miller via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 18:45:04 +0000
- To: public-webauthn@w3.org
> That behavior isn't standardized though, right? There's [an entire section in the spec](https://w3c.github.io/webauthn/#sctn-sign-counter) that outlines signature counter behavior for those authenticators that maintain one. This section _does_ have [a carve-out for authenticators that don't wish to track signature counters](https://w3c.github.io/webauthn/#sctn-sign-counter:~:text=Authenticators%20that%20do%20not%20implement%20a%20signature%20counter%20leave%20the%20signCount%20in%20the%20authenticator%20data%20constant%20at%20zero.): > Authenticators that do not implement a signature counter leave the signCount in the authenticator data constant at zero. The Virtual Authenticator API section of the spec doesn't explicitly mandate the implementation of a signature counter feature, but in practice one has clearly been implemented, including by Chrome's implementation. I concede the point that there's currently no normative requirement that virtual authenticators implement a signature counter feature. Thus there is nothing preventing e.g. Chrome's implementation from immediately switching to returning `0` in all ceremonies. But I still maintain that such a switch would be disruptive to Relying Parties, like Cisco Duo, that have automation testing in place that asserts the incrementing of signature counts based on observed virtual authenticator behavior. Having said all that, at the very least I hope there'd be sufficient notification in advance of such an upcoming change in virtual authenticator behavior so that RPs won't suddenly face breaking tests when e.g. "the newest version of Chrome in the test runner setup stopped incrementing the counter." > And if asserting anything about signature counters should be exceptionally rare in production, shouldn't it equally be exceptionally be rare in virtual authenticator tests? I have a hard time believing that there are deployments that actually enforce this in any meaningful way. Perhaps it's time to discuss, as a WG, about whether it's worth it anymore for [RPs to verify the signature counter during authentication](https://w3c.github.io/webauthn/#sctn-verifying-assertion:~:text=If%20authData.,Counter%20Considerations.) as the spec instructs them to. As a WebAuthn library maintainer I know that my two libraries implement signature counter verification because the spec says RPs need verify them. These libraries would definitely throw on the unexpected removal of virtual authenticator signature counters if tests weren't able to get updated in time with whatever hypothetical browser update changes authenticator behavior without the spec text normatively changing in some way. > IMO mimicking real world behavior is more important here than preserving historical behavior. I don't disagree with you, I'm only trying to be mindful of changes to the Virtual Authenticator API that would throw Relying Parties for a loop. I'm looking for a simple way to offer an opt-in change to virtual authenticator behavior first (i.e. from incrementing the counter to not incrementing the counter,) that can become an opt-out mechanism later for those RPs who want to have test coverage of cloned authenticator scenarios as is supported by the currently defined Virtual Authenticator API. -- GitHub Notification of comment by MasterKale Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2363#issuecomment-3813171688 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 18:45:05 UTC