- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Jun 2021 04:03:48 +0000
- To: public-webauthn@w3.org
Firstyear has just created a new issue for https://github.com/w3c/webauthn: == Base64 of fields to simplify javascript/json behaviour == In the webauthn standard, a number of fields are defined as javascript structures that are sent to the navigator.credentials api's of the client. Some of these fields makes use of the type "BufferSource" which is a javascript Uint8Array. Notable examples are `PublicKeyCredentialCreationOptions.challenge`, `PublicKeyCredentialUserEntity.id`. While these may be javascript types, they are not themself able to convert directly from json to javascript - these actually on deserialisation from json create an array type that is not suitable for use where a uint8array is used. This has led to a number of implementations having to "work around this". The common workaround is the use of base64 (of various formats ...) such as on oktas sign in page, https://webauthn.io/ and others. Many of these ship their own base64 implementations, as javascript has no method to natively decode from base64 to a uint8array. The primary concern is that this means that javascript for webauthn will likely be incompatible between backends and RP's, which could reduce the ability to share or adopt code. The other concern is that this necessitates that client javascript *must* alter the content of the request options in order to proceed in calling the navigator.credentials api. It adds a needless extra hurdle for implementors to jump through, and presents a silent and subtle trap. I would suggest that the standard be extended so that fields have an `encoded` form of DOMString available. This DOMString must contain base64url encoded data, that the navigator.credentials api would decode. If the `encoded` form is not present, then the previous id/challenge fields are inspected. ``` dictionary PublicKeyCredentialRequestOptions { DOMString encodedChallenge; BufferSource challenge; ... } ``` This would allow implementors of site specific javascript to more easily handle the options that are provided from the server, and removes the need to alter and modify their content. Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1619 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 June 2021 04:03:56 UTC