- From: Martin Kreichgauer via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Dec 2021 19:44:57 +0000
- To: public-webauthn@w3.org
> This is meant for the server, and the server already needs to work with WebAuthn binary formats as well as CBOR to handle the assertions, to handle attestations and to handle extensions (such as the mandated credProtect by some clients) IIRC, we specifically added getAuthenticatorData() because sites were asking us for ways to use basic WebAuthn (i.e. w/o attestation, extensions, etc) without needing to introduce a CBOR dependency. On the flip side, I suspect the vast majority of sites already understand how to pass JSON between a client and a server. So I think JSON is a more natural fit for the web, even if some RPs also have a CBOR dependency already. > additional ArrayBuffer values represented as base64 encoded properties might not be understood as string vs binary properly if a request is sent to a client which does not support it. I think the way this would work is that when browsers add a new WebAuthn feature that is accessed via a field in PublicKeyCredentialCreation/RequestOptions, they would also add deserialization support to the fromJSON method() (whether it's ArrayBuffer-valued or not). Any unsupported fields would simply be ignored. > I cannot speak to how this knowledge might complicate environments where the browser and platform have an API between them. At least in Chrome, we would implement this feature in the browser. There's no need to rely on platform APIs. -- GitHub Notification of comment by kreichgauer Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-984946650 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 December 2021 19:44:59 UTC