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

> > So long as it's consider how this will work in a WASM context for non-js languages, then this is supported by me.
> 
> Architecturally, 90+% of browser-hosted WASM has no need to interact with WebAuthn,

And 99% of all Javascript also has nothing to do with WebAuthn, and yet, here we are talking about how to make it accessible to use Webauthn from JS. 

>  as it is the server component of the architecture which is challenging and processing the registrations and assertions.
> 

I'm sorry, are you confused? The issue in this matter is that the types as defined by Webauthn are *not possible* to deserialise from JSON directly into JS/WASM in a manner that the platform API's can consume, currently forcing all RP implementors to fiddle with the content of the structures. 

So it doesn't matter if it's JS or WASM there is currently no way to take "JSON" and feed that to the navigator.credentials apis without messing with it.  

> Outside of ZKP experiments such as Cloudflare's and demo applications, WASM code would mostly act analogous to client-side form validation, processing and rejecting created credentials which did not meet the codified server policy. That said, in many cases you might not even gain significant performance benefits from WASM due to serialization and the lack of WebCrypto in WASM.

As the author of Webauthn-RS, who implemented the demo site and examples for all client side browser elements in WASM and NOT Javascript, I'd like to disagree. There is also a huge and growing interest in WASM for client side elements in replacement of JS.

As such, WASM is an important use case to consider. 




-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-1015843116 using your GitHub account


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

Received on Tuesday, 18 January 2022 21:19:46 UTC