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

Anders Rundgren anders.rundgren.net at gmail.com
Mon Jul 27 16:18:00 UTC 2020


On 2020-07-27 17:02, Joseph Heenan wrote:

Hi Joseph,

I understand that you dislike this idea but I think you are overreacting a bit.  BG's tentative Embedded SCA for EMV,FIDO; Mobile etc. is in fact a step in the same direction.


> 
>> On 27 Jul 2020, at 15:02, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto: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.

I meant that there is no other organizational entity involved.

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

Presumably whatever they have as interface still move money from one account to another, or retrieve information about accounts.


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

Sure, there are rules but there is no NCA as far as I know.

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

I totally agree but I have a feeling that very few banks do that today.  For Android I guess attestations (as used by Saturn) is the only trustworthy way to know which app you are talking 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.

It is of course doable.  For Apple Pay/EMV it is less doable.


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

The direct mode has nothing to do with TTPs.  Having the bank's own application ask for a "consent" is not compliant with the reality.  None of the numerous bank applications I use do that.  They do ask me to authorize payments but that is another thing.

Wallets like Apple Pay and Saturn doesn't need any access tokens since they already have one or more built in.  They also do not create sessions.

If this is such a horrible idea, we can postpone the discussions until the Berlin Group give this new thing their blessing.

Anders

> 
> Thanks
> 
> Joseph
> 
> 



More information about the Openid-specs-fapi mailing list