Bug 224042 – [Webauthn] navigator.credentials.create, with direct attestation, throws 'NotAllowedError.' error on MacOS11 M1 Chip

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

[SG]

navigator.credentials.create throws 'NotAllowedError: This request has been cancelled by the user.' error when "direct" attestation is requested on MacOS Big Sur, Safari 14 browser 

Request
navigator.credentials.create({publicKey: {
    "rp": {
        "id": "",
        "name": ""
    },
    "user": {
        "name": "",
        "displayName": "",
        "id": 
    },
    "challenge":
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        }
    ],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform"      
    },
    "attestation": "direct"
}})

Response 
NotAllowedError: This request has been cancelled by the user.

[Radar WebKit Bug Importer]

<rdar://problem/76390431>

[Cyril Labbe]

Created attachment 433873 [details]
error popup on webauthn.me

[Cyril Labbe]

Created attachment 433874 [details]
mac os & chipset reference

[Cyril Labbe]

issue also reported on the fido-dev google group
https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/BHYtIkLTZbM

happens when attestation is "direct" or "indirect", not when "none"
happens on MacBook Pro M1 (no issue on intel MacBook)

the attestation ceremony proceed normally regarding the user (allows the domain to perform webauthn then use touchid), but ends up on an error popup

[[e-mail]]

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

[Dirkjan Bussink]

I'm also hitting this issue on trying to register with TouchID with Okta.

It reproduces as well on https://webauthn.me/debugger when registering with the attestation set to "direct" or "indirect". It works when it's set to "none".

[login Llama]

With attestation Direct

On Intel Safari 15.4 I get a not allowed error when Syncing platform authenticator is disabled.
When Syncing platform authenticator is enabled it works as expected.  

On M1 Safari 15.2 and STP 140 I get "The operation cannot be completed" if Syncing platform authenticator is enabled or disabled.

The expected behavior is that the browser should return an attestation of type none if the authenticator doesn't support attestation.  

 There is a WebAuthn issue to track this https://github.com/w3c/webauthn/issues/1697

It is possible that WebAuthn Level 3 will need to be updated to be more explicit on this so that platforms are consistent.

[[e-mail]]

Hi, thank you for this report. We have identified the cause of this bug and a fix will be included in a future release.

You can test attestation on M1 now by installing both the public beta of macOS 12.3 and Safari Technical Preview 139.

[Dirkjan Bussink]

I don't think this issue is fixed. I just tried on an M1 with 12.3 and the problem still exists and I can't register with any attestation configured.

[Dirkjan Bussink]

Also tested on a non M1 Mac with 12.3 and it errors out now also there, so I think it's been a regression on all platforms?

I see now a "NotAllowedError: This request has been cancelled by the user." when trying to register on https://webauthn.me/debugger

[login Llama]

An M1 with STP 141 on OSX 12.3 gives me "The operation cannot be completed" if attestation is direct for the platform authenticator.

[Hidehito Gomi]

I don't think this is fixed. There seems to be a regression on non-M1 (Intel) chip.
I tested on an Intel Core i7 Macbook Pro (macOS Monterey 12.3) with Safari 15.4 and Safari Technology Preview 141, using TouchID.

navigator.credentials.create in each case threw 'NotAllowedError: This request has been cancelled by the user.' error when "direct" or "indirect" attestation for "platform" authenticator was requested.

[[e-mail]]

The fix for this issue is available in today's macOS Monterey‌‌‌ 12.3‌‌.1 update.

[Dirkjan Bussink]

Can confirm that this is now fixed in 12.3.1 on both an M1 Mac and an Intel Mac.