- From: Md kamal Hossen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Jul 2019 20:35:18 +0000
- To: public-webauthn@w3.org
kmlhossen has just created a new issue for https://github.com/w3c/webauthn: == navigator.credentials.get() option to suppress chrome UI popup if allowCredentials is not present in the authenticator == I was trying WebAuthN 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 the built in 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. Or is there anyway chrom can detect the error and pass it to the caller so that caller can take action instead of showing error to user by default 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. Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1251 using your GitHub account
Received on Monday, 1 July 2019 20:35:20 UTC