Closed kmlhossen closed 5 years ago
Hi, this would require a change to Chromium (and potentially the WebAuthn specification if adding a new field to the credentials.get call), rather than this github repo. If you file a request at https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication or https://github.com/w3c/webauthn more information could probably be provided.
In general, for privacy reasons the WebAuthn API tries to avoid responding to any request until a response is received from an authenticator. This is to avoid giving additional information about a user attempting login to the relying party.
Thanks for the information
I was trying in the chrome with mac inbuilt fingerprint scanner (platform authenticator only) and wondering what will be the solution of the following use case for a relying party
Let's say user registered webauthn in device A with the relying party R. Authentication flow is like this, the user comes to the relying party R input username and clicks next, relying party pulls the previously registered credential Ids for the user to create allowCredentials and query the authenticator for authentication. All goes fine as authenticator has one of those allowCredentials associated private key
But let's say the same user goes to the device B not registered before and tries to login with the same relying party R by putting username and clicking next. This time again the relying party pulls over the registered credential Ids for the user to create allowCredentials and query the authenticator for authentication. But this time as the device B does not have any associated private key it shows an error popup window in chrome.
Is there any way we can pass any option to the navigator.credentials.get call so that if the associated private key is not present for the given allowCredentials we can just stop the webauthn flow by catching some error.
This will help to fall back to some other authentication method without showing the error popup window and ask the user later to register device B after successful login with other authentication methods.