Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]