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

[Ralph Bragg]

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 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

    _______________________________________________
    Openid-specs-fapi mailing list
    Openid-specs-fapi at lists.openid.net
    http://lists.openid.net/mailman/listinfo/openid-specs-fapi