[Openid-specs-fapi] Issue #295: Possible support for "embedded" SCA mode (openid/fapi)

Francis Pouatcha fpo at adorsys.de
Thu Jun 4 14:36:22 UTC 2020


Thanks for sharing Ralph,

- From a legal perspective, many ASPSP still provided AIS and PIS to their
customers through embedded interfaces. As long as this occurs, TPP will
keep fighting to obtain the same privileges, as the embedded approach
provides the smoothest user experience.

- From a technical perspective, there is a huge misunderstanding
around authentication and authorization in the open banking space. Many
frictions caused by multiple SCA, multiple redirections are due to the fact
that initial open banking market initiatives did not draw clear lines
between "authentication" and "authorization" of the PSU.
--> Authenticating a PSU with the purpose of establishing a session between
the PSU -> TPP -> ASPSP can occur once, can be well done using redirection
and can be durable.
--> Authorizing a payment or additional account access is very tight to
banking business logic and should be embedded inside the PSU -> TPP
interface,
----> as there is a dynamic linking between transaction data and the second
factor (TAN, signature, ...)
----> as this will take away all hazard associated with involving unwanted
third parties in this interaction, including the leakage of transaction
data embedded into unencrypted jwt token in browser caches, ...
----> as this will allow TPP to provide frictionless banking interfaces to
PSU

- We also witness the EBA here mentioning the PoS use case that does not
work with mandatory redirection.

>From this EBA opinion paper, you can see the embedded approach is still a
battleground between TPPs and ASPSP in the EEA open banking space. This
battle will continue till we have well implemented reference practices that
are secure and smooth on the market.

IMHO the final solution will move toward having hybrid solutions with
redirected authentication and embedded authorizations.

This I reraised the point of reconsidering the embedded approach.

@Dave Tonge <dave.tonge at momentumft.co.uk> Where do I find the previous
discussion or FAPI change request related to the embedded approach?

Best regards.
/Francis

On Thu, Jun 4, 2020 at 8:10 AM Dave Tonge <dave.tonge at momentumft.co.uk>
wrote:

> Thanks for sharing Ralph - its an interesting document.
>
> We had a discussion with Francis Pouatcha who brought the issue up again
> - as a way of helping harmoisation efforts with the Berlin Group and banks
> that have implemented their standards.
>
>
>
> On Thu, 4 Jun 2020 at 14:04, Ralph Bragg via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
>> Hi,
>>
>> Opinion piece from the EBA on the validity of redirect and decoupled
>> flows; I haven't digested the whole lot completely but it's broadly
>> supportive of redirect and decoupled provided it's done well.
>>
>> Dave T - I'm curious about the embedded mode requirement and where this
>> has come from?
>>
>>
>> https://eba.europa.eu/eba-publishes-opinion-obstacles-provision-third-party-provider-services-under-payment-services
>>
>> Cheers,
>> Ralph
>>
>> On 04/06/2020, 11:02, "Openid-specs-fapi on behalf of Joseph Heenan via
>> Openid-specs-fapi" <openid-specs-fapi-bounces at lists..openid.net
>> <openid-specs-fapi-bounces at lists.openid.net> on behalf of
>> openid-specs-fapi at lists.openid.net> wrote:
>>
>>
>>
>>     > On 4 Jun 2020, at 10:21, Anders Rundgren <
>> anders.rundgren.net at gmail.com> wrote:
>>     >
>>     > On 2020-06-04 11:01, Joseph Heenan wrote:
>>     >> Hi Anders,
>>     >> Can you describe with a few lines of text (without referring to
>> Saturn :-) ) how a protocol could address the EMV use case within FAPI or
>> one of the other mechanisms we’re discussing please?
>>     >> (
>> https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf
>> seems mostly to be rehashing OpenID’s “sub” and OAuth2’s refresh token, and
>> I can’t see where the result differs from using those two?)
>>     >
>>     > The document you are referring to is the best description I have so
>> I can only repeat myself :)
>>     >
>>     > The technical core of the idea is keeping payment applications like
>> EMV, Saturn, FIDO, etc out of the Open Banking API.
>>     > The commercial aspect is that such applications would preferably be
>> provided by the respective system owner.
>>     > The applications (services rather) may or may not be PSD2
>> compatible.
>>     > The scheme builds on using OAuth2 as binding system between these
>> services (additional APIs) and the core API, where the former thus works
>> like TPPs.
>>     > The only really new thing is that the applications are running with
>> higher privileges than existing applications since they are supposed to do
>> SCA on their own.
>>     >
>>     > Making Open Banking APIs [technically] usable for any consumer
>> payment may not be such a bad idea.
>>
>>     So if I understand correctly, the problem is with the limitations
>> surrounding PSD2 functional APIs?
>>
>>     The various mechanisms FAPI supports, including CIBA and the embedded
>> proposal under discussion, are all suitable for the initial user
>> onboarding/binding of the user and (by using refresh tokens) for creating
>> persistent sessions from the TPP to the bank for that user, and that no
>> changes are necessary to the “security” protocols to enable the EMV use
>> case supporting functional APIs you’re describing?
>>
>>     Thanks
>>
>>     Joseph
>>
> --
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200604/a42ed06b/attachment-0001.html>


More information about the Openid-specs-fapi mailing list