- From: David Waite via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Jan 2022 02:57:41 +0000
- To: public-webauthn@w3.org
> What is there that needs elaborating? Instead of using JS, you use WASM. As a result, and changes to make it easier to get from JSON -> navigator.credentials.get/create need to work in a WASM context. What would WASM do with the data in this context, e.g. specifically within a browser under the local user's control, other than create a demo app which provides no access into remote systems? The goal is to provide API useful for production systems, not necessarily demonstrations or experimentation. That said, I'm trying to make sure there are not concrete features which would be missed toward that goal. An example I proposed here was having logic analogous to local form validation. Examples there would be that the credential returned only contains known extensions, or that a created credential has a properly rooted attestation. The purpose of proposing serialization and deserialization here is specifically that the browser presentation has so little that it _can_ do with WebAuthn. The challenges and assertions are made between the back-end infrastructure and the authenticator. > Yes, I have previously described these here #1619 From that earlier issue, I surmise your goal is encompassed as the one stated here then; we wish to provide methods to go in between some serialization needed by the server and the requests/responses exposed by the API, in order to eliminate the hard requirement for clients and servers to individually define their own implementation-specific approach for that. You asked for considerations of how it would work in WASM for non-js languages - is there an example of a serialization of the data which would be sufficient for server usage but which would be insufficient for local WASM processing you had in mind? My suspicion is that there will be more discussion on whether the response serialization should be of integrity-protected binary data and client supplemental data only. The alternative would be having the duplication we currently expose in the API responses, such as returning an additional copy of the public key on credential creation in a more commonly understood format (conditionally, when no attestation was requested) -- GitHub Notification of comment by dwaite Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-1017070693 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 20 January 2022 02:57:43 UTC