Bug 232501 – Authenticator is not falling back to clientPIN after internal verification fails and is blocked.

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

[login Llama]

Thanks for fixing https://bugs.webkit.org/show_bug.cgi?id=213903

I tested that it works on OSX STP 134.

However in testing I discovered that Safari is not detecting that internal UV is blocked and falling back to getPinToken (CTAP2.0) or getPinUvAuthTokenUsingUvWithPermissions (CTAP2.1).

Safari should fall back when it receives the CTAP2.0CTAP2_ERR_PIN_REQUIRED error and/or when the CTAP2.1 uvRetries <= 0.

That is the current behavior of Chrome and Windows.  

I grant you that the CTAP2.0 spec is less clear on this point than one might hope.

CTAP2.1 https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html is clearer on how platforms should fall back to clientPin for CTAP2.0 authenticators than the CTAP2.0 spec was.

Regards

[Radar WebKit Bug Importer]

<rdar://problem/84913636>

[login Llama]

For Fido members this is the relevant issue on clarifying the platform actions section of the CTAP 2.1 specification on pin fallback. 
https://github.com/fido-alliance/fido-2-specs/issues/1303

[[e-mail]]

Created attachment 447649 [details]
Patch

[[e-mail]]

Created attachment 447650 [details]
Patch

[[e-mail]]

Created attachment 447651 [details]
Patch

[EWS]

Committed r287315 (245467@main): <https://commits.webkit.org/245467@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 447651 [details].

[login Llama]

I don't see this change in STP 137 yet.  

Let me know when I can retest.

Thanks

[login Llama]

Change tested and working in STP 140

Thanks