<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2020-07-24 10:21, Ralph Bragg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:LNXP265MB0809E1EDF5E44087CF5F288EF6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div data-ogsc="" style="">
<div>Hi Anders,</div>
</div>
</div>
</blockquote>
Hi Ralph,<br>
<blockquote type="cite"
cite="mid:LNXP265MB0809E1EDF5E44087CF5F288EF6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM">
<div dir="ltr">
<div data-ogsc="" style="">
<div dir="ltr"><br>
</div>
<div dir="ltr">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). <br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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].<br>
<br>
<blockquote type="cite"
cite="mid:LNXP265MB0809E1EDF5E44087CF5F288EF6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM">
<div dir="ltr">
<div data-ogsc="" style="">
<div dir="ltr"><br>
</div>
<div dir="ltr">No further redirects, consents or any of the
like would be required.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Personally I think it would be a good idea for
you to build a mobile client and then onboard to a model
bank. </div>
</div>
</div>
</blockquote>
<br>
This is Saturn which I started with 2015.<br>
<br>
<blockquote type="cite"
cite="mid:LNXP265MB0809E1EDF5E44087CF5F288EF6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM">
<div dir="ltr">
<div data-ogsc="" style="">
<div dir="ltr">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.</div>
</div>
</div>
</blockquote>
<br>
If you want to see it, there are many alternatives:<br>
Web-based UI-emulator for testing on desktop computer using Chrome:
<a class="moz-txt-link-freetext" href="https://cyberphone.github.io/doc/saturn/ui-demo/index.html">https://cyberphone.github.io/doc/saturn/ui-demo/index.html</a><br>
Android "reference" application using a real bank sandbox:
<a class="moz-txt-link-freetext" href="https://github.com/cyberphone/swedbank-psd2-saturn#swedbank-psd2saturn-interface">https://github.com/cyberphone/swedbank-psd2-saturn#swedbank-psd2saturn-interface</a><br>
<br>
Embedded credentials is the core of the Berlin Group Embedded SCA
tentative "upgrade" project.<br>
<br>
Regards,<br>
Anders<br>
<br>
<br>
<blockquote type="cite"
cite="mid:LNXP265MB0809E1EDF5E44087CF5F288EF6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM">
<div dir="ltr">
<div data-ogsc="" style="">
<div dir="ltr"><br>
</div>
<div dir="ltr">RB</div>
<div><br>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b> Anders
Rundgren <a class="moz-txt-link-rfc2396E" href="mailto:anders.rundgren.net@gmail.com"><anders.rundgren.net@gmail.com></a><br>
<b>Sent:</b> Friday, July 24, 2020 9:07:57 AM<br>
<b>To:</b> Ralph Bragg <a class="moz-txt-link-rfc2396E" href="mailto:ralph.bragg@raidiam.com"><ralph.bragg@raidiam.com></a>;
Financial API Working Group List
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-fapi@lists.openid.net"><openid-specs-fapi@lists.openid.net></a><br>
<b>Cc:</b> Nat Sakimura <a class="moz-txt-link-rfc2396E" href="mailto:nat@sakimura.org"><nat@sakimura.org></a><br>
<b>Subject:</b> Re: [Openid-specs-fapi] FAPI meeting request -
Mobile app access</font>
<div> </div>
</div>
<div>
<div class="x_moz-cite-prefix">On 2020-07-24 08:37, Ralph Bragg
wrote:<br>
</div>
<blockquote type="cite">
<style type="text/css" style="display:none">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Hi Anders,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Be interested to know where the specs technically don't work
for confidential clients on a mobile.</div>
</blockquote>
Hi Ralph,<br>
<br>
Is this what you mean with confidential client?<br>
<a
href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md#markdown-header-524-confidential-client"
moz-do-not-send="true">https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md#markdown-header-524-confidential-client</a><br>
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.<br>
<br>
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.
<br>
<br>
Anders<br>
<br>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
RB</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" face="Calibri, sans-serif"
color="#000000"><b>From:</b> Openid-specs-fapi
<a class="x_moz-txt-link-rfc2396E"
href="mailto:openid-specs-fapi-bounces@lists.openid.net"
moz-do-not-send="true">
<openid-specs-fapi-bounces@lists.openid.net></a>
on behalf of Nat Sakimura via Openid-specs-fapi
<a class="x_moz-txt-link-rfc2396E"
href="mailto:openid-specs-fapi@lists.openid.net"
moz-do-not-send="true">
<openid-specs-fapi@lists.openid.net></a><br>
<b>Sent:</b> Friday, July 24, 2020 6:20 AM<br>
<b>To:</b> Financial API Working Group List <a
class="x_moz-txt-link-rfc2396E"
href="mailto:Openid-specs-fapi@lists.openid.net"
moz-do-not-send="true">
<Openid-specs-fapi@lists.openid.net></a>; Anders
Rundgren <a class="x_moz-txt-link-rfc2396E"
href="mailto:anders.rundgren.net@gmail.com"
moz-do-not-send="true">
<anders.rundgren.net@gmail.com></a><br>
<b>Cc:</b> Nat Sakimura <a
class="x_moz-txt-link-rfc2396E"
href="mailto:nat@sakimura.org" moz-do-not-send="true">
<nat@sakimura.org></a><br>
<b>Subject:</b> Re: [Openid-specs-fapi] FAPI meeting
request - Mobile app access</font>
<div> </div>
</div>
<div>
<div name="x_x_messageBodySection">
<div dir="auto">Hi.<br>
<br>
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?</div>
</div>
<div name="x_x_messageSignatureSection"><br>
<div dir="auto">Nat Sakimura
<div dir="auto">Chairman, OpenID Foundation </div>
<div dir="auto"><a class="x_moz-txt-link-freetext"
href="https://nat.sakimura.org"
moz-do-not-send="true">https://nat.sakimura.org</a></div>
</div>
</div>
<div name="x_x_messageReplySection">2020年7月24日 15:04
+0900、Anders Rundgren <a class="x_moz-txt-link-rfc2396E"
href="mailto:anders.rundgren.net@gmail.com"
moz-do-not-send="true">
<anders.rundgren.net@gmail.com></a>のメール:<br>
<blockquote type="cite">Hi FAPIers,<br>
<br>
Currently FAPI methods are only accessible by TPPs.<br>
<br>
This may be "by design" but it also makes the API less
universal and force banks to create competing APIs.<br>
<br>
As an example some mobile wallets provide real-time
account balances. This obviously requires a direct call
to the associated bank.<br>
<br>
Could we have a meeting on this topic?<br>
<br>
Sincerely,<br>
Anders Rundgren<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
<br>
</body>
</html>