Bug 213903 - [WebAuthn] authenticators supporting internal uv and pinToken defaulting to client pin
Summary: [WebAuthn] authenticators supporting internal uv and pinToken defaulting to ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: Safari Technology Preview
Hardware: iPhone / iPad Other
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 214076 (view as bug list)
Depends on:
Blocks: 181943
  Show dependency treegraph
 
Reported: 2020-07-02 15:33 PDT by login Llama
Modified: 2021-10-04 14:47 PDT (History)
7 users (show)

See Also:


Attachments
Patch (24.24 KB, patch)
2021-09-23 16:28 PDT, j_pascoe@apple.com
no flags Details | Formatted Diff | Diff
Patch (29.13 KB, patch)
2021-09-28 12:04 PDT, j_pascoe@apple.com
no flags Details | Formatted Diff | Diff
Patch (24.45 KB, patch)
2021-09-30 12:15 PDT, j_pascoe@apple.com
no flags Details | Formatted Diff | Diff
Patch for landing (28 bytes, patch)
2021-10-04 13:07 PDT, j_pascoe@apple.com
no flags Details | Formatted Diff | Diff
Patch for landing (24.38 KB, patch)
2021-10-04 13:11 PDT, j_pascoe@apple.com
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description login Llama 2020-07-02 15:33:12 PDT
In CTAP2 the pinToken is required for doing credential management and bio enrollment.
It also provides a fallback if fingerprint or face is not matching.
Comment 1 login Llama 2020-07-02 15:58:12 PDT
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.
Comment 2 Jiewen Tan 2020-07-28 01:03:53 PDT
Will be a nice improvement.
Comment 3 Jiewen Tan 2020-07-28 01:07:46 PDT
*** Bug 214076 has been marked as a duplicate of this bug. ***
Comment 4 Jiewen Tan 2020-07-28 01:10:19 PDT
<rdar://problem/65359269>
Comment 5 login Llama 2020-08-25 19:38:29 PDT
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.
Comment 6 Jiewen Tan 2020-09-18 17:11:19 PDT
(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?
Comment 7 login Llama 2021-01-07 05:56:56 PST
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.
Comment 8 login Llama 2021-09-10 13:02:04 PDT
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.
Comment 9 j_pascoe@apple.com 2021-09-23 16:28:47 PDT
Created attachment 439105 [details]
Patch
Comment 10 Brent Fulgham 2021-09-28 09:43:36 PDT
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.
Comment 11 j_pascoe@apple.com 2021-09-28 12:04:02 PDT
Created attachment 439503 [details]
Patch
Comment 12 j_pascoe@apple.com 2021-09-30 12:15:37 PDT
Created attachment 439768 [details]
Patch
Comment 13 EWS 2021-10-04 10:04:23 PDT
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.
Comment 14 j_pascoe@apple.com 2021-10-04 13:07:31 PDT
Created attachment 440093 [details]
Patch for landing
Comment 15 j_pascoe@apple.com 2021-10-04 13:11:20 PDT
Created attachment 440095 [details]
Patch for landing
Comment 16 EWS 2021-10-04 14:47:49 PDT
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].