- From: philomathic_life via GitHub <sysbot+gh@w3.org>
- Date: Sat, 27 Jul 2024 15:20:26 +0000
- To: public-webauthn@w3.org
I hope this is not misconstrued as a "rant", but I think the real problem is the serialization algorithm itself. It is _far_ too strict. The fact this algorithm is technically required means many clients or user agents will likely _accidentally_ not conform to the spec since they likely use an _actual_ JSON library which will likely not guarantee the order of fields, not guarantee unnecessary whitespace is used, etc. The spec should be written such that clients and user agents have an easier time to conform to the spec and not a harder time so long as there is not a reduction in security. The existence of the serialization algorithm seems to violate two big goals of WebAuthn: consistency among RPs in order to mitigate risks related to a fragmented ecosystem that causes users to turn away from WebAuthn altogether and the spec as a _web_ standard. Personally, I'm sympathetic to libraries that don't kowtow to non-conforming clients/usage; and as an RP writer, I find it hard to "forgive" these non-conforming clients. It is obvious that allowing any conforming JSON, even if it violates the spec, is not a "security issue"; but that creates a slippery slope. While Postel's law is still common, this can cause issues if one is not careful. The purpose of a spec should be to state what is necessary and not rely on implementors to use their best judgment when the spec can, and in this case seemingly _should_, be violated. The existence of the serialization algorithm and the related limited verification algorithm is a not-so-subtle way to help non-web platforms—as confirmed by @agl himself above. When questions come up about native applications and other non-web platforms, the usual (and appropriate) response is something to the effect of "WebAuthn is only a web standard, so concerns with native applications are not applicable"; yet here we have a _required_ algorithm that is designed for non-web platforms. Ideally the solution would be to state that clients/user agents can send any payload that conforms to [RFC 8259](https://www.rfc-editor.org/rfc/rfc8259) (or whatever formal standard you wish to cite), and they MAY optionally begin the payload with U+FEFF. Then at most a commentary note stating that they SHOULD conform to the serialization algorithm. With above, an RP writer cannot claim to be "WebAuthn-conforming" since conforming clients/user agents are allowed to send any JSON (and optional BOM). Until then, the spec should at least be consistent and ensure the required serialization algorithm and the limited verification algorithm align with other areas of the standard that state BOM stripping MUST occur; because as of now, it's a bizarre requirement to allow payloads that strictly speaking are not possible. -- GitHub Notification of comment by zacknewman Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2107#issuecomment-2254177169 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 27 July 2024 15:20:27 UTC