[Openid-specs-fapi] Next step(s) for FAPI?

Anders Rundgren anders.rundgren.net at gmail.com
Sun Sep 29 07:16:17 UTC 2019


Thanx Ralph,

It is a little bit strange that ETSI rather than the IETF takes on this pretty universal topic.

Anyway, there are two issues that need to be addressed:
- How to deal with signed header data.  This is what many people (including myself) consider being the trickiest problem.
- How to represent the payload.  Since ALL Open Banking solutions I'm aware of use clear text, it would be strange changing this now.

Regarding the latter, canonicalization still offers major benefits over using plain HTTP bodies, including JSON serialization and embedding of signed data. That FAPI doesn't need counter signatures at the moment is true, but it may not always be the case.  Other solutions out there including my Saturn project is entirely depending on such constructs.  Implementations for JavaScript, Java, Python3, Go and C# (beginning with Net Core V3) shows that interoperability is essentially a no-issue.

Countersigning, serialization, and embedding using Cavage or OBIE's current signature scheme is not feasible.

thanx,
Anders
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-12

On 2019-09-29 08:45, Ralph Bragg wrote:
> All,
> 
> There was a meeting of the major standards bodies last week with ETSI coordinating. JWS detached and not detached will almost certainly be one of the agreed formats for AdES and subsequently message signing for PSD2.
> 
> When the minutes are published I’ll share.
> 
> Given that Cavage 11 includes the following.
> WARNING: DO NOT IMPLEMENT THIS SPECIFICATION AND PUSH THE CODE INTO
>    PRODUCTION.  THIS VERSION OF THE SPECIFICATION IS ONLY FOR
>    EXPERIMENTAL IMPLEMENTATIONS.
> 
> The Berlin group and others have had to explicitly reference version 10 to avoid using a a spec that says “don’t use this”. This doesn’t leave them a way forward with this draft. I expect that ETSI will look at the desirable properties of the Cavages draft and try and come up with something that has the same characteristics.
> 
> RB
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
> *Sent:* Sunday, September 29, 2019 7:20:33 AM
> *To:* Financial API Working Group List <Openid-specs-fapi at lists.openid.net>
> *Cc:* Anders Rundgren <anders.rundgren.net at gmail.com>
> *Subject:* [Openid-specs-fapi] Next step(s) for FAPI?
> Dear FAPIers,
> 
> Apparently the (in)famous https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ scheme has more or less become a de-facto standard.
> 
> Convincing the Berlin Group to change their NextGenPSD2 API will probably not happen since no standardized alternative is available and OBIE's current signature solution isn't REST compliant.
> 
> Anyway, there are other things FAPI could do to gather more interest.  It may be worthwhile collecting such and then decide where to go.
> 
> Here are a few known (and published) candidates:
> 1. An HTTP signature scheme that supports JSON serialization and embedding.
> 2. A scheme for enriching authorization requests.
> 3. A scheme for using FAPI locally in banks.
> 
> I'm currently plotting with #3 because it should be 100% backward compatible, while still being potentially quite useful. "Low hanging fruit" :)  Note though that OAuth2 is not really my area of expertize so it would be great if this was a FAPI project!
> 
> WDYT?
> 
> Anders
> 
> https://github.com/cyberphone/swedbank-psd2-saturn
> 
> 
> _______________________________________________
> 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