The workaround originally described has a flaw - it would require a user touch for the CTAP2 request and again for U2F.

We can't always use U2F if we see the appID extension because the extension is per-request, which could have multiple credentials which could be of either protocol.

So, we're planning to initially do a silent CTAP2 query first and then decide to proceed with CTAP2 or U2F from that point. Jun estimates ~200 LOC but somewhat painful changes to tests.

On the upside, this change will likely give us more flexible UI options in the future.

Balazs, wdyt?

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

commit 7ffaa1de4abce1791d14fade9c2c00f7b0022446
Author: Jun Choi <hongjunchoi@chromium.org>
Date: Mon Sep 17 17:54:04 2018

Fallback to U2F sign if appId extension is present

When conducting GetAssertion task for devices that support both CTAP2
and U2F protocols, it may be the case the legacy appId credentials are
stored in CTAP2 devices. As so, fallback to U2F sign request if CTAP
GetAssertion request fails when appId extension in present.

Bug:  883068 
Change-Id: I372cd1cb1976cf476771a516c515d9f0c259fcc4
Reviewed-on: https://chromium-review.googlesource.com/1222989
Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Commit-Queue: Jun Choi <hongjunchoi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591734}
[modify] https://crrev.com/7ffaa1de4abce1791d14fade9c2c00f7b0022446/device/fido/ctap_request_unittest.cc
[modify] https://crrev.com/7ffaa1de4abce1791d14fade9c2c00f7b0022446/device/fido/fido_test_data.h
[modify] https://crrev.com/7ffaa1de4abce1791d14fade9c2c00f7b0022446/device/fido/get_assertion_task.cc
[modify] https://crrev.com/7ffaa1de4abce1791d14fade9c2c00f7b0022446/device/fido/get_assertion_task.h
[modify] https://crrev.com/7ffaa1de4abce1791d14fade9c2c00f7b0022446/device/fido/get_assertion_task_unittest.cc

Requesting merge of https://chromium-review.googlesource.com/c/chromium/src/+/1222989 to M70. 


This change is purely for regression purposes. 

Problem: Previously chrome was rejecting users with new CTAP2 devices to sign-in using credentials registered via legacy API. 

This change fixes this by correctly handling backwards-compatibility issues. 

Impact: While the change is relatively small and effects small portion of the logic flow/code base, this issue may prevent end users with the new CTAP2 security keys from signing-in. If they were had previously registered the keys via legacy U2F API's. 

Did you folks test this with BLE keys?

No, mainly because we do not have access to BLE security keys that support both CTAP2 and U2F. 

Yubico security key we use for most testing only support HID, and some Feitian BLE security key supports CTAP2 but not U2F. 

This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re: #7, what I mean is, can we at least verify that two commands in a row over BLE have any chance of working?

That is:

 1.) Take a CTAP2 BLE key.
 2.) Trick a custom build of Chrome into believing it's a hybrid key (by short-circuiting the logic that determines this).
 3.) Let Chrome issue a (successful) check-only GetAssertion followed by a real GetAssertion command with up/uv.

Check if this actually works with a single tap.

Let's confirm #9 first, and then I can review merge. 

Reply for comment #6 and #10: 

Authentication using BLE security keys is manually confirmed. BLE device did not timeout and only single user touch was needed. 

Note: Due to lack of testing devices, we used "FIDO Digipass CTAP2 security key"[1] for testing. 

[1]: https://www.vasco.com/

Thanks for confirming, really glad to hear it worked okay!

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

commit 90347b806a468ff71e55f2ae5325907b9d567bfb
Author: Jun Choi <hongjunchoi@chromium.org>
Date: Thu Sep 20 21:05:40 2018

Fallback to U2F sign if appId extension is present

When conducting GetAssertion task for devices that support both CTAP2
and U2F protocols, it may be the case the legacy appId credentials are
stored in CTAP2 devices. As so, fallback to U2F sign request if CTAP
GetAssertion request fails when appId extension in present.

Bug:  883068 
Change-Id: I372cd1cb1976cf476771a516c515d9f0c259fcc4
Reviewed-on: https://chromium-review.googlesource.com/1222989
Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Commit-Queue: Jun Choi <hongjunchoi@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#591734}(cherry picked from commit 7ffaa1de4abce1791d14fade9c2c00f7b0022446)
Reviewed-on: https://chromium-review.googlesource.com/1237238
Reviewed-by: Jun Choi <hongjunchoi@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#552}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/90347b806a468ff71e55f2ae5325907b9d567bfb/device/fido/ctap_request_unittest.cc
[modify] https://crrev.com/90347b806a468ff71e55f2ae5325907b9d567bfb/device/fido/fido_test_data.h
[modify] https://crrev.com/90347b806a468ff71e55f2ae5325907b9d567bfb/device/fido/get_assertion_task.cc
[modify] https://crrev.com/90347b806a468ff71e55f2ae5325907b9d567bfb/device/fido/get_assertion_task.h
[modify] https://crrev.com/90347b806a468ff71e55f2ae5325907b9d567bfb/device/fido/get_assertion_task_unittest.cc

The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/90347b806a468ff71e55f2ae5325907b9d567bfb
Commit: 90347b806a468ff71e55f2ae5325907b9d567bfb
Author: hongjunchoi@chromium.org
Commiter: hongjunchoi@chromium.org
Date: 2018-09-20 21:05:40 +0000 UTC
Fallback to U2F sign if appId extension is present

When conducting GetAssertion task for devices that support both CTAP2
and U2F protocols, it may be the case the legacy appId credentials are
stored in CTAP2 devices. As so, fallback to U2F sign request if CTAP
GetAssertion request fails when appId extension in present.

Bug:  883068 
Change-Id: I372cd1cb1976cf476771a516c515d9f0c259fcc4
Reviewed-on: https://chromium-review.googlesource.com/1222989
Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Commit-Queue: Jun Choi <hongjunchoi@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#591734}(cherry picked from commit 7ffaa1de4abce1791d14fade9c2c00f7b0022446)
Reviewed-on: https://chromium-review.googlesource.com/1237238
Reviewed-by: Jun Choi <hongjunchoi@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#552}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

I'm not certain if what I'm seeing is related to this but it seems like it is. I've registered my YubiKey 5 that does not have a pin set. It's registering as a 'packed' attestation and not fido-u2f so that seems to work fine. But when I'm attempting to do a CTAP2 auth with navigator.credentials.get() in the passwordless mode aka without passing in any allowCredentials….
{"publicKey":{"challenge":{},"timeout":60000,"allowCredentials":[]}}"

I get an error of "InvalidStateError: The user attempted to use an authenticator that recognized none of the provided credentials." If I do this same thing but pass in the existing credentials registered on the account (aka U2F) the authentication succeeds. 

Same behavior on 72.0.3582.0 canary and 70.0.3538.67 beta

Hi there, this is WAI. Chrome doesn't yet support resident keys, so if you don't pass in any allowCredentials then the device won't be usable in CTAP2 mode. In this case, it also can't fall back to U2F since U2F doesn't have the concept of empty allow lists.

Ahh thank you. I see you opened another issue to track the disabling of resident keys. Hopefully full support comes soon as this is an extremely valuable use case and is already supported by Edge.