[Openid-specs-fapi] FAPI HTTP Signing requirements

Anders Rundgren anders.rundgren.net at gmail.com
Mon Jul 15 17:00:52 UTC 2019


On 2019-07-12 17:11, Joseph Heenan wrote:
> Thank you Anders! Responses inline:
Hi Joseph, responses in-line.
> 
>> 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).

No, I was (for once) not pushing my favorite solution :) Even OBIE's current solution require direct access to the raw JSON payload.

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

Yes, it would.


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

Not really.  There were just a bunch of complaints but no concrete issues except that XML canonicalization failed which actually is incorrect and also ignores the fact that XML <> JSON.  FWIW, I collected the issues raised in document and included my responses as well:
https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html

The naked truth is that there is no "perfect" solution, they all have certain pros and cons.  It is possible that Open Banking APIs will never need the sophisticated constructs like counter signatures required by Saturn.  OTOH, it would be a huge advantage if whatever concept the WG comes up with could be used by non-FAPI applications as well.

BTW, dealing with HTTP header canonicalization (featured in both the cavage I-D and the Amazon scheme) is way more difficult than JSON canonicalization.

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

That sounds very reasonable. Anyway, here you have a comparison table made by Dave Tonge:
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/tonge_-_http_signing.pdf#page=5

Thanx,
Anders
SHREQ - Signed Http REQuests: https://mobilepki.org/shreq/home



> 
> Thanks
> 
> Joseph
> 



More information about the Openid-specs-fapi mailing list