Bug 213903 – [WebAuthn] authenticators supporting internal uv and pinToken defaulting to client pin

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[login Llama]

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.

[login Llama]

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.

[Jiewen Tan]

Will be a nice improvement.

[Jiewen Tan]

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

[Jiewen Tan]

<rdar://problem/65359269>

[login Llama]

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.

[Jiewen Tan]

(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?

[login Llama]

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.

[login Llama]

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.

[[e-mail]]

Created attachment 439105 [details]
Patch

[Brent Fulgham]

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.

[[e-mail]]

Created attachment 439503 [details]
Patch

[[e-mail]]

Created attachment 439768 [details]
Patch

[EWS]

[e-mail] does not have committer permissions according to https://raw.githubusercontent.com/WebKit/WebKit/main/metadata/contributors.json.

Rejecting attachment 439768 [details] from commit queue.

[[e-mail]]

Created attachment 440093 [details]
Patch for landing

[[e-mail]]

Created attachment 440095 [details]
Patch for landing

[EWS]

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].