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

Anders Rundgren anders.rundgren.net at gmail.com
Fri Jul 24 11:52:54 UTC 2020


On 2020-07-24 10:21, Ralph Bragg wrote:
> Hi Anders,
Hi Ralph,
>
> Again I’m a little confused, for a wallet, once registration or consent has been given with a bank then updates, payments and other APIs are an api call only? (Or two if the access token is expired a refresh token was used to get another one).

These applications have generally no relation to OAuth.  They all have unique security solutions since there are no (established) standards in this space.  However, to date they have been excluded from Open Banking.

My quest is simply about fixing that or that we (all) accept that Open Banking APIs will only serve a tiny fraction of the consumer payment market.  If I were a bank architect I would consider this a poor use of resources since all applications could possibly benefit from the same core functions.  Bank Abstraction Layer [BAL].

>
> No further redirects, consents or any of the like would be required.
>
> Personally I think it would be a good idea for you to build a mobile client and then onboard to a model bank.

This is Saturn which I started with 2015.

> Happy to help you through that process if it’s not something you’ve done before. That way then you can compare and contrast and justify why things like embedding credentials would be required. I’m interested to see it.

If you want to see it, there are many alternatives:
Web-based UI-emulator for testing on desktop computer using Chrome: https://cyberphone.github.io/doc/saturn/ui-demo/index.html
Android "reference" application using a real bank sandbox: https://github.com/cyberphone/swedbank-psd2-saturn#swedbank-psd2saturn-interface

Embedded credentials is the core of the Berlin Group Embedded SCA tentative "upgrade" project.

Regards,
Anders


>
> RB
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Anders Rundgren <anders.rundgren.net at gmail.com>
> *Sent:* Friday, July 24, 2020 9:07:57 AM
> *To:* Ralph Bragg <ralph.bragg at raidiam.com>; Financial API Working Group List <openid-specs-fapi at lists.openid.net>
> *Cc:* Nat Sakimura <nat at sakimura.org>
> *Subject:* Re: [Openid-specs-fapi] FAPI meeting request - Mobile app access
> On 2020-07-24 08:37, Ralph Bragg wrote:
>> Hi Anders,
>>
>> Further to Nats questions, there is nothing stopping a confidential client being run on a mobile device. Indeed this is how a lot of Banks Mobile applications are written. With a confidential client on a mobile device there is nothing stopping the app from interacting with a providers APIs using the FAPI Security profiles.
>>
>> Joseph calls this out explicitly in implementation guidance section however there are significant challenges for implementation of this model under PSD2. The use of qualified certificates for 'identification' makes this almost impossible for a TPP to do safely or at least in a way that would be appropriate from a risk point of view however, if a TPP wanted to do this they could.
>>
>> Be interested to know where the specs technically don't work for confidential clients on a mobile.
> Hi Ralph,
>
> Is this what you mean with confidential client?
> https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md#markdown-header-524-confidential-client
> IMO, none of the things mentioned here apply because mobile apps are not "clients" in OAuth terminology.  Mobile apps must (of course) use strong authentication but they would for session-oriented applications preferably use FIDO and cookies. Mobile wallets (my line of work), OTOH, typically provide complete assertions like Apple Pay/EMV.  The latter is now targeted for inclusion in the Berlin Group API.  There is no scope, redirect, explicit PSU ID, only a single request/response pair.  The Berlin Group intends using Embedded SCA for this purpose but that doesn't solve the mobile app issue.
>
> The "problem" is that Open Banking APIs based on FAPI support the core (payments and account information access), but there is [currently] no standardized way reusing the core for mobile apps.  This is obviously outside of the CMA / EBA "order" but that doesn't make it irrelevant, particularly not for those who actually pay for the party, the Banks.
>
> Anders
>
>>
>> RB
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> <mailto:openid-specs-fapi-bounces at lists.openid.net> on behalf of Nat Sakimura via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> <mailto:openid-specs-fapi at lists.openid.net>
>> *Sent:* Friday, July 24, 2020 6:20 AM
>> *To:* Financial API Working Group List <Openid-specs-fapi at lists.openid.net> <mailto:Openid-specs-fapi at lists.openid.net>; Anders Rundgren <anders.rundgren.net at gmail.com> <mailto:anders.rundgren.net at gmail.com>
>> *Cc:* Nat Sakimura <nat at sakimura.org> <mailto:nat at sakimura.org>
>> *Subject:* Re: [Openid-specs-fapi] FAPI meeting request - Mobile app access
>> Hi.
>>
>> Certainly we can take it up as an agenda item but I would like to understand what you mean by FAPI methods. Could you please elaborate on it?
>>
>> Nat Sakimura
>> Chairman, OpenID Foundation
>> https://nat.sakimura.org
>> 2020年7月24日 15:04 +0900、Anders Rundgren <anders.rundgren.net at gmail.com> <mailto:anders.rundgren.net at gmail.com>のメール:
>>> Hi FAPIers,
>>>
>>> Currently FAPI methods are only accessible by TPPs.
>>>
>>> This may be "by design" but it also makes the API less universal and force banks to create competing APIs.
>>>
>>> As an example some mobile wallets provide real-time account balances. This obviously requires a direct call to the associated bank.
>>>
>>> Could we have a meeting on this topic?
>>>
>>> Sincerely,
>>> Anders Rundgren
>

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


More information about the Openid-specs-fapi mailing list