On 2014-01-07 10:47, Carsten Bormann wrote: > On 07 Jan 2014, at 10:31, Anders Rundgren <[email protected]> > wrote: > >>> That’s not JSON. >>> ("Parsing Restrictions:” "• The original property order must be preserved.”) >> It is a correct but [somewhat] restricted JSON syntax. > The syntax conformance is not the point. > > In my version of a “somewhat restricted JSON syntax", a double newline in > front of a string means that the string is a binary string in base64url > decoding. Fully conforming. And, I’m expecting all of your implementations > to heed this and automatically decode those binaries, of course. Oh, and > decode strings starting with \u003a as a symbol, while continuing to decode > strings starting with an unescaped colon as a string. > > That’s just not the way JSON works. > > If you need a special parser for a syntax, it’s no longer JSON.
I'm sorry Carsten but my brain doesn't parse what you are writing :-) The parser in question reads the JSON syntax as specified in the RFC. At least that was the goal. What's not described in the RFC is the way a JSON parser deal with the parsed data. It is clear that no other parser out there can be used to verify signatures based on JCS. If this makes the entire concept invalid that's a valid opinion, however it is not a fact. Backward compatibility at any cost is at least not my recipe for success. BTW, the whole JS-thing looks extremely odd, not even "long" and BigInteger are supported! The XML syntax added in ES4 look quite ridiculous. Who asked for that? I'm actually quite happy with the "cheap trick canonicalization" scheme. Even a third-rate programmer should be able to get it right :-) Regards, Anders > > Grüße, Carsten > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
