207951 2020-02-19 11:03:21 -0800 [WebAuthn] Yubikey 5ci lightning does not work in iOS 13.4 beta 2020-02-19 21:16:48 -0800 1 1 1 Unclassified WebKit New Bugs Other iPhone / iPad iOS 13 RESOLVED CONFIGURATION CHANGED P2 Major --- 181943 1 sweeden webkit-unassigned jiewen_tan oldest_to_newest 1620744 0 sweeden 2020-02-19 11:03:21 -0800 In testing WebAuthn on iOS 13.4 beta with an iPad Air 2 using a Yubikey 5ci authenticator, I used the WebAuthn parameters for requireResidentKey: false, userVerification: discouraged. The lightning key did NOT blink when performing a registration operation. The key does blink (and can be used) with the same parameters on the same device using iOS 13.3.1 (although there is a different problem with the AAGUID in the attestation result in that version). 1620796 1 jiewen_tan 2020-02-19 12:21:51 -0800 (In reply to sweeden from comment #0) > In testing WebAuthn on iOS 13.4 beta with an iPad Air 2 using a Yubikey 5ci > authenticator, I used the WebAuthn parameters for requireResidentKey: false, > userVerification: discouraged. The lightning key did NOT blink when > performing a registration operation. The key does blink (and can be used) > with the same parameters on the same device using iOS 13.3.1 (although there > is a different problem with the AAGUID in the attestation result in that > version). Could you tell me the exact beta version like: 17E5233g? BTW, we release beta 2 today, can you try that as well? 1620801 2 jiewen_tan 2020-02-19 12:26:10 -0800 It is probably a duplicate of Bug 204111, which is fixed in Beta 2. 1620918 3 sweeden 2020-02-19 15:51:41 -0800 I just installed 13.4 beta 2. Same behaviour. Key does not blink at all when registering with the following options: { "extensions": {}, "attestation": "direct", "challenge": "9MmAkj8jroow3kq_gKb5jjs8YjSA9jgMk-YXb86Xxj8", "authenticatorSelection": { "userVerification": "discouraged", "requireResidentKey": false }, "user": { "displayName": "REDACTED", "name": "REDACTED", "id": "k-rsnTR5Q6CWAmU_VMwjeA" }, "rp": { "name": "fidointerop.securitypoc.com", "id": "fidointerop.securitypoc.com" }, "timeout": 60000, "pubKeyCredParams": [ { "type": "public-key", "alg": -7 }, { "type": "public-key", "alg": -257 } ] } 1620919 4 sweeden 2020-02-19 15:56:09 -0800 The beta 2 build as you suggested is 17E5233g 1620929 5 sweeden 2020-02-19 16:18:32 -0800 Ok so more details. I got *another* Yubikey 5ci brand new and it worked. I think the defining difference is the yubikey that did not work had a PIN set whereas the one that did work did NOT have a PIN set. Not sure why that should make any difference when uv=discouraged is set in options... 1620939 6 jiewen_tan 2020-02-19 16:38:54 -0800 (In reply to sweeden from comment #5) > Ok so more details. I got *another* Yubikey 5ci brand new and it worked. I > think the defining difference is the yubikey that did not work had a PIN set > whereas the one that did work did NOT have a PIN set. > > Not sure why that should make any difference when uv=discouraged is set in > options... Alright then. Can you please try STP 101 which should have the fix for Bug 206547? I will close this bug as "configuration changed". Feel free to reopen it if you still see your issues on STP 101. 1620946 7 jiewen_tan 2020-02-19 16:46:28 -0800 (In reply to Jiewen Tan from comment #6) > (In reply to sweeden from comment #5) > > Ok so more details. I got *another* Yubikey 5ci brand new and it worked. I > > think the defining difference is the yubikey that did not work had a PIN set > > whereas the one that did work did NOT have a PIN set. > > > > Not sure why that should make any difference when uv=discouraged is set in > > options... > > Alright then. Can you please try STP 101 which should have the fix for Bug > 206547? I will close this bug as "configuration changed". Feel free to > reopen it if you still see your issues on STP 101. Actually, I'm wrong. You are talking about registrations. According to CTAP2 authenticatorMakeCredential Step 6: "If pinAuth parameter is not present and clientPin been set on the authenticator, return CTAP2_ERR_PIN_REQUIRED error." Link here: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorMakeCredential Yes, if your authenticator has a PIN, registrations won't work. 1621015 8 sweeden 2020-02-19 18:54:16 -0800 Is it reasonable to conclude that the reason my key stopped working for registration between 13.3.1 and 13.4 is that Safari is moving from CTAP1 to CTAP2? When using CTAP1 / U2F attestation, the presence or absence of the PIN would have been irrelevant. This is no longer the case with CTAP2. 1621022 9 jiewen_tan 2020-02-19 19:03:39 -0800 (In reply to sweeden from comment #8) > Is it reasonable to conclude that the reason my key stopped working for > registration between 13.3.1 and 13.4 is that Safari is moving from CTAP1 to > CTAP2? > > When using CTAP1 / U2F attestation, the presence or absence of the PIN would > have been irrelevant. This is no longer the case with CTAP2. That's probably not accurate. WebKit should always prefer CTAP2 if it is available. There was a bug that WebKit doesn't recognize authenticator that supports more than 2 protocols, and treat them all like U2F. 1621029 10 sweeden 2020-02-19 19:23:35 -0800 Ok thanks for letting me know. I am fine with leaving this one closed for now with an understanding that PIN-based authenticators simply are not yet supported. 1621036 11 sweeden 2020-02-19 19:39:43 -0800 Hmm - one additional question on this. When I use Chrome and set rk=false, uv=discouraged, I am not prompted for a PIN even if one is set on the authenticator, and I am able to register and get a fido2-u2f attestation. I guess with this combination of flags, Chrome is falling back to CTAP1. As soon as I change uv=preferred, then I get PIN prompt, plus I get a CTAP2 packed attestation format. This is not the case with WebKit. Is this a bug, or just a different interpretation of how to map webauthn parameters to CTAP? 1621066 12 jiewen_tan 2020-02-19 21:16:48 -0800 (In reply to sweeden from comment #11) > Hmm - one additional question on this. When I use Chrome and set rk=false, > uv=discouraged, I am not prompted for a PIN even if one is set on the > authenticator, and I am able to register and get a fido2-u2f attestation. I > guess with this combination of flags, Chrome is falling back to CTAP1. As > soon as I change uv=preferred, then I get PIN prompt, plus I get a CTAP2 > packed attestation format. > > This is not the case with WebKit. Is this a bug, or just a different > interpretation of how to map webauthn parameters to CTAP? Probably later, I don't think the CTAP 2.0 spec has specified such a fallback.