[Webkit-unassigned] [Bug 253975] New: WebAuthn authentication includes security key as option when only "hybrid" is the potentially usable transport

Wed Mar 15 11:36:29 PDT 2023

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

            Bug ID: 253975
           Summary: WebAuthn authentication includes security key as
                    option when only "hybrid" is the potentially usable
                    transport
           Product: WebKit
           Version: Safari 16
          Hardware: Mac (Apple Silicon)
                OS: macOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: matthew at millerti.me

## Context

Safari's WebAuthn prompt behavior seems odd when credential transports are provided for a single entry in `allowCredentials`, and "hybrid" is the only potentially usable transport.

For example, consider the case of a single passkey with ["internal", "hybrid"] for transports. The passkey is not recognized by the local platform authenticator over "internal" transport, so Safari asks the user to choose between the following two options:

- iPhone, iPad, or Android device
- Security key

Why is "Security key" an option here, if the transports indicate that the passkey is only usable locally or from a mobile device's platform authenticator? It seems Safari should instead jump straight to the hybrid QR code display, because the RP hasn't communicated in any meaningful way that the user might be able to successfully use a security key.

Additionally, in the somewhat contrite case of only ["hybrid"] for transports, Safari skips any choice and goes straight to the "Use Security key" prompt! This doesn't make any sense as "hybrid" isn't a security key-related transport. Here too Safari should display the hybrid QR code for authenticating with a mobile device.

## Environment

- Safari 16.3
- macOS Ventura 13.2.1

## Reproduction

This basic HTML document demonstrates both scenarios listed above in a practical manner:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <style>
    body {
      max-width: 40em;
    }
  </style>
  <title>Safari Bug - Security key as option for ["internal", "hybrid"]</title>
</head>
<body>
  <h1>
    Safari Bug - Security key as option for ["internal", "hybrid"]
  </h1>
  <p>
    Demonstrating how Safari shows security keys as an option when the only allowed credential
    has ["internal", "hybrid"] as transports. Why would the browser think this is a security key?
    What if Safari simply skipped to the hybrid QR code when it doesn't recognize the credential as
    "internal"?
  </p>
  <button id="auth1">Authenticate w/['internal', 'hybrid']</button>
  <p>
    And to really emphasize how weird this is, Safari only shows security key as an option when only
    ["hybrid"] is set as transports for the sole entry in allowCredentials. Feels like Safari should
    skip to the hybrid QR code here too.
  </p>
  <button id="auth2">Authenticate w/['hybrid']</button>
  <script>
    // button#auth1
    document.getElementById('auth1').addEventListener('click', () => {
      navigator.credentials.get({
        publicKey: {
          challenge: new Uint8Array([1,2,3,4]),
          allowCredentials: [
            { id: new Uint8Array([1]), type: 'public-key', transports: ['internal', 'hybrid'] },
          ]
        },
      }).then(console.log);
    });

    // button#auth2
    document.getElementById('auth2').addEventListener('click', () => {
      navigator.credentials.get({
        publicKey: {
          challenge: new Uint8Array([1,2,3,4]),
          allowCredentials: [
            { id: new Uint8Array([1]), type: 'public-key', transports: ['hybrid'] },
          ]
        },
      }).then(console.log);
    });
  </script>
</body>
</html>
```

-- 
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/20230315/3689789c/attachment-0001.htm>