Re: [webauthn] Section 4.1.4 Use Existing Credential "get"

thanks much for your thoughts @rlin1 

my apologies, what I posted in https://github.com/w3c/webauthn/issues/480#issuecomment-308924747 is a summary abstraction of this portion of the alg, in a similar vein to the directly prior post https://github.com/w3c/webauthn/issues/480#issuecomment-308510804, and so omitted details. 

> Note that step 16 already does that, i.e. For each authenticator
> currently available on this platform, perform the following steps:.
> As a consequence allowCredentialDescriptorList only contains the
> credentials bound to that specific authenticator (see step 16.2).

understood. 

> Additionally, I think the algorithm must distinguish 2 cases: a)
> options.allowCredentialDescriptorList is non-empty b)
> options.allowCredentialDescriptorList is empty

agreed, the alg already does that in current step 16.3. I had essentially elided it in `[...]` (in https://github.com/w3c/webauthn/issues/480#issuecomment-308924747).

> In case a) we might want to filter the number of authenticators
> connected to the platform (e.g. as used in step 16) to the ones
> related to one (or more) credentials in `options.allowCredentialDescriptorList`.

Agreed -- the alg already does that in current step 16.2.   Also, `options.allowCredentialDescriptorList` should be `options.allowCredential` in the above.

> In case b) we should ask all [currently available] authenticators whether they
> have a credential [bound to] the request[ing] RP.

Agreed -- the alg already does that via current steps 15 & 16 & 16.3.

> One more issue: I think the transports are specific to the authenticator - not to the credential.  This means even if the platform has used BLE connection to talk to the authenticator while [creating the PK cred], if the the platform knows the authenticator is connected via USB at time of calling `get()`, USB connection is the right transport here (for `get()`).

yeah, I've also been thinking about that a bit.  Tho, I think it is something we should explore in a separate issue. 

```
> --> Idea of an algo
> replace current step 16 by
> 16a. if options.allowCredentialDescriptorList is empty then
```
You mean `options.allowCredentials`.  Also, this leaves out constructing `|allowCredentialDescriptorList|` (current step 16.2).

```
>      in parallel for each authenticator currently available on this 
>      platform, perform the following step:
>          1. using local configuration knowledge of the appropriate 
>             transport to use with authenticator, invoke 
>             the authenticatorGetAssertion operation on authenticator with rpId,
>              clientDataHash, [empty allowCredentialDescriptorList], 
>              and clientExtensions as parameters.
```
The current step 16 effectively does the above.  Note that we do not need to pass in `empty allowCredentialDescriptorList`, rather we just do not pass it in at all. 
```
> 16b. if options.allowCredentialDescriptorList is NOT empty then
```
You mean `options.allowCredentials`.
```
>     in parallel for each authenticator currently available on this platform, 
>     perform the following step:
>         1. execute a platform-specific procedure to determine which, if any,
>            public key credentials described by options.allowCredentials are
>            bound to this authenticator, by matching with rpId, 
>            options.allowCredentials.id, and options.allowCredentials.type. Set 
>             allowCredentialDescriptorList to this filtered list.
>         2. Determine the appropriate transport for talking to the
>            authenticator by examining local platform knowledge and the 
>            transport field for each of the credentials in
>            allowCredentialDescriptorList.
>         3. Then, using transport, invoke the authenticatorGetAssertion
>             operation on authenticator, with rpId, clientDataHash,
>            allowCredentialDescriptorList, and authenticatorExtensions as
>             parameters.
```

OK, this overall proposal ends up being essentially the same as the overall current step 16, except that:

a. it switches first on whether `options.allowCredentials` is empty or not (perhaps a worthwhile optimization?), and, 
b. it includes examining the cred descriptors' transport values. 

So, other than (a), this is what I was/am proposing.  

It seems we are largely on the same page. 

I have changes locally queued that essentially match this, except for (a).  I'll submit those as a PR. If we feel (a) is a worthwhile optimization, we can address it separately. OK?  thanks!













-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/480#issuecomment-309095565 using your GitHub account

Received on Friday, 16 June 2017 18:07:56 UTC