Re: [webauthn] Not necessary to pass AuthenticatorSelectionCriteria members to authenticatorMakeCredential()

@AngeloKai wrote:
> Software authenticators such as Windows Hello can alter behaviors differently based on what inputs they accept, including key storage and user verification behaviors

**A)** Ok, so that means that we are altering the "authenticator model" from what it was/is in U2F & UAF. The latter is that authnrs' behaviors are fixed and describable by relatively simple metadata.  We are now saying that (some) authnrs' behavior is tailorable by RPs at createCredential() and (it seems?) getAssertion() times.  

**B)** This alteration to the "authnr model" is nominally ok by me, though I argue that we need to comprehensively craft the approach (i.e., have a framework), and the approach needs to be extensible, ideally without altering the webauthn API.  I.e., over time folks will invent new authnr characteristics. As they are invented, they will need identifiers assigned such that they can be reasoned about and RPs can selectively employ them or not. If the webauthn API has to change to reflect newly-characterized authnr behaviors, then that's suboptimal.

The present approach in webauthn, i.e., [authenticatorSelection](, requires alteration of the webauthn API in that we're adding items to the latter dictionary, which is an API change whenever something new is added.  Also, these tailorable characteristics such as rk (requireResidentKey) and uv (requireUserVerification) are not documented/cataloged in the same place as other authenticators (see [fido-registry "authenticator characteristics"]( This is an issue for FIDO authnr interop & security certification program, which needs to keep track of these characteristics in order to factor them into said program.  

**C)** There are technical issues with the present [authenticatorSelection]( approach. 

**wrt (A)**, we need to properly explain this in the webauthn spec and IMHO it is not at this time. 

**wrt (B)**, we should have an approach that leverages an authnr characteristics registry (perhaps the existing one) such that these issues are addressed.  Doing so will also make it easier for us to enable use of already-fielded authnrs via the webauthn API. Also, adding denotation of such characteristics, one by one as they come up, to the API is error-prone. See below for technical issues with the present approach, eg (1). 

**wrt (C)**:

1. [#createCredential](  step 21 checks for both `authenticatorSelection.rk` and `authenticatorSelection.uv` but in step 24.3 only `rk` is passed to the authenticatorMakeCredential operation. see also #536.

2. Ostensibly, IIUC, one wants/needs to pass `authenticatorSelection.uv` in the [#getAssertion]( call, but [authenticatorSelection]( is part of [MakePublicKeyCredentialOptions](, which is not passed at all to [#getAssertion](  

3. CTAP expects `up` (user presence test) and `uv` to be passed to authenticatorGetAssertion, but there is no presently specified means for that to be done in [#getAssertion]( This was apparently an omission in PR #460 that we missed in review. 

4. allocating these feature/characteristics as individual booleans seems heavy-weight and clunky, to me anyway.  One can set bit flags in javascript just like in C, and WebIDL has the requisite unsigned integers to accommodate series of bit flags. 

    Or, we already have the [User Verification Method Extension (uvm)]( which defines a structure to convey bit fields encoded in CBOR and meshes with [fido-registry "authenticator characteristics"](  We could update the UVM extension to take a `uvmFormat` as an input in order to convey authenticator feature requests (such as `uv` and `up`).

GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at using your GitHub account

Received on Thursday, 7 September 2017 02:04:07 UTC