[Webkit-unassigned] [Bug 219813] New: `navigator.credentials.get()` returns immediately with `NotAllowedError` if credential already registered.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 11 16:19:16 PST 2020


https://bugs.webkit.org/show_bug.cgi?id=219813

            Bug ID: 219813
           Summary: `navigator.credentials.get()` returns immediately with
                    `NotAllowedError` if credential already registered.
           Product: WebKit
           Version: Safari 14
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lgarron at chromium.org

Per the WebAuthn spec (https://w3c.github.io/webauthn/#sctn-op-make-cred , step 3), errors returned from `navigator.credentials.get()` correspond to the following

- `InvalidStateError`: the user consented to create a new credential, but there are no authenticators that match the `authenticatorSelection` but aren't in `excludeCredentials`.
- `NotAllowedError`: the user did not consent to create a new credential

The most obvious case for "did not consent to create a new credential" is if the user pressed "cancel". However, it seems Safari also does the same if trying to register a platform authenticator (Touch ID or Face ID) that is already registered.

While other browsers allow the user to interact with the prompt, e.g. Safari on macOS 11.0 Big Sur flashes `Do you want to allow "example.com"' to use Touch ID` (with the options "Don't allow" and "OK") but immediately replaces it with `You have already set up Touch ID for this website.` (with only the option "OK").

This makes it impossible to tell if the user intended to create a credential, and for the RP (website) to offer a more useful option based on `InvalidStateError`.

I don't know if this is a bug, but I wanted to make sure it was not an accident.
The user experience (with the flashing prompt) is not great, so I think there is room for some improvement, either in the browser, or in the website's reaction to the error. It's unclear to me if any of the bugs here cover this issue: https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&field0-0-1=component&field0-0-2=alias&field0-0-3=short_desc&field0-0-4=status_whiteboard&field0-0-5=content&list_id=6674120&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&type0-0-0=substring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0-0-4=substring&type0-0-5=matches&value0-0-0=webauthn&value0-0-1=webauthn&value0-0-2=webauthn&value0-0-3=webauthn&value0-0-4=webauthn&value0-0-5=%22webauthn%22

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201212/85c8a44b/attachment.htm>


More information about the webkit-unassigned mailing list