[Openid-specs-fapi] FAPI meeting request - Mobile app access (Francis)

Joseph Heenan joseph at authlete.com
Mon Jul 27 15:02:44 UTC 2020



> On 27 Jul 2020, at 15:02, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> 
> Hello Francis,
> 
> Can we take this slowly to not create unnecessary friction or hardships?
> 
> I am claiming that:
> - On-line banking applications usually call bank-servers directly.

That’s incorrect; they almost always have a backend that talks to the underlying bank server.

> - Such applications use some kind of API that in the end presumably does quite similar things as Open Banking APIs.

That varies a lot between banks. Some do not use anything you would think of as an API (for example, some bank mobile app backends generate significant amounts of html).

> - Such applications are neither TPPs nor regulated.

That’s incorrect; such applications are definitely regulated and banks have had to make changes to their apps due to PSD2, for example requiring SCA in places they didn’t before.

> - Such applications use authentication solutions that the bank consider sufficient.

And, very very importantly, the bank is able to validate the identity of the calling application, because it is the bank’s own mobile app, and the app has (somehow) also proved to the bank server which PSU it is associated with.

> - FIDO is currently held as the state-of-the-art for user authentication.
> - FIDO is not a PKI solution.
> 
> If any of the above is wrong, feel free to correct me.
> 
> What I'm proposing is that it might be useful if such applications could reuse the core of Open Banking APIs. This obviously needs another "input channel" since the security model is entirely different.


I’m aware of at least one bank where the mobile app is an oauth client that uses FAPI to obtain such an access token - albeit there are still some differences.

> 
> Since on-line banking as well as mobile wallets are not standardized, I'm only proposing a standardized mechanism [1] for connecting trusted bank-local applications to Open Banking APIs.  BTW, a trusted bank-local application may very well support a PSD2 compliant service.
> 
> You claim that the Berlin Group cannot introduce this due to regulatory requirements.
> Since the Berlin Group is a member-driven organization shouldn't this be up to the members to decide?
> 
> OBIE is different because they got substantial government funding.

OBIE’s protocol supports what I think you’re talking about with ‘direct mode':

https://github.com/OpenBankingUK/read-write-api-docs-pub/blob/master/profiles/read-write-data-api-profile.md#consent-re-authentication-through-tpp

(Which you’ll note just uses an existing standard, RFC7523, combined with the relevant FAPI requirements like send constrained access tokens.)

But note that I’m not currently aware of any banks that have yet chosen to enter such an agreement with TPPs, as they’re not legally required to, and implying that no TPP has yet proposed something to the bank that is financially attractive for the bank. And (as already noted re: eIDAS etc), such APIs can’t really be used directly from third party mobile apps, due to the requirement to identify both the app/organisation and the user - i.e. the third party mobile app must have a bank end that verifies the call came from the third party’s app, as there’s really no way to have the bank validating a third parties app - or at least not a standardised way (the state of art on iOS generally involves a lot of what can be viewed as security through obscurity, which won’t be put into a published standard for hopefully obvious reasons).

Thanks

Joseph


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200727/b2316262/attachment-0001.html>


More information about the Openid-specs-fapi mailing list