crrev.com/c/1181863 is going to land soon which only aborts the request on OPERATION_DENIED for platform authenticators

After discussing this in the last days, I think we can extend this to all transports. Though there probably is no real urgency since there are probably no existing devices with this use case (they would need a cancel button, UI display or a user verification mechanism, i.e. biometrics or similar).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5bac165c3a66f63ce3511975a81d72c8b7031058

commit 5bac165c3a66f63ce3511975a81d72c8b7031058
Author: Martin Kreichgauer <martinkr@google.com>
Date: Wed Aug 22 16:41:10 2018

fido: return NOT_ALLOWED_ERROR for OPERATION_DENIED from platform authenticator

This changes FidoRequestHandler to translate any
CtapDeviceResponseCode::kCtap2ErrOperationDenied
(CTAP2_ERR_OPERATION_DENIED) responses from platform authenticators into
FidoReturnCode::kUserConsentDenied. Upon receiving this error, all
outstanding authenticator requests are cancelled, and the error is
bubbled up into a NOT_ALLOWED_ERROR.

More concretely, this is going to change UI behavior such that the
request is cancelled if the user clicks cancel or fails verification in
the native macOS Touch ID dialog.

The WebAuthn spec in sections 5.1.3 and 5.1.4 states that "If any
authenticator returns a status indicating that the user cancelled the
operation", which indicate that the UA should cancel the entire
operation and return NOT_ALLOWED_ERROR in this case".

CTAP2_ERR_OPERATION_DENIED is used by the CTAP2 spec to signal
 - user declined to create a credential
 - user failed gesture verification
 - time out during user consent collection
 - user failing to select a credential on authenticators with account
chooser UI (deny or timeout)

Because of the reference to authenticator-defined timeouts, it is
debatable whether this CTAP error sufficiently indicates that "the user
cancelled the operation". For internal authenticators (Touch ID),
however, this is definitely the case. I will track a follow-up
discussion whether to extend this behavior to external authenticators
also in crbug/875982.

Also fix a bug in MockFidoDevice GetId generation and add a
|ExpectCtapRequestAndReturnError| helper method.

Bug:  875982 ,  678128 
Change-Id: I616b319accb7d387c0d98de059c52b04bc80ce59
Reviewed-on: https://chromium-review.googlesource.com/1181863
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: Jun Choi <hongjunchoi@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#585070}
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/content/browser/webauth/authenticator_impl.cc
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/fido_constants.h
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/fido_request_handler.h
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/fido_request_handler_unittest.cc
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/get_assertion_handler_unittest.cc
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/make_credential_handler_unittest.cc
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/mock_fido_device.cc
[modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/mock_fido_device.h

> since there are probably no existing devices with this use case (they would need a cancel button, UI display or a user verification mechanism, i.e. biometrics or similar).

Actually, I'm not certain if this is totally true: Feitian appears to have a prototype FIDO2 key with fingerprint reader.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8e6f1b321789b67f4da7dfb35e01f831797382e1

commit 8e6f1b321789b67f4da7dfb35e01f831797382e1
Author: Martin Kreichgauer <martinkr@google.com>
Date: Fri Aug 24 13:42:49 2018

fido: make CTAP2_ERR_OPERATION_DENIED cancel the request

This is a follow-up to crrev.com/c/1181863, which added OPERATION_DENIED
handling for Touch ID. In this change that behavior is extended to all
transports.

Bug:  875982 
Change-Id: If10000f8333dccd4c2e83becf51e36baedbc2655
Reviewed-on: https://chromium-review.googlesource.com/1187683
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#585823}
[modify] https://crrev.com/8e6f1b321789b67f4da7dfb35e01f831797382e1/device/fido/fido_request_handler.h
[modify] https://crrev.com/8e6f1b321789b67f4da7dfb35e01f831797382e1/device/fido/fido_request_handler_unittest.cc
[modify] https://crrev.com/8e6f1b321789b67f4da7dfb35e01f831797382e1/device/fido/get_assertion_handler_unittest.cc
[modify] https://crrev.com/8e6f1b321789b67f4da7dfb35e01f831797382e1/device/fido/make_credential_handler_unittest.cc