- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Jun 2020 14:06:39 +0000
- To: public-webauthn@w3.org
If, in Chrome, you go to chrome://device-log and select “Debug” as the log level then you can see the underlying CTAP2 traffic to the security key. In this case, I'm guessing that there won't be any and that you've set a PIN on the security key. Since we can't create a credential over CTAP 2.0 without PINs, once one has been set, Chrome is falling back to the U2F protocol, which cannot handle anything but ECDSA. Enabling resident keys overrides your "userVerification: discouraged" and forces UV, thus allowing CTAP2, thus allowing EdDSA. CTAP 2.1 fixes this problem but, prior to that, this is working as intended for Chrome I'm afraid. (Note: above is just a guess and I could be wrong. If the device-log contains CTAP2 traffic, that'll tell.) -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1437#issuecomment-640631540 using your GitHub account
Received on Monday, 8 June 2020 14:06:41 UTC