Issue metadata
Sign in to add a comment
|
Empty transports list in allowCredentials prevents using authenticator with WebAuthn
Reported by
br...@dropbox.com,
Oct 25
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:62.0) Gecko/20100101 Firefox/62.0 Steps to reproduce the problem: 1. Register an authenticator using WebAuthn API 2. Try to get a WebAuthn assertion for the authenticator with its "transports" set to "[]" in "allowCredentials" list To run the attached test case, it should be on a domain with https with a Yubikey/other authenticator plugged in. I used a self-signed cert and redirected "testlocal.com" to localhost in /etc/hosts. When the test page loads, open the developer console and watch the console logs while tapping the Yubikey twice. The first tap is for registration and always works, while the second tap will print a success message in working versions but in Chrome 70 just causes the authenticator to stop blinking What is the expected behavior? When requesting an assertion and the user selects the previously registered authenticator (ex: by tapping Yubikey), a valid assertion is returned What went wrong? When user selects authenticator whose "transports" field is an empty list, it stops blinking, but a valid assertion is not returned. Instead, the request eventually times out. If the "transports" field is undefined instead, a valid assertion is returned. Did this work before? Yes 69 Does this work in other browsers? Yes Chrome version: 70.0.3538.77 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.12 Flash Version: The workaround of setting "transports" to undefined instead of an empty list is easy, but this still looks like a bug (and likely not what spec intends).
,
Oct 26
Thanks for filing the issue! As per comment# 0 from the reporter issue seems to be related to Yubikey which is not available at ET team, hence routing this issue to Inhouse for further triaging the issue. Thanks!
,
Oct 26
phanindra.mandapaka: Our corp security keys are made by Yubico - they are a version of Yubikey. Regardless, this doesn't have anything to do with HTTP auth. I guess this falls under USB?
,
Oct 26
,
Oct 26
This is WAI. Empty allowCredential lists should ideally present an account chooser to permit the user to select which on-device credential they would like to use. We don't have an account chooser implemented yet. In m69, this meant that the default was to return the first credential found on the device for that RP. We decided to instead enforce that allowCredential lists must be populated with at least one credential until we can properly support this use case.
,
Oct 26
AIUI, this is not about empty allowCredentials lists, but about a PublicKeyDescriptor with an empty transports field in that list. I.e.:
allowCredentials: [{
"type": "public-key",
"id": keyHandle,
"transports": []
}]
That seems like a bug to me. We shouldn't handle unset fields differently from empty ones unnecessarily.
,
Oct 26
You're right, I read that too fast. I'll take this.
,
Oct 29
Seems it is out of scope from TE end as it is related to Yubikey , adding TE-NeedsTraige-help label to move this out of our triaging bucket. Could someone from dev team please take a look into this issue. Note: Tried with the available security key , but it doesn't work. Thanks..!
,
Oct 29
,
Oct 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7f232d720e47376f1f7b34ba6db7c33de8b991f1 commit 7f232d720e47376f1f7b34ba6db7c33de8b991f1 Author: Kim Paulhamus <kpaulhamus@chromium.org> Date: Tue Oct 30 22:51:21 2018 Accept empty transport lists in allowCredentials sequence<AuthenticatorTransport> in allowCredentials is an optional field. We should treat empty lists as if the transport option was undefined. Bug: 899045 Change-Id: Ifb45a505e428676b2c72b063f3c94d10f227d912 Reviewed-on: https://chromium-review.googlesource.com/c/1302014 Reviewed-by: Mike West <mkwst@chromium.org> Commit-Queue: Kim Paulhamus <kpaulhamus@chromium.org> Cr-Commit-Position: refs/heads/master@{#604043} [modify] https://crrev.com/7f232d720e47376f1f7b34ba6db7c33de8b991f1/third_party/WebKit/LayoutTests/http/tests/credentialmanager/credentialscontainer-get-with-virtual-authenticator.html [modify] https://crrev.com/7f232d720e47376f1f7b34ba6db7c33de8b991f1/third_party/blink/renderer/modules/credentialmanager/credential_manager_type_converters.cc
,
Nov 2
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Oct 26