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

[Joseph Heenan]

> On 27 Jul 2020, at 17:18, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> 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.
> 

It’s not that I dislike anything, I just still don’t know what you’re actually proposing the FAPI WG does.

"Embedded SCA for EMV” turns up zero google matches. A link, a copy of a relevant document or a description of how it works (that doesn’t mention Saturn) would be great.

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

Not necessarily. e.g. some bank mobile apps (still!) can’t create new payees, only pay to existing ones, and sometimes only for very limited amounts. The interfaces generally only allow what the application supports, deliberately. They may only return transactions as html, not in a structured format like json you’d expect in a banking API.


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

It’s under PSD2 so the same NCA as for TPPs applies, in the UK banks (and hence bank’s own mobile apps) are regulated by the FCA.

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

Really? In that case you already have the API you want, you can just reverse engineer the bank’s mobile app. Several people tried to do this (tellr.io), but it doesn’t work out well. The banks do not want people pretending to be their mobile app’s API and go to quite some length to make sure they don’t.

Attestations are generally bypassable in my experience; within banking I believe they’re only used in combination with other methods. As I mentioned, the methods are generally classed in some way as ’security through obscurity’ (e.g. white box crypto), but that doesn’t mean they can be bypassed in any reasonable financially viable time.


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


I’m fairly certain most banking applications I’ve used have asked me for consent when I first logged into it, depending what you mean by consent. Bank don’t collect consent in the PSD2 use cases either (consent is collected by the TPP). If direct mode is only for use internally between a bank’s mobile app and a bank’s server there is, in my opinion, very little point in standardising it, as none of the large banks are interested in using such a standard.

Joseph

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