- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Mar 2022 16:40:55 +0000
- To: public-webauthn@w3.org
I appreciate the frustration, and I invite you and everyone else to hurt our feelings as much as is needed to make the spec the best it can be. I agree with @Firstyear that if the spec fails to communicate clearly to its audience, that is primarily the fault of the spec. However, as a spec intended for wide interoperability we may need to prioritize impartial generality over concrete examples, or sacrifice brevity to avoid ambiguity, or on the flip side sacrifice detailed descriptions for conciseness. Where the spec is vague it is often intentional so as not to restrict implementations or use cases too much. I can't speak for every technical decision in the spec as I wasn't around for its early development, but I'll try to add some colour to some of your grievances: > * _outdated_: byte buffers containing CBOR structures, which in turn contain nested byte buffers which are a concatenation of flags, byte lengths and nested CBOR... shouldn't such things a relic of the last century?! WebAuthn is in large part designed to be compatible with the FIDO [CTAP protocol](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html), which uses CBOR for many things including signatures. I don't know why CBOR specifically was chosen for that, though. But as for the raw byte concatenations, again that is in part motivated by being [backwards compatible with U2F signatures](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-fido-u2f-sig-format-compat) so that millions of existing U2F tokens can be used with WebAuthn. I suppose this also largely precludes JWT/JWS as a "signature format", since we cannot change the way U2F tokens assemble the data to be signed. As an RP library implementer myself, though, I think CBOR does have some merits of its own. It's largely a binary analogue of JSON, which makes direct translation between the two somewhat straightforward apart from byte array values. For example, the Jackson library for Java supports both JSON and CBOR as (de)serialization backends using the same logical data structures. Similarly, the COSE key data structures are (mostly) direct analogues of JOSE which JWT/JWS builds on. The use of byte buffer types rather than, say, base64url-encoded strings in results was [understood to reflect W3C direction](https://github.com/w3c/webauthn/issues/1683#issuecomment-970360597) for JavaScript APIs. There is currently some movement towards some "JSON-ized" API in PR #1703, although nothing is quite certain yet. > * _messy_: there are many different attestation formats, with each its own way to be parsed, interpreted and validated... Isn't it kind of ironic for a "standard"?! Indeed attestation and its many nuances is probably the most complex part of the spec, and as @herrjemand also points out it's messy because the outside world is messy. But indeed most RPs won't actually need the guarantees that attestation can provide, so they don't really need to implement all that complexity. Hm, with that in mind... perhaps we should split [§7.1. Registering a New Credential](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-registering-a-new-credential) into two versions: a greatly simplified one for RPs that don't need attestation, and the current one for RPs that do. > * _complex_: it's fucking 165 pages long!!! It's huge, it's difficult to read, it's sometimes unclear, sometimes obscure... Who can even understand all that?! If it's any consolation, keep in mind that the spec has at least three audiences: RP implementers, client (browser) implementers, and authenticator implementers. For example, RP implementers don't need to read sections §5.1.3 - §5.1.7 as those are mostly about the internals of how browsers are to implement the operations. That is unfortunately less the case in L1 and L2, as there was little guidance about what various parameters actually mean to an RP outside of reading the implementation details of what clients are to do with them, but at least for [L3](https://w3c.github.io/webauthn/) we've [made an effort](https://github.com/w3c/webauthn/pull/1621) to be more clear about what the parameters mean from an RP perspective and what the client and authenticator will do with them. But of course there's always more we can do to be better. If you can point us to specific parts or concepts that are unclear, or hard to read or understand, we'll be happy to do our best to improve them. Just be prepared that not everything is a good fit to include in the spec itself - it is indeed already very long. Some things may fit better in external resources such as those @herrjemand mentioned. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1709#issuecomment-1076516177 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 March 2022 16:40:56 UTC