RESOLVED FIXED Bug 215836
[WebAuthn] Don't set the UV option if the authenticator doesn't support it
https://bugs.webkit.org/show_bug.cgi?id=215836
Summary [WebAuthn] Don't set the UV option if the authenticator doesn't support it
login Llama
Reported 2020-08-25 20:31:34 PDT
This is related to Bug 213934 For CTAP2.0 and CTAP2.1_Pre authenticators that don't support internal user verification sending the UV option will cause a CTAP2_ERR_UNSUPPORTED_OPTION. See authenticatorMakeCredential step 3 ( https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorMakeCredential ) and authenticatorGetAssertion Step 5. During Authenticator selection if clientPin is set in getInfo options, the platform is sending a dummy request to the authenticator to make the led blink to determine what authenticator to use. This works when the webAuthn request contains User Verification absent/Discouraged/preferred. However if User Verification required is sent by the RP the platform includes the uv=true option and that causes a CTAP2_ERR_UNSUPPORTED_OPTION error for CTAP2.0 authenticators that don't support internal UV. For Authenticators that do support internal UV it seems that some are performing internal UV (fingerprint etc) and not returning the expected error. I expect that the CTAP 2.0 authenticators with no internal UV are also going to have a further problem after authenticator selection if both a pinToken and uv option are sent to them. Bio Authenticators receiving both the uv option and pintoken may or may not work. My test CTAP2.1 authenticators that ignore the UV option work but as client pin authenticators ignoring the fingerprint, and other authenticators like the biopass I tested are not working. The first step would be to remove the uv option being sent with pintoken. That should never happen in CTAP 2.0. I hope that platforms MUST NOT do that is more clear in the CTAP2.1 spec. This should explain why the MS test page that sets user verification required won't work with a YK 5Ci but the same key will work just fine with a resident credential on a site with User Verification optional.
Attachments
Patch (12.57 KB, patch)
2020-09-13 23:48 PDT, Jiewen Tan
no flags
Patch (26.58 KB, patch)
2020-09-18 00:47 PDT, Jiewen Tan
darin: review+
Patch for landing (26.57 KB, patch)
2020-09-21 13:46 PDT, Jiewen Tan
no flags
Radar WebKit Bug Importer
Comment 1 2020-08-26 11:20:55 PDT
login Llama
Comment 2 2020-08-26 14:06:40 PDT
I retested with with iOS developer beta 6, and as expected the behavior is the same.
Jiewen Tan
Comment 3 2020-09-13 22:35:41 PDT
The spec suggests: "user verification: Instructs the authenticator to require a gesture that verifies the user to complete the request. Examples of such gestures are fingerprint scan or a PIN." The "PIN" mentioned there is confusing with ClientPIN. Should we fix this confusing text in CTAP 2.1 as well? @John, what do you think?
Jiewen Tan
Comment 4 2020-09-13 23:35:01 PDT
*** Bug 216180 has been marked as a duplicate of this bug. ***
Jiewen Tan
Comment 5 2020-09-13 23:36:06 PDT
*** Bug 214266 has been marked as a duplicate of this bug. ***
Jiewen Tan
Comment 6 2020-09-13 23:48:53 PDT
Jiewen Tan
Comment 7 2020-09-18 00:47:09 PDT
login Llama
Comment 8 2020-09-18 10:17:11 PDT
Each authentication requires a test of user presence. In some cases the user verification method also provides the test of user presence such as a fingerprint. The clientPIN is never considered a test of user presence. Now in CTAP2.1 with the pinUvAuthToken the explanation has been almost totally re-written. There is still some up caching text that Jeff is still working on so it is not totally merged. RD02 should be available shortly. Let me know if you think it is still confusing.
Jiewen Tan
Comment 9 2020-09-18 17:12:56 PDT
(In reply to login Llama from comment #8) > Each authentication requires a test of user presence. > > In some cases the user verification method also provides the test of user > presence such as a fingerprint. > > The clientPIN is never considered a test of user presence. > > Now in CTAP2.1 with the pinUvAuthToken the explanation has been almost > totally re-written. > > There is still some up caching text that Jeff is still working on so it is > not totally merged. > > RD02 should be available shortly. Let me know if you think it is still > confusing. Sure.
Darin Adler
Comment 10 2020-09-20 11:07:41 PDT
Comment on attachment 409111 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=409111&action=review > Source/WebCore/ChangeLog:14 > + If an authetnicator supports ClientPin, it can set the uv bit in the responses to true but it typo: authenticator
Jiewen Tan
Comment 11 2020-09-21 13:44:21 PDT
Comment on attachment 409111 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=409111&action=review Thanks Darin for r+ this patch. >> Source/WebCore/ChangeLog:14 >> + If an authetnicator supports ClientPin, it can set the uv bit in the responses to true but it > > typo: authenticator Fixed.
Jiewen Tan
Comment 12 2020-09-21 13:46:07 PDT
Created attachment 409315 [details] Patch for landing
EWS
Comment 13 2020-09-21 14:32:26 PDT
Committed r267369: <https://trac.webkit.org/changeset/267369> All reviewed patches have been landed. Closing bug and clearing flags on attachment 409315 [details].
Note You need to log in before you can comment on or make changes to this bug.