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

Joseph Heenan joseph at authlete.com
Mon Jul 27 22:11:57 UTC 2020



> On 27 Jul 2020, at 19:58, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
> 
> On 2020-07-27 18:42, Joseph Heenan wrote:
> 
> The fact is that nobody in this WG (or anywhere else for that matter), have come up with a document (not to mention a product) showing how you could create payment systems that even comes close to Apple Pay based on PSD2 APIs/OAuth.

I think this is the fundamental disagreement: You can't recreate Apple Pay on top of PSD2 APIs. That’s a legal problem, not a technical one. PSD2 has a deliberate reach, and is it clear that ‘open access’ PSD2 APIs can’t be used to build something that will cut banks out of the card fee revenue loop. A number of people are annoyed about that, but that is how it the legal position. (Interestingly, Variable Repeat Payments support from the UK CMA9 may end up partially doing so.)

You can get close already - but ‘getting close’ still requires the bank performing SCA on the user.

> The Berlin Group wants to change this through Embedded SCA [1].  If successful, FAPI/OBIE will surely have to join the party.

Embedded SCA is a separate thing - see https://bitbucket.org/openid/fapi/issues/295/possible-support-for-embedded-sca-mode <https://bitbucket.org/openid/fapi/issues/295/possible-support-for-embedded-sca-mode> and in particular the flow diagram, which I presume must be the flow you’re talking about. If it’s not, please provide a flow diagram for the BG standard you are talking about.

Embedded SCA (as described there) cannot be used to create an Apple Pay competitor, because the bank is still doing SCA - the TPP is just providing the UI to collect the necessary data from the user, the SCA is not ‘out sourced’ to the TPP. SCA in law basically explicitly requires non-replayable credentials.

For the mobile app case, I don’t think embedded SCA even helps - you actually get a better user experience doing an app2app authentication so the user only has to do a biometric - as opposed to doing embedded SCA and having the user mess around typing in OTPs… as far as I know embedded SCA doesn’t extend as far as allowing the TPP to do a biometric - because the EBA opinions don’t require banks to allow that, though it can be done by a commercial arrangement between the TPP and bank (i.e. a model where the TPP pays the bank real money for the additional privilege of performing SCA on behalf of the bank). 

People are already using the app2app model in the UK (and I guess Europe will get there eventually) to implement ‘pay with Banked straight from your bank account’, ‘donate to charity without any card fees’, ’transfer money from my legacy bank account to my challenger bank bank account’. Though the ‘pay with Banked’ is not popular as the liability and/or settlement model doesn’t really work for the merchant or buyer when selling/buying goods or services, especially compared to debit/credit cards.

[I don’t currently see how Embedded SCA overlaps with “mobile app access”?]

If we switch, and consider the UK API I referred you to earlier, that absolutely allows you to implement an ‘Apple Pay’ competitor (depending exactly what you mean by that - if you wanted to do it via the mastercard/visa/amex networks and the NFC card terminals you’d still need an acquirer etc).

Joseph

> 
> EMV is super-simple: EMV authz -> Merchant -> "PISP" -> ASPSP.  A single request/response pair all the way to the bank.
> 
> Anders
> 
> 1] Personally I consider EMV, FIDO for Payments, Saturn, etc, being "applications" and should not be a part of the Open Bank "platform".  Hence the "Direct Mode".
> 
>>> On 27 Jul 2020, at 17:18, Anders Rundgren <anders.rundgren.net at gmail.com <mailto: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 <http://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/6ebb6c7a/attachment.html>


More information about the Openid-specs-fapi mailing list