W3C home > Mailing lists > Public > public-webauthn@w3.org > November 2021

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

From: Matthew Miller via GitHub <sysbot+gh@w3.org>
Date: Mon, 15 Nov 2021 23:50:30 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-969451914-1637020228-sysbot+gh@w3.org>
Thank you for submitting this ticket, I had intended to file something similar ages ago but never managed to make time for it. In my mind I totally think `PublicKeyCredential` needs to be expanded in this direction.

I encourage us to think about how devs work with native JS capabilities and build the spec _for_ them, not build the spec for us and hope JS devs will follow. To get some of my own thoughts out about this:

- In my mind base64url would be the preferable encoding/decoding scheme because it's [specifically called out as a dependency](https://www.w3.org/TR/webauthn-2/#sctn-dependencies).
- I think making it easier for developers to consume WebAuthn API via JSON inputs and outputs would go a long way in encouraging adoption without forcing developers to A) figure out WebAuthn serialization for themselves, or B) incorporate _another_ dependency like Github's [webauthn-json](https://github.com/github/webauthn-json) or my [@simplewebauthn/browser](https://github.com/MasterKale/SimpleWebAuthn).
- I'd argue JSON over CBOR as the former is the lowest-common denominator data schema, especially in the world of advanced JavaScript projects like Single-Page Applications. JSON can be natively worked with without needing to incorporate any dependencies, and without having numbers handy I'd say almost all front end JS projects make JSON-based REST or GraphQL API calls. This means most JS devs are comfortable thinking about data structures purely as JSON, and have no idea what CBOR-encoding is nor would see the benefits in it when JSON has "worked so well" for them. Not to mention CBOR encoding/decoding would require their own dependencies, so you'd be trading one kind of dependency for another; definitely "one step forward, one step back".

Whatever direction an effort like this takes, I think the end goal should be to make WebAuthn easier for developers to consume, especially in the browser side of things. If we can accomplish that then adoption will follow. Right now WebAuthn is a PITA to implement in large part because `ArrayBuffer`'s just aren't common in front end JS development. Not to mention there's a lack of native methods to convert to/from Base64URL in the browser which further complicates things when the spec seemingly assumes such "standard library" APIs are available (😂/😭) I think we can tackle this with a smart addition to `PublicKeyCredential` so long as we keep an eye on how we can make WebAuthn more practical to consume.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 15 November 2021 23:50:32 UTC

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