Using 1Password does not work on demo

[phildenhoff]

Trying the demo at https://webauthn.passwordless.id/demos/basic.html, I found that using 1Password to save my passkey doesn't work. 1P will save the passkey, but the client can't unpack the response to send it to the server.

Here's a demo of what I mean:

Screen.Recording.2023-08-18.at.16.43.28-2.mp4

I found this out by using the webauthn client in my own project and confirmed it in the basic demo. In my project, I saw errors that getPublicKey() didn't exist. I believe that is optional, so it's not too surprising.

Do you have any suggestions on what can be done to support 1Password? I can look at making changes, but I don't know the Webauthn spec that well. I know your project is focused, so you may not want to support these kinds of authenticators at all.

Using both my browser and a remote authenticator (my phone) did work. It's just 1Password and it's weird responses that doesn't.

This the credential created by 1Password:

and the response:

the clientDataJSON:

{
    "type": "webauthn.create",
    "challenge": "5146a02d-2124-4c50-93af-d64a9ff8ce70",
    "origin": "<snip>"
}

[dagnelies]

Hi,

I saw errors that getPublicKey() didn't exist. I believe that is optional, so it's not too surprising.

Accroding to the specs:

User agents MUST be able to return a non-null value for getPublicKey() when the credential public key has a COSEAlgorithmIdentifier value of:

• -7 (ES256), where kty is 2 (with uncompressed points) and crv is 1 (P-256).
• -257 (RS256).
• -8 (EdDSA), where crv is 6 (Ed25519).

So opening a ticket for 1Password would be more suited, so that they become compliant to the specs.

That said, that 1Password implements providing the public key makes more sense rather than all developers having to work around the lack of this critical convenience function. Lastly, it would bloat this slim library with an additional undesired CBOR dependency.

The specs require it and all major browsers/platforms comply to it (the lagging behind Firefox recently implemented it, see #18) so I see no reason to bloat this lib. That said, I'd of course accept a PR for this feature if the CBOR dependency is loaded dynamically "on demand".