- From: Eric Stern via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Oct 2024 17:10:58 +0000
- To: public-webauthn@w3.org
> Is it "obvious" that the client should not send this data seeing how if the server had this info it's now at best devolved into a shared secret? From my eyes, it is not - though I'll readily admit that's more due to unfamiliarity with the use-cases than going through the actual spec. While it's out of scope on _this_ PR to add more info about use-cases, I think it would be a worthwhile addition to the spec to go into more details there. [MasterKale's gist](https://gist.github.com/MasterKale/dbe39a01438251f0cbd55576304731fd) provides a bit more context, but I think more detail about what party manages and/or retains what data would go a long way towards keeping implementations on the successful path. 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. > That's where I am leaning too: a brief cautionary note that mentions one may want to omit this information when sending getClientExtensionResults or toJSON to the server when the server should not have this sensitive data. 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. -- GitHub Notification of comment by Firehed Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2174#issuecomment-2394175267 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:10:59 UTC