- From: Ibrahim Damlaj via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Mar 2018 21:07:22 +0000
- To: public-webauthn@w3.org
idamlaj has just created a new issue for https://github.com/w3c/webauthn: == Platform authenticators and key stores == Issue #420 (PR #708) details how a relying party who only wants platform authenticators can create authentication flows using the web authentication API: * Relying party creates a credential with attachment=platform * Relying party stores the credential ID (let's call it cred1) in HTML5 local storage * Next time a user wants to authenticate, relying party passes [cred1] as allowCredentials in .get(), knowing that cred1 was created as a platform credential. This method works fine most of the time. However, on some platforms, the key store holding the platform credential cred1 – or its decryption key, if it is a server-resident credential – may get wiped for a variety of reasons (e.g. last fingerprint removed, disabling / re-enabling screenlock, etc). If we follow the WebAuthn specification as is, the following user flow will occur: * Relying party creates a credential with attachment=platform * Relying party stores the credential ID (cred1) in HTML5 local storage * Day to day, relying party authenticates the user by passing [cred1] as allowCredentials in .get() * One day, the user disables and re-enables the screenlock on their device. This deletes all the platform credentials in the device's key store, including cred1. * Next time the relying party tries to authenticate the user, the platform will not know cred1 is a platform key, so the platform will display a UI asking the user to present a security key – which they never created. * User will try to cancel out of this security key UI * Relying party will get NotAllowedError which could mean anything from "timeout" to "user canceled authentication", so they can't tell that the user is in this state. * Thus, user will keep getting asked for a security key they never created every time they visit the relying party web site. Is this a scenario that the working group cares about? If so, what are the recommendations to prevent the user experience described above? Please view or discuss this issue at https://github.com/w3c/webauthn/issues/851 using your GitHub account
Received on Thursday, 22 March 2018 21:07:25 UTC