[Openid-specs-fapi] PSD2 - FAPI Client Registration

Sun Aug 2 03:14:33 UTC 2020

Hello Ralph,

thanks for the document. I didn't have access to this.

As we have to deal with non repudiation at the DRC interface, I will
suggest FAPI works on following recommendation:

Suggest implementation to select either of these signature schemes at DRC
(and other AS back channel endpoints)
- "JSON Web Signature Profile for Open Banking" or design a superset that
keeps the non repudiation character (Included mandatory use of certificates
can only apply in legislation where client/tpp are all issued certificates).
- Propose an alternative based on http-signature (see
https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/)
with mandatory header params that guarantee the non repudiation character
of the request.

Best regards
/Francis

On Sat, Aug 1, 2020 at 4:50 PM Ralph Bragg <ralph.bragg at raidiam.com> wrote:

> Hi,
>
>
>
> Resharing the comparison and analysis previously shared with this group,
> given that in a JAdES signature, the body and headers are signed as part of
> the request, non-repudiation is achieved. I’ll admit, I prefer the OBIE
> current approach as it’s nicely tied up in a bow / single message but both
> mechanisms offer non repudiation.
>
>
>
> Also the original TDA decision with input from the Major Banks can be
> found on the OBIE TDA website which debated various different methods. You
> might find this useful crafting the way forward for DCR for Berlin. If
> there is a desire to see the UK model of a signed DCR request being picked
> up out of the UK then it should be standardized so I’m keen to see how this
> progresses.
>
>
>
> RB
>
>
>
> *From: *Francis Pouatcha <fpo at adorsys.de>
> *Date: *Saturday, 1 August 2020 at 21:15
> *To: *Ralph Bragg <ralph.bragg at raidiam.com>
> *Cc: *Financial API Working Group List <openid-specs-fapi at lists.openid.net
> >
> *Subject: *Re: [Openid-specs-fapi] PSD2 - FAPI Client Registration
>
>
>
> Hello Ralph,
>
>
>
> The draft ETSI JAdES standard is what I refer to  with "JSON Web Signature
> Profile for Open Banking" that is designed to be JAdES compliant.. Berlin
> Group is also behind the standard, as they are listed among the
> contributors.
>
>
>
> Although the OBIE approach is criticized, it is the only option I met so
> far that provides non repudiation for DCR.
>
>
>
> Considering heavy regulation of the financial industry, not covering non
> repudiation is not an option.
>
>
>
> Best regards.
>
> /Francis
>
>
>
> On Sat, Aug 1, 2020 at 3:12 PM Ralph Bragg <ralph.bragg at raidiam.com>
> wrote:
>
> Hi Francis,
>
>
>
> I can only take partial credit for its adoption in the obie specifications
> the other credit belongs to the talented Pam Dingle.  The draft ETSI JAdES
> standard for payload signing should also be consulted (though it’s a
> detached format for signing) if you want something that’s future proof and
> a European wide standard for JSON payload signing.
>
>
>
> All standards bodies Are being encouraged to adopt  JAdES by ETSI when it
> is published so check if that is still the intention for Berlin group.
>
>
>
> I should also point out that the obie approach isn’t necessarily
> universally liked by this community as the inner jwt has to be unpacked to
> obtain the key locations in order to validate the outer payload. It’s not
> an ietf or oidf standard however there is wide spread support for
> processing this request format from  all major idps.
>
>
>
> Ralph Bragg
>
> Raidiam Services Ltd
>
>
>
> Sent from a mobile device. Please excuse brevity and typos.
> ------------------------------
>
> *From:* Francis Pouatcha <fpo at adorsys.de>
> *Sent:* Friday, July 31, 2020 10:35:16 PM
> *To:* Ralph Bragg <ralph.bragg at raidiam.com>
> *Cc:* Financial API Working Group List <openid-specs-fapi at lists.openid.net
> >
> *Subject:* Re: [Openid-specs-fapi] PSD2 - FAPI Client Registration
>
>
>
> Hello Ralph,
>
>
>
> excellent work done here (
> https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement).
> realy! We can build on top of this.
>
>
>
> For authentication of TPP with ASPSP's AS, we will use: tls_client_auth.
> This is included.
>
>
>
> OBIE signing the entire registration request provides for non repudiation
> for the registration call. This is a great first step. If we can add the
> QSealC to the header of the request, we will be complete here.
>
>
>
> Last part missing would be the non repudiation for all other back channel
> requests from TPP to ASPSP's AS.
>
>
>
> To FAPI Working Group:
>
>
>
> IT makes sense to add the option of having (all) requests from TPP to
> ASPSP's AS signed (e.g.: QSealC). We could call this authentication method:
> "signed_http_request".
>
>
>
> The signature scheme supported by the AS could be published with AS
> metadata. IT could be:
>
> - JSON Web Signature Profile for Open Banking (See EBA Clearing)
>
> - draft-ietf-httpbis-message-signatures
>
> - Or any other scheme providing non repudiation over HTTP messages.
>
>
>
> The AS metadata could define the header field where to put the signature
> certificate (Like in NextGenPSD2 the TPP-Signature-Certificate).
>
>
>
> Canonicalization shall also be defined by the chosen signature standard.
>
>
>
> Does this look like a change request to FAPI?
>
>
>
> Best regards
>
> /Francis
>
>
>
>
>
> On Fri, Jul 31, 2020 at 2:07 AM Ralph Bragg <ralph.bragg at raidiam.com>
> wrote:
>
> Hi Francis,
>
>
>
> See here for the OBIE DCR Spec.
>
>
> https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement
>
>
>
> It supports both a federation provider issued Software Statement Assertion
> and a Self Signed Software Statement Assertion and is an example of a DCR
> request sent as a JWT to bind both the SSA and the Request together.
>
>
>
> The same approach can be achieved by using standard DCR (JSON) with
> ecosystem defined ‘initial access token’ as a JWT provided the request is
> sent over a tamper resistant transport channel such as an Mutually
> Authenticated TLS channel where both parties are using QWACs to identify
> each other.
>
>
>
> Rgds,
>
> RB
>
>
>
>
>
> *From: *Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on
> behalf of Ralph Bragg via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net>
> *Reply to: *Financial API Working Group List <
> openid-specs-fapi at lists.openid.net>
> *Date: *Friday, 31 July 2020 at 06:03
> *To: *Financial API Working Group List <openid-specs-fapi at lists.openid.net
> >
> *Cc: *Ralph Bragg <ralph.bragg at raidiam.com>, Francis Pouatcha <
> fpo at adorsys.de>
> *Subject: *Re: [Openid-specs-fapi] PSD2 - FAPI Client Registration
>
>
>
> Hi Francis,
>
>
>
> There are two approaches. 1. Sign the entire registration request. Look a
> the obie dynamic client registration approach for an example of how this is
> performed.
>
>
>
> 2. Craft and define an “initial access token” which can be defined as a
> jwt that a tpp can use as part of registration. I have examples of both
> approaches if you drop me a line.
>
>
>
> The obie is publishing a list of trusted qtsp certificates issuing and I
> believe the root authorities as well they is created by processing the EU
> list of trust listed.  banks should have no excuses for not being able to
> determine the set of issuing authorities to trust up front.
>
>
>
> Kind Regards,
>
> Ralph
>
>
>
>
> ------------------------------
>
> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on
> behalf of Francis Pouatcha via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net>
> *Sent:* Friday, July 31, 2020 3:09:15 AM
> *To:* Openid-specs Fapi <openid-specs-fapi at lists.openid.net>
> *Cc:* Francis Pouatcha <fpo at adorsys.de>
> *Subject:* [Openid-specs-fapi] PSD2 - FAPI Client Registration
>
>
>
> In our attempt to use FAPI to implement the NextGenPSD2 oAuth approach, we
> are facing the following problem.
>
>
>
> The PSD2 trust framework assumes each ASPSP maintains the list of
> legitimated certification authorities (rootCAs). This is, regulators expect
> ASPSP to accept requests from any licensed TPP that present a valid
> QWAC/QSealC certificate.
>
>
>
> We have been looking for a way to use dynamic client registration to allow
> the TPP to register with ASPSP's OP/AS prior to sending their first
> requests.
>
>
>
> OP can get access to TPP's authenticated information:
>
> - If TPP uses mTLS (QWAC) at the OP interface.
>
> - If TPP uses QSealC to sign the client registration request, seems to be
> the best approach, as it also provides non repudiation.
>
>
>
> Request Signature:
>
> Alt-1: I prefer signing the whole http request (see
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/).
> Not sure if this is covered by FAPI.
>
> Alt-2: QSealC could be used to produce a private_key_jwt that will be
> included to the registration request. QSealC can be added to the token, to
> avoid pre-registration. Digest of the request body could be added to the
> private_key_jwt to provide for non repudiation.
>
>
>
> What am I missing? Are we still in the scope of OIDC/FAPI or getting out
> of bound?
>
>
>
> Thanks in advance for feedback.
>
> --
>
> Francis Pouatcha
>
> Co-Founder and Technical Lead
>
> adorsys GmbH & Co. KG
>
> https://adorsys-platform.de/solutions/
>
>
>
>
> --
>
> Francis Pouatcha
>
> Co-Founder and Technical Lead
>
> adorsys GmbH & Co. KG
>
> https://adorsys-platform.de/solutions/
>
>
>
>
> --
>
> Francis Pouatcha
>
> Co-Founder and Technical Lead
>
> adorsys GmbH & Co. KG
>
> https://adorsys-platform.de/solutions/
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200801/c2bf7eb1/attachment-0001.html>