W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2022

Re: [webauthn] Provide request deserialization, response serialization (#1683)

From: Firstyear via GitHub <sysbot+gh@w3.org>
Date: Thu, 20 Jan 2022 03:12:48 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1017077432-1642648366-sysbot+gh@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.

As I'm reading this, you are expressing an opinion that WASM is a "demo" or a "toy" language, and not something you need to seriously consider in the surface area of webauthn and how it interacts with a browser. 

> 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?

I am extremely confused by what you are asking here, because I think you are confused about what I'm requesting. 

> 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)

Both of which would be "breaking" changes to what a browser provides, and are desperately needed both so that RP's no longer need JS/WASM to mangle incoming requests so that nav.cred can understand it, but also because a large number of parameters in Webauthn an unsigned which opens the door to a number of potential security issues which extensions poorly defend from. 

GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-1017077432 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 03:12:50 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:45 UTC