Bug 213903

iOS 14 performs client PIN authentication with any authenticator advertising clientPin= True in authenticatorGetInfo. Most authentication that support internal uv also support pinToken. For authentication that have both clientPin=True and uv=true in CTAP2.0 (Logic changes in CTAP2.1) if uv is required, the platform should first do authenticatorGetCredential with the uv option set to 1. The authenticator will return an assertion or an error. CTAP2_ERR_OPERATION_DENIED 0x27 returned if the authenticator doesn't want pin fallback. CTAP2_ERR_PIN_REQUIRED 0x35 returned if uv mismatch wanting a fallback to clientPin If the error is CTAP2_ERR_PIN_REQUIRED then the platform should then do: authenticatorClientPIN (0x06) getKeyAgreement authenticatorClientPIN (0x06) getPINToken Then retry authenticatorGetCredential with pinAuth.

Will be a nice improvement.

*** Bug 214076 has been marked as a duplicate of this bug. ***

<rdar://problem/65359269>

This is still a problem in Developer preview 5 and STP 112. Bio authenticators are working but with pin. Sending a uv option to the authenticator along with pinToken in CTAP2.0 and if internal uv is supported may cause unpredictable results. Some authenticators will attempt to do fingerprint as well as pin in this case. It is at best confusing to users.

(In reply to login Llama from comment #1) > iOS 14 performs client PIN authentication with any authenticator advertising > clientPin= True in authenticatorGetInfo. Most authentication that support > internal uv also support pinToken. > > For authentication that have both clientPin=True and uv=true in CTAP2.0 > (Logic changes in CTAP2.1) if uv is required, the platform should first do > authenticatorGetCredential with the uv option set to 1. > > The authenticator will return an assertion or an error. > CTAP2_ERR_OPERATION_DENIED 0x27 returned if the authenticator doesn't want > pin fallback. > CTAP2_ERR_PIN_REQUIRED 0x35 returned if uv mismatch wanting a fallback to > clientPin > > If the error is CTAP2_ERR_PIN_REQUIRED then the platform should then do: > authenticatorClientPIN (0x06) getKeyAgreement > authenticatorClientPIN (0x06) getPINToken > > Then retry authenticatorGetCredential with pinAuth. Couldn't find the exact text corresponding to the description here in the current CTAP 2.1 spec. @John, could you point me to it?

https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#sctn-getAssert-platf-actions A non normative platform actions section has been added to CTAP2.1 Specifically see 6.2.1. Platform Actions for authenticatorGetAssertion step 1.1.2 Covering everything the platform needs to do requires a book. I hope this section covers the major flow issues. It covers the main platform logic implemented in Chrome and Windows. Any mistakes or questions should go to the Fido2 TWG during the current public review.

This bug is still present in the latest STP. I just has a conversation with a major authenticator vendor who told me they are violating the CTAP specifications and dynamically hiding the availability of pinToken support to trick Safari into supporting biometrics on there devices. Having to implement workarounds like that to support Safari is disappointing.

Created attachment 439105 [details] Patch

Comment on attachment 439105 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=439105&action=review r=me, but please include the radar in your changeling. > Source/WebCore/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=213903 Please always include the radar: <rdar://problem/65359269> > Source/WebKit/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=213903 Ditto. > Tools/ChangeLog:4 > + https://bugs.webkit.org/show_bug.cgi?id=213903 Ditto.

Created attachment 439503 [details] Patch

Created attachment 439768 [details] Patch

j_pascoe@apple.com does not have committer permissions according to https://raw.githubusercontent.com/WebKit/WebKit/main/metadata/contributors.json. Rejecting attachment 439768 [details] from commit queue.

Created attachment 440093 [details] Patch for landing

Created attachment 440095 [details] Patch for landing

Committed r283515 (242483@main): <https://commits.webkit.org/242483@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 440095 [details].