- From: philomathic_life via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Oct 2024 17:44:38 +0000
- To: public-webauthn@w3.org
> When it comes to cryptography, and especially handling of key material (or inputs to derive it), I'd recommend erring strongly on the side of overly-explicit. I agree especially since it would be a quick remark. > It may be too late to materially change the mechanics, but if this is the case, it seems to me that the sensitive data should have a different access path that's outside of those APIs. In particular, `toJSON` is really intended to dump the whole thing to the server for processing (or, at least, that's how I plan on using it once there's enough browser support); default-including data in there that should not leave the client is asking for problematic implementations. A harsh rebuttal would be that any RP that "accidentally" sends sensitive data is likely not qualified to do whatever it is they are trying to do (e.g., password manager). If/when I implement my own passkey-only password manager; then on the client, I would use `toJSON` and then remove the data I don't want (e.g., `prf`) to send. I think there are other reasons one may want to remove certain data from `toJSON` anyway. For example I would personally remove all superfluous data (e.g., `id` and `rawId` from `RegistrationResponseJSON` and `publicKey`, `publicKeyAlgorithm`, and `authenticatorData` from `AuthenticatorAttestationResponseJSON`) since that puts more work on the server to perform inter-data matching for those that are already parsing the `attestationObject` which already contains all of that info. -- GitHub Notification of comment by zacknewman Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2174#issuecomment-2394264852 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 4 October 2024 17:44:39 UTC