Emil Lundberg

Related: - https://github.com/w3c/webauthn/issues/1688 - https://github.com/w3c/webauthn/issues/1750 - https://github.com/w3c/webauthn/issues/1714

Good observation, thanks! (I first re-tagged this as editorial but then reverted that, because [WebIDL dictionaries](https://webidl.spec.whatwg.org/#idl-dictionaries) are in fact defined to be ordered)

(As pointed out in #2083, the order of WebIDL dictionary members is lexicographical order, not source definition order, so this actually is an editorial change since the WebIDL definitions are...

From 2025-04-11 face-to-face WG meeting: - It's unclear what clients would do differently for different `language` values, especially considering these values (`user.name` and `user.displayName`) are likely chosen by the user...

Closing in favour of #2308, per https://github.com/w3c/webauthn/issues/1643#issuecomment-2985299304.

Even though `credentialRecord/authenticatorDisplayName` was added in #1880 along with `credProps.authenticatorDisplayName`, we should still recommend RPs to provide some way for users to set a "nickname" for their credentials, even if...

Yes, this seems like a duplicate of #1823. For the payment use case specifically, there is [Secure Payment Confirmation](https://www.w3.org/TR/secure-payment-confirmation/) which is an alternate API building on top of WebAuthn.

Thanks, I was not aware of that. There is some overlap, and it should be fairly straightforward to make the CTAP layer of this "sign" extension compatible as a key...

> it would be great to prevent the keys from being exposed to Javascript for instance Indeed, this is precisely the goal of this extension. > Also support for different...

Thank you @selfissued! > Where are we on implementations? Only barely started, I'm afraid. We (Yubico) have some rough internal proof-of-concept prototypes (of all three of authenticator, client and RP),...