[Openid-specs-fapi] JWS Detached Data - Vulnerable or not?

Anders Rundgren anders.rundgren.net at gmail.com
Mon May 13 05:31:34 UTC 2019

It has been claimed that the RECOMMENDED way using JWS is ASCII-armoring through Base64Url encoding because otherwise you bring in security vulnerabilities.  However,  none of the Open Banking APIs have chosen that path.

In addition, RFC7515 (JWS RFC) also defines a detached mode but doesn't speak a word about vulnerabilities, it only says that the detached data must be reconstructed in an exact manner which of course is true.  If you fail to do that the only thing that happens (in a properly designed application NB), is that you get a signature validation error leading to a rejected request or similar.

Question: Can we maybe put the ASCII-armoring as a hard requirement to rest [1] ?

If this is the case, I claim that simple "hashable" serialization schemes like JCS are more robust than HTTP bindings.  Other benefits include:
- HTTP requests become self-contained, serializable, embeddable and fully JSON compliant objects
- A method that can be applied to any other JSON object needing a signature

These were the issues raise at IETF-104 in Prague: https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html


1] URL-safe operation is another thing.

More information about the Openid-specs-fapi mailing list