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

Ralph Bragg ralph.bragg at raidiam.com
Fri Jul 24 08:21:10 UTC 2020

Hi Anders,

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

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


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


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


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

Anders Rundgren

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

More information about the Openid-specs-fapi mailing list