[jose] Activities outside of the IETF dealing with "Signed JSON"

[Anders Rundgren <[e-mail]>]

Hi All,

As predicted the "Market" (or whatever we like to call it), working with applications like payments [1] have begun testing alternatives to JWS [2] in order to avoid dressing their precious messages in Base64.  Yes, there are specifications [3,4,5] adapting JWS for such uses by moving parts of the signature generation and validation processes into the application space.  Now, if you actually have a working JSON "Canonicalization" scheme [6], does it really make sense only using it for "Data" when it (by definition) should be equally applicable to "Headers"?  In addition, these applications typically rely on "Enveloped" signatures (for keeping message structure intact also after signing), making it straightforward providing "Human readable" header information as a part of an embedded signature object.

However, the JOSE stack of standards represents a truly amazing piece of work so it would of course be extremely cool if you could re(use) the JOSE "Core" rather than reinventing the wheel.  What's then the core of JOSE?  That's for sure debatable, but IMO, based on related work performed on multiple and quite different platforms, implementing support for the cryptographic algorithms (JWA) including JWK is the by far most difficult [7] part of JOSE.  Yes, "Input validation" (as recently mentioned on this list) is also crucial.  Creating a clear text signature container OTOH, is close to trivial.

Here is a revised attempt combining the best of two worlds: https://cyberphone.github.io/doc/research/jwa.jwk.es6-signature.html

Thanx,
Anders Rundgren

1] French Payment Standards proposal: https://api.scailine.org/ext/useCaseOnlinePisp.pdf using the LDS scheme [2]:
2] Linked Data Signatures: https://w3c-dvcg.github.io/ld-signatures/
3] JWS Unencoded Payload option: https://tools.ietf.org/html/rfc7797
4] JWS Detached Content: https://tools.ietf.org/html/rfc7515#appendix-F
5] Signature scheme using an "Implicit" JWS container: https://w3c-dvcg.github.io/lds-rsa2017/
6] ES6 Serialization appears to be a good candidate since it is already featured in billions of devices
7]  Cryptographic subsystems differ quite a bit in capabilities and usage between platforms like .NET, Java, Python, Node.js, etc.