| Yes. Regarding JOSE (JWS/JWE/JWA/JWK/JWT) I consider that point one of the core design differences I have with JOSE as it results in re-encode ballooning. That's separate from the fact that JSON was intended to be human readable and base64 encoding of otherwise human readable payloads robs JSON of this design goal. (If going so far to base64 encode human readable payload, why not take advantage of efficient binary messaging standards instead of using JSON? The whole point of the "bloat" of JSON over binary forms is human readability.) Not only is JOSE base64 encoded, but many situations have base64 payloads embedded in the JSON, meaning payloads are double encoded, and as far as I'm aware, JOSE headers are always base64 encoded, regardless of the outer (re-)encoding. Each round of base64 encoding adds overhead. For example, if starting with a 32 byte payload, the first round base64 encodes as 43 bytes, then is inserted into JSON, and then base64 re-encoded as 58 bytes. The starting payload of 32 balloons to nearly twice the size of 58. For a direct example from one of the RFCs the header `{"alg":"RS256"}` becomes `"eyJhbGciOiJSUzI1NiJ9"`. That's 15 bytes unencoded, human friendly JSON and 20 bytes as encoded unfriendly base64. Further, there's a later RFC 7797 that was intended to address the complaints of this, the 'JOSE JSON serialization Unencoded Payload Option', but that too failed to address encode ballooning in the headers. From the RFC: { "protected": "eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19", "payload": "$.02", "signature": "A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY" } That encoded header is 58 bytes but when unencoded, {"alg":"HS256","b64":false,"crit":["b64"]}, it is 42 bytes. There's no compelling reason for this design. The better solution? Just stay as JSON. I have more to say, but I'll leave it there. You can also check out my presentation on the matter here: https://docs.google.com/presentation/d/1bVojfkDs7K9hRwjr8zMW... Right now a relevant slide is 115, or control-f "ballooning", or I have other text documents up on Github. |