W3C home > Mailing lists > Public > public-webauthn@w3.org > March 2018

[webauthn] Platform authenticators and key stores

From: Ibrahim Damlaj via GitHub <sysbot+gh@w3.org>
Date: Thu, 22 Mar 2018 21:07:22 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-307815027-1521752841-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:31 UTC