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.



_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to