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

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

From: David Waite via GitHub <sysbot+gh@w3.org>
Date: Tue, 16 Nov 2021 00:11:11 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-969477419-1637021469-sysbot+gh@w3.org>
> * 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).

That would be my preference.

> * 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".

We have a lot of values which would be named base64url property values at that point, e.g.
- numerous identifiers
- the challenge
- the client JSON (since it has to be byte-for-byte preserved)
- the actual signed data
- all extension requests and responses (which you are pretty much guaranteed to need to handle due to some clients injecting Credential Properties)

My reasoning for CBOR over JSON:

Because JSON cannot differentiate text from base64url-encoded binary, the selection of JSON would require a semantic knowledge of the message (including future additions) in order to process. This increases the maintenance of such serialization and deserialization.

The selection of JSON may also push for duplication of non-encoded forms, for example including what today is getPublicKey() as a duplicated JWK within the serialized JSON response. This particular example duplication of security information and increases the risk of an implementation accidentally relying on data which is not integrity protected.

I don't feel additional forms of data are necessary. For browser Javascript, we do not need a JSON form to introspect because we have the actual WebAuthn API. For things which a browser needs to understand, we should still focus on raising that information through the API, rather than through serialized forms.

For the relying party infrastructure processing the data however, we necessitate binary processing already by the nature of the protocols being written in terms of U2F-legacy binary and CBOR binary messages. Semantic transformation to other forms breaks integrity. Base64 encoding binary data does not make the relying party job easier.

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

Agreed. While a serialized form does not create any mandate, one could see how what is client javascript libraries today might get pared down to either send the serialized form in request/responses directly, or composed within additional API messages which provide something like an authentication workflow.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 16 November 2021 00:11:13 UTC

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