iPhone + Safari + Passwords violates WebAuthn spec when pubKeyCredParams doesn't contain ES256

WebAuthn Level 3 § 6.3.2 Step 2 states the authenticator must :

Check if at least one of the specified combinations of PublicKeyCredentialType and cryptographic parameters in credTypesAndPubKeyAlgs is supported. If not, return an error code equivalent to "NotSupportedError" and terminate the operation.

On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and an ES256 credential is created when an RP passes a non-empty sequence that does not contain {"type":"public-key","alg":-7} (e.g., [{"type":"public-key","alg":-8}]).

When I use Chromium 138.0.7204.92 on my laptop running Arch Linux in conjunction with the Passwords app (connected via the "hybrid" protocol), a credential is not created and instead an error is reported per the spec.

Seeing how Chromium on laptop + Passwords works correctly, I'm inclined to believe the issue lies with Safari (at least on iOS). If I had to "guess" what is happening, it is that Safari automatically adds ES256 when it does not exist (and possibly removes the supplied algorithms). This violates the spec though. WebAuthn Level 3 § 5.1.3 Step 10 states the steps a user agent MUST follow:

If pkOptions.pubKeyCredParams’s size is

is zero:

Append the following pairs of PublicKeyCredentialType and COSEAlgorithmIdentifier values to credTypesAndPubKeyAlgs:

  • public-key and -7 ("ES256").
  • public-key and -257 ("RS256").

is non-zero

For each current of pkOptions.pubKeyCredParams:

  1. If current.type does not contain a PublicKeyCredentialType supported by this implementation, then continue.
  2. Let alg be current.alg.
  3. Append the pair of current.type and alg to credTypesAndPubKeyAlgs.

If credTypesAndPubKeyAlgs is empty, throw a "NotSupportedError" DOMException.

In particular when an RP does supply a list of algorithms, the user agent is not permitted to add its own algorithms nor remove any of the supplied algorithms (assuming the PublicKeyCredentialType is supported (e.g., "public-key")).

Our engineering teams will need to investigate this issue.

We'd greatly appreciate it if you could open a bug report, include crash logs and sample code or models that reproduce the issue, and post the FB number here once you do. http://feedbackassistant.apple.com

Bug Reporting: How and Why? has tips on creating a successful bug report.

As requested, a bug report was raised using Feedback Assistant. The number is 18838512. Here is the link.

iPhone + Safari + Passwords violates WebAuthn spec when pubKeyCredParams doesn't contain ES256
 
 
Q