[Openid-specs-fapi] ECB: On-line Payments Remain Fragmented

Anders Rundgren anders.rundgren.net at gmail.com
Sat Dec 7 10:35:03 UTC 2019


On 2019-12-07 10:10, Stuart Low via Openid-specs-fapi wrote:
> Hi Anders et al.
> 
>> This recent speech by an ECB board member echoes what I have been saying for quite some time:
>> https://www.ecb.europa.eu/press/key/date/2019/html/ecb.sp191126~5230672c11.en.html
>>     "progress at the back-end has not translated into similar progress at the front-end, which
>>      remains fragmented, with no European solution emerging for point-of-sale and online payments”
>> 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.

Hi Stuart,
The change document I referred to should be viewed in the context it supposed to run in.

The core idea is taking EMV into the 21:st century (it was created 1993) where "always connected" and "instant transactions" is the norm.

EMV is the gold standard (in the west...) for payment authorization in the physical world.  Apple pioneered a variant of that for on-line.  OBW takes this notion one step further by eliminating card networks (=achieving decentralization on the "frontend"), through an upgrade of the "card" concept as well as through some rather nifty lookup services.

Although I can't prove it since most pay-ish stuff is heavy guarded by NDAs and secrecy, I believe most of the pretty successful mobile payment systems out there actually build on similar ideas as OBW when it comes to the client side which is at odds with the OAuth way of doing things.  The good news is that the APIs (which probably represent >95% of the code base) remain intact.

Regards,
Anders

> 
> 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”).
> 
> 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 /wants/ it to be a unified experience.
> 
>> 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.
> 
> 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.
> 
>> 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: https://cyberphone.github.io/openbankingwallet/adapting-open-banking-apis
> 
> 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”
> 
> 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.
> 
> Specifically on the content, point by point:
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> Just my 2c,
> 
> Stuart
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 



More information about the Openid-specs-fapi mailing list