[Openid-specs-fapi] Serialization: Financial_API_HTTP_Signing.md

[Joseph Heenan]

Thanks Anders!

I think most of the schemes can be serialised; it’s just a case of storing the http headers & body? (I guess to different degrees, this is easier is some schemes than others.)

I’m thinking I do need to move ’serialisation’ out to being it’s own requirement to make that clearer though.

One other interesting thing to come out of the call is that it sounds like there is still a use case for integrity protection as well; TLS is often not end to end in the bigger systems, would people agree with adding this as a potential requirement?

Joseph

> On 25 Oct 2019, at 06:14, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> Thanx Dave for arranging the HTTP Signature call!  My SHREQ presentation wasn't that great; I'm more used to documents and F2Fs :)
> 
> Anyway, in https://bitbucket.org/openid/fapi/src/master/Financial_API_HTTP_Signing.md there is a line
> 
>     "Any signing scheme must support straightforward serialization for later verification"
> 
> which I don't understand since few of the proposed solutions actually have this quality.  They rather support receive-time/transient signature verification which is sufficient for FAPI given the *current* functionality.
> 
> For Saturn OTOH, serialization support is fundamental since it builds on a self-contained, clear-text, redeemable, payment-token concept using *counter-signatures* which for example is used for Gas station payments which few (if any) Open Banking APIs currently support.  This is effectively an alternative to the "lodging" schemes FAPI is currently playing with.
> 
> Regards,
> Anders