- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 May 2022 23:24:26 +0000
- To: public-webauthn@w3.org
> It is valid for the authenticator to begin the counter at 0 during registration and increment it to 1 in the first assertion - in fact, this is the [specified behaviour](https://www.w3.org/TR/webauthn/#ref-for-signature-counter%E2%91%A0%E2%91%A4) for per-credential counters. So you may want to adjust that behaviour to instead reject credentials that attempt to authenticate with >0 after ever _authenticating_ with =0. > Sure, it may be *possible*, but I have also based my implementation on "what happens in the real world", and there are no devices that exhibit this behaviour, so until I find one that does this, I'd rather err on the stricter behaviour. Even though webauthn may be a standard, as is ctap and friends, they have a lot of room, and the only "standard" that matters is the lowest common denominator that is implemented functionally within this scope. > It might happen to be compatible with existing implementations, but I don't think there is strong enough reason to change it since there is still a simple and concise validation rule as described above. I think that the wording is annoying and confusing, and should instead describe the states and permutations that do and can exist and what should happen. for example ``` If at registration the counter is == 0 and authentication the counter is == 0 If at registration the counter is == 0 and authentication the counter is > 0 If at registration the counter is > 0 and authentication the counter is == 0 If at registration the counter is > 0 and authentication the counter is > 0 ``` This is far clearer to an RP implementing the specification about what they should do, and they understand that 4 possible states CAN exist. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1734#issuecomment-1141535940 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 May 2022 23:24:28 UTC