Re: [webauthn] Authenticator session not possible for BLE

Ok, I have to admit I know almost nothing about how Bluetooth stacks or drivers work.

I wasn't around when this language was added to the spec, but my understanding is this:

- More than one authenticator may be available to perform an operation.
- The command is sent to each available authenticator. This is required for first factor authentication, for example, as the client cannot know beforehand which authenticator to use.
- As soon as one authenticator returns a response we need to tell the other authenticators to cancel the ongoing operation, as they may otherwise remain locked indefinitely waiting for a user gesture.
- Therefore the concept of an "authenticator session" is necessary for the `authenticatorCancel` operation. Note that the session can be short-lived (i.e. terminate as soon as the first operation completes or is canceled) and it's perfectly fine for an authenticator to allow only one session (i.e. only one concurrent operation, except `authenticatorCancel`) at a time.

Although I suppose the issue of authenticators being left locked indefinitely could be somewhat solved by a required timeout.

Anyway, since there can be more than one client running on a device there must be a way to handle concurrent commands by different clients that don't know about each others' running operations. If a client _B_ tries to send a command to an authenticator currently processing a command send by client _A_ it MUST either

 1. result in an error returned to _B_ alone (otherwise _A_ could falsely interpret the error as _A_'s operation having failed, rather than _B_'s operation being refused), or
 2. result in an error which _A_ can identify as not corresponding to _A_'s operation (otherwise _A_ could falsely interpret the error as _A_'s operation having failed, rather than _B_'s operation being refused), or
 3. be queued by the host driver (outside the client) to run as soon as the authenticator becomes available, or
 4. be queued by the authenticator to run as soon as it's available, or
 5. be run on the authenticator in parallel with _A_'s operation.

Clearly for BLE CTAP authenticators, and I expect for most authenticators, neither (4) nor (5) is an option. The remaining options are then that some layer between the client and authenticator, like an OS driver or the like, must do (1), (2) or (3); the choice shouldn't matter much, if at all, to the client.

If none of those is an option, we'll have to eliminate the `authenticatorCancel` operation and rely exclusively on timeouts. This seems to be how U2F handles the issue. It could be workable, but it'll likely make for a confusing user experience.

Modifying the WebAuthn spec to make authenticator responses include some kind of request ID would break backwards compatibility with U2F, since the client in general does not have access to the credential public key and therefore cannot verify what an authentication response message has signed over.

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

Received on Tuesday, 17 October 2017 11:21:06 UTC