- From: philomathic_life via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Jul 2024 18:00:13 +0000
- To: public-webauthn@w3.org
> Obviously there's a tension around how "limited" the limited algorithm is. If it keeps gaining things it'll be no better than writing a small JSON parser! It's a _long_ ways off from that point. My implementation is around 125 lines of code after the removal of comments. Obviously it's _technically_ unbounded in its growth, but I'll cross that bridge when it comes. If things are added at the current rate, I'll likely long be dead by the point my implementation is even close to the length and complexity of a "small JSON parser". > The original motivation for it was that OpenSSH would not accept a JSON parser in their code, and I had sufficient sympathy for that to propose that we constrain the format of the client data accordingly. If this were proposed as a PR, I wouldn't have strong feelings either way, but I do worry in general that the limited form wasn't really intended for normal Web usage, and I'm not sure that we want to adopt a norm that we keep extending the algorithm to cover everything. Understand. The serialization algorithm is quite strict (e.g., the order of fields is dictated, unnecessary whitespace is forbidden, even what strings are allowed to be Unicode-escaped is reduced to the first 32 Unicode scalar values unlike JSON where all Unicode scalar values are allowed to be escaped using their Unicode code point), so I thought the idea was that the serialization algorithm and limited verification algorithm were effectively inverses of one another. If the serialization algorithm were much looser, then I would understand how the two algorithms are quite distinct; and updating the serialization algorithm wouldn't necessitate updating the limited verification algorithm. > Could you expand on why your case both seems to be web-based, yet wants to use the limited algorithm? Is it that you look at results [like this](https://seriot.ch/projects/parsing_json.html#41) and feel that JSON is insufficiently rigorously defined for such usages? If so, I think the saving grace here is that the signature tells you, before parsing, that the JSON is as originally generated and, if the generator (i.e. browser) is trying to mess with you, you've already lost. My RP library is designed to be small so that it can be used by other libraries and applications including but not limited to an SSH implementation, native applications, etc. This means while I love libraries like [`serde_json`](https://docs.rs/serde_json/latest/serde_json/), I simply don't need or desire such a large dependency. -- GitHub Notification of comment by zacknewman Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2102#issuecomment-2243515723 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 22 July 2024 18:00:15 UTC