[Openid-specs-fapi] FAPI HTTP Signing requirements

Anders Rundgren anders.rundgren.net at gmail.com
Thu Jul 11 15:09:46 UTC 2019

Hi Joseph,

"However many middleware systems come with REST clients that
  will often parse JSON payloads automatically, making it difficult
  to reconstruct the original message body to verify the signature"

In this case it seems that no post processing signature scheme will work; it would have to be an integral part of the REST solution itself.

Additional Requirement/Feature: serializability (= storage of signed request or response data).

Although JCS (JSON Canonicalization Scheme) was rejected by IETF-ART it surely isn't dead :-)  In fact, nobody have come up with a problem that doesn't have a well-defined solution.  JCS has been successfully applied to the Saturn payment authorization system for Signing, Authenticated Encryption as well as for Hashing of JSON objects.  JCS is currently in the IETF ISE (Independent Stream Editor) queue.


On 2019-07-11 14:40, Joseph Heenan via Openid-specs-fapi wrote:
> Hi all,
> After discussion with Dave (in an attempt to move forward the long-running discussion about HTTP signing) I have tried to enumerate the requirements for HTTP signing within the context of Financial-grade APIs:
> https://bitbucket.org/openid/fapi/pull-requests/130
> The rational for creating this was that it should be much easier to discuss the pros and cons of potential solutions if we have consensus as to what the goals are.
> Any feedback would be greatly appreciated.
> Thanks
> Joseph
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

More information about the Openid-specs-fapi mailing list