- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Sat, 22 Apr 2017 18:05:34 -0700
- To: W3C Web Authn WG <public-webauthn@w3.org>
[ I guess "reviews" are not automatically mirrored to the list :-/ we might want to update our github-notify-ml-config settings... ] This review: <https://github.com/w3c/webauthn/pull/378#pullrequestreview-34141186> The changes embodied in this PR #378 "Enable RP to choose authenticators based on key storage capability" are specific to only a single authenticator attribute (authnr attr) -- one indicating whether or not the authenticator+platform holds credential private keys. It allows RPs to select authnrs to employ based on this attribute. Additionally, we have attachment and transport authenticator attribute hints that an RP may also employ for authenticator selection. All of the above authenticator attributes are manifested in the webauthn API as individual values, and their processing is to some degree special-cased in the main [credential-creation](https://w3c.github.io/webauthn/#createCredential) and [assertion-generation](https://w3c.github.io/webauthn/#getAssertion) algorithms. However, there are further authenticator attributes that some RPs may find useful for authenticator selection. For example: * whether the authenticator has user interface capability of its own (e.g., for selecting among credentials, and/or RP ID display, and/or transaction confirmation), * whether the authenticator implementation and key storage is userland software or whether it is TEE/hardware-backed, * whether the authenticator is capable of user verification, or test of user presence, or is a silent/touchless authenticator. If in the future, customer RPs express a need to select authenticators based on any of these additional attributes, it will presently require API and algorithm changes to accommodate them. The original vision expressed by browser vendors for webauthn was that authenticator selection would not be needed. But perceived use cases have evolved and now we have the above-noted attributes in the API and the algorithms. How sure are we that we will not feel compelled in the not-too-distant future to need to accommodate authenticator selection based on yet more attributes (see examples above)? If we feel we need to accommodate RP-driven authenticator selection, we probably should have an extensible framework that does not require spec changes to accommodate selection via additional authenticator attributes, rather than the essentially ad-hoc approach we have so far taken, including in this PR. WRT the specific spec changes proposed in this PR #378 -- they need work in order to be correct. Further comments below. see: <https://github.com/w3c/webauthn/pull/378#pullrequestreview-34141186>
Received on Sunday, 23 April 2017 01:05:53 UTC