- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Jan 2020 12:14:33 +0000
- To: public-webauthn@w3.org
You might like GitHub's [webauthn-json](https://github.com/github/webauthn-json) library, which should alleviate some of your pains with the API.
---
>why does WebAuthn use CBOR encoding? [...] Couldn't this API simply return a JavaScript object, with the values ready to be sent back to the server?
The main reason is that the API is designed to work with dedicated authenticator hardware, which benefits from a compact binary representation. The client does in fact transform the binary response from the authenticator into a more ergonomic object format before returning it to the RP - but since some of the response is cryptographically signed, those signed parts (`authData`, `attStmt`, `clientDataJSON`, `sig`) have to remain in the exact binary format they were when signed. The authenticator data format is the way it is in large part to maintain compatibility with [U2F authenticators](https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-raw-message-formats.html#authentication-response-message-success).
There's been some [discussion about adding more web-friendly versions](https://github.com/w3c/webauthn/issues/557) of some of the data, but it was decided against in favour of reducing client complexity and data duplication.
>the use of Uint8Array/ArrayBuffer is a pain - can't it use base64 encoding?
I guess it could, but on the other hand `Uint8Array/ArrayBuffer` are native JavaScript types while base64 strings are not. I think there is value in minimizing the number of places where we need to specify which exact variant of base64 to use - we already have some divergence between base64Url (e.g., `CollectedClientData.challenge`) and classic base64 (e.g., `android-safetynet` attestation).
> the [Client Data `challenge` is base64 encoded](https://w3c.github.io/webauthn/#dictionary-client-data), but the [Credential Creation `challenge` is not](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-challenge)
The `CollectedClientData.challenge` is base64 encoded because it gets written into a JSON string to be signed by the authenticator. I agree the `PublicKeyCredential{Creation,Request}Options.challenge` will most likely come from a JSON object in the first place, but that is not the only possibility.
> As an aside, would the [non-JavaScript approach](https://github.com/w3c/webauthn/issues/1255) be able to skip most of this extra processing?
Perhaps, but please note that the discussion of a non-JavaScript approach is only hypothetical at this point - it's currently not on any roadmap.
---
By the way, your `base64_to_uint8array` function doesn't actually base64 decode the input string, so you're going to have mismatches when you compare the challenge from `clientDataJSON` with the original input challenge. Which of course supports your thesis that the API is difficult to use. But again, [webauthn-json](https://github.com/github/webauthn-json) should help.
--
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1362#issuecomment-575125247 using your GitHub account
Received on Thursday, 16 January 2020 12:14:35 UTC