W3C home > Mailing lists > Public > public-webauthn@w3.org > April 2018

[webauthn] Authenticators that do not recognize any handles shouldn't just be dropped on the floor

From: kpaulh via GitHub <sysbot+gh@w3.org>
Date: Fri, 06 Apr 2018 23:24:01 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-312147394-1523057041-sysbot+gh@w3.org>
kpaulh has just created a new issue for https://github.com/w3c/webauthn:

== Authenticators that do not recognize any handles shouldn't just be dropped on the floor ==
Context from the sister issue raised in the CTAP2 spec: [fido-2-specs/issues/509](https://github.com/fido-alliance/fido-2-specs/issues/509):
"When a privacy-conscious client collects assertions, it does not reveal immediately to an RP that no authenticator recognized any of the identifiers in the allow list. Doing so would allow malicious RPs to test for the presence of authenticators using only a credential id.

In Chrome, both in U2F and WebAuthn, we handle this by making plugged in USB authenticators blink until the user selects one of them (and thereby gives consent to reveal its presence). At that point we return an error indicating that no key handle was recognized."

We had been doing this in the cryptoken extension as well. However, the WebAuthN spec, in 6.2.3.2, states that if no credentials are present on that authenticator, 
"return an error code equivalent to "NotAllowedError" and terminate the operation."
(Effectively, drop the device on the floor and waiting for other hotplugged devices.)

To be consistent with CTAP2, we think we should send the authenticator one of the keyhandles so that it blinks, and if the user selects that authenticator by giving it a tap, then return "InvalidStateError" to indicate the user tried to use a device that wasn't actually registered.

(Similar to how the spec handles user consent for already-registered authenticators in 6.2.2.3)

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/863 using your GitHub account
Received on Friday, 6 April 2018 23:24:14 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:32 UTC