Tim Bray writes: > The chance of the JOSE working group moving the vast world of > deployed JSON infrastructure round to 0.00. Thus putting a MUST > reject in here would essentially say you can’t use well-debugged > production software, and would be a really bad idea.
And are none of those jose parsers open source? If any of them is open source, then someone who wants to use jose, could take one, fix it to reject duplicates, and use that still well-debugged production software, with small patch, and he just need to add regression test case for the new patch, and rerun the normal regression tests to know everything else still works. If all of them are closed source software which you cannot patch, then it might be better that people write proper open source parser which actually tries to be secure. > On the other hand, if JOSE specified that producers’ messages MUST > conform to I-JSON, and a couple other WGs climbed on that bandwagon, > and the word started to get around, I wouldn’t be surprised if a few > of the popular JSON implementations added an I-JSON mode. That > would be a good thing and lessen the attack surface of all > JSON-based protocols (which these days, is a whole lot of them). And if we say MUST reject structures with duplicate keys, that would perhaps force them even more, especially as those vendors really wanting to be conformant would start asking that. On the other hand, I think most of the vendors would just issue request for the fix, but still continue using the relaxed parser, regardless what we write in the specification here. At least if we say MUST then they hopefully will put the feature request in. If we say SHOULD, they will not... -- [email protected] _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
