Adam, can you please look into this?

No further triaging needed. I vaguely recall there has been some discussion around what exactly we should return here and whether the spec should be updated. Kim, Adam, do you remember details of that discussion?

As I recall, the discussion about the appid result was around whether there should be any result. The RP, after all, knows the answer: if the credential was registered with U2F and worked, then appid was supported.

There is currently https://github.com/w3c/webauthn/issues/948 on this topic too.

The current behaviour was motivated by the thought that returning "false" tells the RP that it could use U2F credentials if it wished. But, if that is to change, then I think the spec would need to be updated to mark the appid member as optional.

I actually interpreted the current spec to mean that appid shouldn't be present in clientExtensionResults unless it was requested. (specifically as stated in the quote from comment #1). It also makes sense since clientExtensionResults is populated as a result from extensions processing, and if the extension isn't requested it wouldn't be processed.

I think we should update the behavior to this until the outstanding discussions Adam mentioned are resolved.

I've no problem either way. (I don't think appid should have a return value at all.) We can just make the value optional in our version of the IDL, but I won't be able to look at this until mid-July when I'm back from travels. (Waiting for a delayed flight at the moment.) Anyone else is welcome to tweak it in the mean-time though.

Yep, I can do that.

[i deleted my prior comment because I'd posted it too soon]

just to note, https://github.com/w3c/webauthn/issues/948 is closed, having been addressed (we hope) by https://github.com/w3c/webauthn/pull/967.  Though, the adopted resolution to  issue #948  does not seem to read on this particular issue (IIUC).

@agl:
> The current behaviour was motivated by the thought that returning "false" 
> tells the RP that it could use U2F credentials if it wished

Just to clarify: do you mean returning "false" in the sense of option 2 in https://github.com/w3c/webauthn/issues/982 where the appid was not used (i.e., the authnr is webauthn/FIDO2 (?)), but you are signaling what?  there is an available U2F authnr, or that you the client support U2F if the user has that flavor of authnr available, or ..?

I agree with @kpaulh that given the present spec language, appid shouldn't be _present_ in clientExtensionResults unless the appid extension was explicitly requested by the RP's JS when making the navigator.credentials.get() call.

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

commit ce352264fed659b1eb806c72650a39e7bc16ca54
Author: Adam Langley <agl@chromium.org>
Date: Fri Aug 10 17:38:22 2018

webauthn: only echo appid extension when requested.

This change aligns Chromium with the current state of the spec[1]: the
“appid” extension output will only be returned when the caller requested
the appid extension, and it'll be true iff the AppID value was actually
used when getting the assertion.

[1] https://w3c.github.io/webauthn/#sctn-appid-extension

BUG= 853770 

Change-Id: I6ac9470c71bfc0cc3b38f6e91c5e8f00b0586405
Reviewed-on: https://chromium-review.googlesource.com/1162823
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Jun Choi <hongjunchoi@chromium.org>
Reviewed-by: Greg Kerr <kerrnel@chromium.org>
Commit-Queue: Adam Langley <agl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582231}
[modify] https://crrev.com/ce352264fed659b1eb806c72650a39e7bc16ca54/content/browser/webauth/authenticator_impl.cc
[modify] https://crrev.com/ce352264fed659b1eb806c72650a39e7bc16ca54/content/browser/webauth/authenticator_impl.h
[modify] https://crrev.com/ce352264fed659b1eb806c72650a39e7bc16ca54/content/browser/webauth/authenticator_impl_unittest.cc
[modify] https://crrev.com/ce352264fed659b1eb806c72650a39e7bc16ca54/third_party/blink/public/platform/modules/webauthn/authenticator.mojom
[modify] https://crrev.com/ce352264fed659b1eb806c72650a39e7bc16ca54/third_party/blink/renderer/modules/credentialmanager/credentials_container.cc