On Mon, Sep 2, 2013 at 5:33 PM, Tim Bray <[email protected]> wrote: > On Mon, Sep 2, 2013 at 5:28 PM, Manger, James H > <[email protected]> wrote: >> >> You can escape / as \/ in JSON, but you don't have to. "/" and "\/" are >> both equally valid JSON strings representing the same 1-character logical >> value. Any JSON parser needs to support both. > > > Yes. > >> >> I believe the one useful use of \/ is to escape "</script>" as >> "<\/script>" when it appears as a JSON string in HTML so the HTML parser >> does not misinterpret it as the end of the script. > > > No. Because \/ is just /. > > If you want \/ in your output you have to say \\/. > > In any case, all this escaping is done at the JSON parser level, so > app-level software doesn’t know whether the JSON textual form contained / or > \/. > > Yes, if you read and re-serialize a JSON text and foolishly escape > characters here and there, you will break signatures. JSON doesn’t have a > canonical form and is not apt to get one. -T
And is in recognition of the fact that there is no JSON canonical form that Jose has defined signature/integrity protection on the base64 encoded format. Any manipulations of the input are thus disallowed, thus avoiding an entire class of interoperability failures. > >> >> In a canonical form of JSON one form needs to be chosen: "/" is the best >> choice; it is the choice of ECMAScript’s JSON.stringify. >> JOSE does not require a canonical form so "http://example.com"; and >> "http:\/\/example.com" are both acceptable. I'm glad the former is chosen >> for the JOSE examples. >> >> >> > However, when looking further I note that JOSE requires some kind of >> > non-standard/additional JSON normalizing before applying base64url: >> > >> > >> > http://tools.ietf.org/id/draft-ietf-jose-json-web-signature-14.html#rfc.section.5.3 >> >> No. The string comparison rules are just trying to be clear that JOSE >> implementations are expected to compare logical string values (not JSON >> serializations, which are not unique due to optional escape sequences) and >> are not expected to perform any Unicode normalization, such as NFC or NFKD. >> >> -- >> James Manger >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- --Breno _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
