- From: Ki-Eun Shin via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Apr 2019 07:23:49 +0000
- To: public-webauthn@w3.org
RP may get supported extensions of a certain authenticator during registration. Then, RP stores such information within the it's storage (DB) to leverage later authentication. This means that the client (browser) understands and supports _exts_ extension or specific extensions that the RP has requested implicitly. After that, when the user tries to authenticate with the same authenticator on another client (which does not support such extensions), RP will set the supported extensions by investigating the storage and expect to be processed by the client and the authenticator. But, it will not work as expected since the client does not support the extension although the authenticator can handle it. So, RP will see an error or unexpected results and then understand that the client does not support requested extensions. RP will be happy if it can provide smooth and concrete UX for the users. So, the RP will provide user flow by checking whether the user's client supports extensions that RP wants to leverage or not. For example, RP does not want to make caBLE authentication flow when the client does not support it although caBLE registration was done before. -- GitHub Notification of comment by Kieun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1199#issuecomment-484386830 using your GitHub account
Received on Thursday, 18 April 2019 07:23:50 UTC