Virtual authenticator should allow `counter` to always be `0`

[MasterKale]

Proposed Change

It doesn't seem possible today, with the currently defined WebAuthn virtual authenticator API, to emulate use of synced passkey credential managers. The authenticator data signCount always increments in authentication responses. This makes it impossible to use the virtual authenticators to test scenarios in which signCount is always 0 in auth responses.

Poking around the spec, it's possible to set an initial sign count when you add a credential to a virtual authenticator:

https://w3c.github.io/webauthn/#sctn-automation-add-credential

However this signCount always increments in subsequent authentications. If an RP backend keeps track of the counter, a test script that wants to automate the instantiation of a virtual authenticator and its credential would need to query the backend for its current signCount for that credential, or subsequent auth responses from the authenticator would have a signCount lower than what's in the DB, and the response would get rejected.

Maybe we can expand the Set Credential Properties endpoint to enable a credential response to always return with a signCount of 0 🤔

I'd like to talk about how we might enhance the virtual authenticator API to allow for better emulation of synced passkey providers.

[nsatragno]

Agreed, this sounds like a good idea.

[nicksteele]

That seems reasonable, only addition would be that we might want to support other values, but 0 would be a good place to start.

[MasterKale]

That seems reasonable, only addition would be that we might want to support other values, but 0 would be a good place to start.

This is a good idea, let's make it possible to set any positive numeric sign count to support more intentional testing of counter scenarios.

[MasterKale]

Shoot, while preparing a PR to address this issue I'm realizing that, even if we added a signCount parameter to the Set Credential Properties virtual authenticator endpoint and used it to set the signature counter of an existing passkey to zero, the virtual authenticator will increment the signature counter and report authData.signCount of 1 in the next authentication response.

I can still see the value in being able to change a credential's associated signature counter, especially for testing cloned authenticator scenarios, this so I'll proceed with PR #2382. However what I think is also needed now is some way to set up a virtual authenticator to always return an authData.signCount of 0 and never increment the counter, to properly behave like a synced passkey authenticator.

[MasterKale]

Bikeshedding this a bit: maybe we can add an isSyncing property to the Add Virtual Authenticator endpoint, default it to false (to not break existing use of virtual authenticators,) then specify virtual authenticator behavior to always report authData.signCount of 0 and not increment a credential's counter when isSyncing is set to true.

[kreichgauer]

Would it make sense to make the virtual authenticator treat the sign counter as fixed to 0 by default to match the majority of real world implementations?

If we really wanted to support testing other values, Set Credential Properties could pass in a different (fixed) value, and the caller could manually increment in whatever steps it wants to test. (But Chrome's position on this is still that the counter should be ignored in all but truly exceptional cases.)

[MasterKale]

Would it make sense to make the virtual authenticator treat the sign counter as fixed to 0 by default to match the majority of real world implementations?

I agree it would be nicer if the default behavior reflected the majority behavior in which passkeys are being synced and signCount is almost always 0. However my concern with such a change is that it'd break all of the existing use of virtual authenticators that RPs have written into their automated tests that expect the sign count to increment automatically because of current virtual authenticator behavior. That's why it seems best to handle this with the addition of an opt-in change to virtual authenticator signature count behavior.

If we really wanted to support testing other values, Set Credential Properties could pass in a different (fixed) value, and the caller could manually increment in whatever steps it wants to test.

This is giving me the idea of a new "freezeSignCount" boolean that could be added to the Set Credential Properties parameters. Combined with the new signCount I'm proposing in #2382, an RP could then hypothetically pass in...

{ "signCount": 0, "freezeSignCount": true }

...to this endpoint for a specific credential, at which point every subsequent use of that credential would yield a WebAuthn auth response with authData.signCount: 0 🤔