If you have ever been through web services security, you probably already know that XML encryption and digital signature are nightmare from interoperability and readability point of view. Here’s an interesting competition growing just now — Javascript Object Signing and Encryption (jose). XML security standards are an example of “try to solve every possible problem on the planet” approach to standardisation, something that was also strongly visible in X.509 and IPSec standards. It took ages to create these standards, and that’s only when they started to get stuck in countless interoperability and implementation issues. But the world around them didn’t really want to wait — it was just coming up with workarounds and home-grown solutions.
XML itself is complex and this how JSON gained popularity. Millions of users now use JSON based authentication protocols on social websites instead of XML based ones. Obviously, the day must have arrived where someone just had to come up with an idea to create an equivalent of XML-Enc and XML-DSig for JSON. Enter JOSE…
Standards around Javascript Object Signing and Encryption (jose) seem to be quite fresh as for the standardisation process. The group at IETF was created in 2011 but only started work in 2013. Quick review of JSON Web Signature (JWS) draft gives me mixed feelings.
On the one hand, it’s much simpler than respective XML standards. On the other hand, it seems to follow the good old tradition of inventing its own weird naming conventions. In case of JOSE, the creators decided to distinguish their project from others by weird field names, which in most cases is implemented by truncating them to 3 characters. So instead of calling a field “type” they call it “typ”. And field containing URL to public keys, named “JWK Set URL” is conveniently abbreviated as “jku”.
Happy reading resulting JSON files — but if you wanted to save space (why at all?) maybe you should try PER (X.691) encoding instead?