[Openid-specs-fapi] FAPI HTTP Signing requirements

Joseph Heenan joseph at authlete.com
Fri Jul 12 15:11:30 UTC 2019

Thank you Anders! Responses inline:

> On 11 Jul 2019, at 16:09, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 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.

I’m not sure I understand the meaning of ‘post processing’ here; canonicalization of JSON is a possibly (I believe I imply this in the next sentence?) and the other approaches would involve not sending raw JSON payloads (the various schemes that base64 encoded etc).

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

Agreed. I think that’s a part of the ’non-reputation’ requirement; would expanding the text in that section to mention serialisation resolve this?

> 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.

Thanks for the update! Apologies if you already shared this, but did they explain the reasons for rejection?

You will note I am trying not to comment too much on any particular solution at this stage, and I have no idea what conclusion the WG may come to on how many (if any) HTTP signing schemes the WG may eventually endorse.



More information about the Openid-specs-fapi mailing list