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

[Dave Tonge]

Hi Anders

Are you able to join one of the working group calls so that we can discuss
this further?

Thanks

Dave

On Sun, 29 Sep 2019 at 09:16, Anders Rundgren via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> 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
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20191002/535e4e73/attachment.html>