I was mostly trying to dig out what Tim was advocating. I make no claims to be a expert on JSON parsers. That most of them accept duplicate keys is a reflection of the current JSON specs.
As Tim stated in a later message most of them don't reject or report duplicate keys. He is proposing a new JSON profile I-JSON that changes that. Changing things that are currently in wide deployment in many environments will not be a overnight thing. It may be that in some environments ignoring duplicate keys may be seen by some (not me) as a feature. I think we all agree that producers must be prohibited from emitting JSON envelopes with duplicate keys. As Jim points out that won't stop bad people from doing it. The only real protection is if receivers check and reject. I agree that making it a MUST will encourage parsers behaviour to change more quickly. In the interim there are going to be a lot of non compliant implementations. My only concern is to get people to fix the parsers properly rather than JOSE libraries building there own, parsers from scratch that may not be well tested and have other issues. This did receive a lot of debate in the WG and the current wording was changed from MUST reject duplicate elements, based on feed back from the JSON community. This is not just a JWK issue, it also applies to JWE and JWS. I am open to changing it if there is support for it in the WG. John B. On Sep 16, 2014, at 5:02 AM, Tero Kivinen <[email protected]> wrote: > John Bradley writes: >> Are you recommending that: >> That receivers MUST reject JOSE objects with duplicate keys. >> >> This would require compliant implementations to write there own parsers >> (perhaps not a good idea), or wait for I-JSON parsers (perhaps sometime >> soonish) > > I do not understand this. Why would they need to write their own > parsers? I would expect they would require the existing parsers to be > fixed to reject objetcs with duplicate keys. If I understand correctly > that would already be allowed, as you said some implementations do > that, some return the last key. > > If we make it MUST reject JW* items with duplicate keys, that would > make changes to parsers high priority items for the users of the JW*, > thus that would most likely get those changes done quite soon. > > Of course there would still be some broken implementations allowing > broken JW* items to be parsed, but the only thing would been that > those implementations cannot claim to be complient with the RFC we are > publishing now. If they want to clam to be complient with RFC xxxx, > they would have to make sure their parser is also fixed... > > I mean how many lines of code it would be in the parser to reject the > object if there is duplicate keys? I would expect the change to be > quite small (in order of few to few tens of lines). > > If we do not mandate this now, then nothing is going to change. There > is no demand to the existing parsers to be fixed, which means they > will not get fixed, and we will be stuck with bad parsers forever... > > Ps. Following and participating this thread has been almost impossible > to me because some people write text inline without any indication > which is quoted text and which is original text. Only after going to > the secdir archives I noticed there are some color differences to > indicate quoted text, and on my text only screen session all that > information is lost... It would be nice to people actually do > something else than rely on some html-formatted colors to indidate > quoted text vs new text. > -- > [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
