Re: [webauthn] Add "sign" extension (#2078)

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 store backend for remote CryptoKeys. However, remote CryptoKeys doesn't address all the concerns that informed the design of the "sign" extension:

- **Origin-bound keys.** The "sign" extension inherits the origin binding from WebAuthn. Remote CryptoKeys recommends, but does not require, that keys be scoped to a particular web origin.
- **Fixed key capabilities.** To prevent downgrade-style attacks, the "sign" extension fixes the capabilities of keys (specifically: whether the key requires UP/UV) at creation time. Remote CryptoKeys recommends, but does not require, some unspecified access control, and `getRemoteKey()` presumably allows accessing the same key with different `keyUsages` arguments. Perhaps individual key store implementations could forbid this, but that's a very weak promise for the API as a whole in that case. Especially without...
- **Attestation.** This is the really big one - support for hardware attestation will be required if the API is to be used for things like (inter)national digital identity wallets. The "sign" extension supports this in much the same way as the top-level WebAuthn attestation, and the attestation signs over the fixed key capabilities described above. The Web Crypto API is not well equipped to convey hardware attestation information to the RP, and this is also missing from the current Remote CryptoKeys proposal.
- **Interoperability**. The "sign" extension defines an explicit interop protocol (on top of CTAP) between client and authenticator, so there's a concrete path for authenticator vendors to implement these features and have them work in any browser that supports the extension. Remote CryptoKeys only vaguely suggests that "[the key store] may be a secure key store, password manager, USB or BlueTooth device, etc." but makes no attempt to define an interface for it, let alone require some minimal interop profile, so compatibility is certain to differ between browsers. This might even be one of the [Non-Goals](https://github.com/WebKit/explainers/tree/main/remote-cryptokeys#non-goals), depending on how you read that section?

I do agree that WebCrypto is in some ways a more appropriate home for these features. But on the other hand, one powerful benefit of doing this in WebAuthn instead, with algorithm identifiers etc. sent to and interpreted only by the authenticator, is that authenticators can introduce support for new algorithms without the client explicitly supporting it. For example, we want to be able to create signatures using a key derived by [ARKG](https://yubico.github.io/arkg-rfc/draft-bradleylundberg-cfrg-arkg.html) - in the "sign" extension this only needs a new `alg` value understood by both the RP and the authenticator, no change to the client is needed. Same goes if we want to, say, use different elliptic curves or introduce PQC algorithms. With WebCrypto, all these things would need standardizing new `AlgorithmIdentifier` values/subtypes and waiting for all relevant browsers to implement them.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2078#issuecomment-2165507426 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 June 2024 12:24:44 UTC