- From: balfanz via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 23:46:35 +0000
- To: public-webauthn@w3.org
One of the problems that this new method was trying to address was to not reveal whether or not a platform authenticator was available on the device, unless the user approves. If the result is a `Promise<bool>`, however, then the caller will know: - if it gets immediately resolved with false, it means there is no platform authenticator All other cases mean that there is a platform authenticator: - if it gets resolved after a while with false, it means there is a platform authenticator (user saw the system UI - which is only shown if there is, in fact, a platform authenticator, and declined) - if it gets (eventually) resolved with true, it means there is a platform authenticator - if it gets never resolved, it means that there is a platform authenticator (user saw the system UI - which is only shown if there is, in fact, a platform authenticator, and never takes action) If the result is a `Promise<void>`, on the other hand, there is ambiguity: - if the promise never gets resolved, we don't know whether the user declined, or whether there is no platform authenticator. I will also point out that in the most likely case (the user approves use of the platform authenticator), the promise resolves in _both_ approaches. And in the case where the user doesn't interact with the system UI, the promise resolves in _neither_ approach. You only get the benefit of not having a dangling promise in the `Promise<bool>`-variant if the user actively denies the use of the platform authenticator in the system UI. I'm in favor of addressing @mikewest 's concerns in another PR. -- GitHub Notification of comment by balfanz Please view or discuss this issue at https://github.com/w3c/webauthn/pull/379#issuecomment-320375807 using your GitHub account
Received on Friday, 4 August 2017 23:46:36 UTC