<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">there is work underway to converge UK OB, STET and NextGenPSD2 in the context of Swift. It currently covers the data model but the API is in scope as well.</div><div dir="ltr"><br></div><div dir="ltr">At the FDATA summit representatives of NextGenPSD2 and UK OB recently recommended to invite FAPI to join this activity and to contribute the security piece (or the authz/SCA part to this activity.</div><div dir="ltr"><br></div><div dir="ltr">It will take time but I’m confident we will see a single standard emerging for payment initiation. And ECB’s pressure plays an important role.</div><div dir="ltr"><br></div><div dir="ltr">best regards,</div><div dir="ltr">Torsten.</div><div dir="ltr"><br><blockquote type="cite">Am 07.12.2019 um 10:10 schrieb Stuart Low via Openid-specs-fapi <openid-specs-fapi@lists.openid.net>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8">Hi Anders et al.<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class=""><div class="">This recent speech by an ECB board member echoes what I have been saying for quite some time:<br class=""><a href="https://www.ecb.europa.eu/press/key/date/2019/html/ecb.sp191126~5230672c11.en.html" class="">https://www.ecb.europa.eu/press/key/date/2019/html/ecb.sp191126~5230672c11.en.html</a><br class="">    "progress at the back-end has not translated into similar progress at the front-end, which<br class="">     remains fragmented, with no European solution emerging for point-of-sale and online payments”</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">Although not useless, FAPI does not address this problem. It is obvious that a more complete standard is needed in order to succeed.  I'm well aware of that this is out of scope for FAPI.<br class=""></div></div></blockquote><div><br class=""></div>I think “FAPI” is a more broad definition for “financial grade” so from a scope basis “it depends”. Most of the historical work has been on “profile” overlays to OIDC specs but there is plenty of work evolving by working group members that is more focused on “features”. I assume partially as a result of OIDF influence it’s been focused on the identity side of things rather than payments and now some of this evolution is converging (“identity to make payment”).</div><div><br class=""></div><div>There is also an entirely non-technological elephant in the room with respect to payment providers considering the nearly all large global payment providers are from the U.S, are duking it out with each other and are intimately involved in the international monetary system. I’m not actually confident even a reasonable number of these participants actually <i class="">wants</i><span style="font-style: normal;" class=""> it to be a unified experience.</span></div><div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">The regulators' hope that PSD2 and Open Banking would create a more "vibrant" payment market is based on a poor understanding of how things actually work.  Well, if Europe establishes a PISP monopoly or oligopoly there could be a solution but that seems like the opposite to what was promised.<br class=""></div></div></blockquote><div><br class=""></div><div>It’s still early days to make a call on PSD2/OB, and really really early globally. Bureaucratic types can be oblivious to the realities, but some financial services systems are closing on 30 years old so pragmatically we are 1-2 lifecycles from seeing many of the true benefits.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Therefore I continue claiming that a decentralized TTP-less solution like the Open Banking Wallet (OBW) is more suited for creating an interoperable consumer payment market.  OBW though requires a [technically] minor patch in FAPI to succeed: <a href="https://cyberphone.github.io/openbankingwallet/adapting-open-banking-apis" class="">https://cyberphone.github.io/openbankingwallet/adapting-open-banking-apis</a><br class=""></div></div></blockquote><div><br class=""></div><div>While in principle I see major advantages to decentralisation I’m not convinced it’s necessary for interoperability. RAR seems like it’s heading in a good direction whereby the “container” of the request is fairly rigid but the metadata it contains is flexible. This seems like a good pathway (and, as I understand it, an evolution of lodged intent) to bridging the idealistic self sovereignty/identity with the commercial realities. I suspect this bridge will be “current generation” and a decentralisation solution will emerge using this payload structure in the “next generation”</div><div><br class=""></div><div>With reference to “Patch to FAPI”. I’m going to assume this is a reference to FAPI-R/RW. FAPI-R/RW is a profile, there is an argument here that this doc makes changes to upstream specs versus simply tweaks some clauses in FAPI.</div><div><br class=""></div><div>Specifically on the content, point by point:</div><div><br class=""></div><div>1. This assumes key exchange has already occurred with a potentially uncontrolled client? If so, this is either a significant friction point for M:N distribution of keys OR a copy of the fragmented commercially driven providers we have already</div><div><br class=""></div><div>2. This is a modification to the oauth2 specification and seems like a material change to the understood workflow (token introspection seems to provide the identifier that’s been proposed to inject here). I’m also ideologically uncomfortable with deliberately binding system token information with business token (ie. identity) information.</div><div><br class=""></div><div>3. I can’t comment on the standard but “friction” has some identified benefits with respect to users agreeing to disclose information. Maybe it’s jurisdictional but part of the challenge with the “global data corps” has been how smooth they have made disclosure by people, who may regret such a decision.</div><div><br class=""></div><div>4. Unlimited lifespan access as a default seems like a dangerous baseline to accept. Requiring refresh token cycling support (in OAuth it is optional if memory serves) would achieve this goal without the open ended static use of a refresh token.</div><div><br class=""></div><div>5. So reading this, I come back to (1). Firstly, there’s some legal bounds here, in Australia for instance consent must be explicit, essentially irrespective of the technology abstraction in use. Secondly, if the intent is to have each peer trust the other peers CA it’s either a replica of existing arrangements or a recreation of a solved problem (ala blockchain).</div><div><br class=""></div><div>6. There are direct flow on effects on fraud exposure here. Maybe they are acceptable, maybe they aren’t, suffice to say it would need appropriate risk assessment to be able to accept.</div><div><br class=""></div><div>Just my 2c,</div><div><br class=""></div><div>Stuart</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div></div></div><span>_______________________________________________</span><br><span>Openid-specs-fapi mailing list</span><br><span>Openid-specs-fapi@lists.openid.net</span><br><span>http://lists.openid.net/mailman/listinfo/openid-specs-fapi</span><br></div></blockquote></body></html>