[Openid-specs-fapi] External : Open Banking NG

Anders Rundgren anders.rundgren.net at gmail.com
Thu Oct 31 13:29:05 UTC 2019


On 2019-10-31 12:40, Rob Otto via Openid-specs-fapi wrote:
> here's another example using a different variation of the above, but still enabled by CIBA
> 
> https://www.youtube.com/watch?v=6Z3YJd2r0qE

Thanx Rob,

My problem (well, it is actually not only "my" problem), is that outside of the UK, mobile phone based payments have already gained huge traction and most of these solutions are not based on OAuth2/PISP. "Consents" (with respect to a TTP) is an largely unknown term whereas SCA is a part of the payment platform itself.

Another important part of the "puzzle" is the relationship between mobile banking apps and payment apps. My "thesis" (FWIW) is that they should separated because if you deploy client keys like in Apple Pay (and in https://cyberphone.github.io/doc/payments/dual-mode-openbanking-api.pdf#page=2), the dependencies become close to none; merging them only slows things down.

The condensed rationale: Banking/Financial Services <<>> Consumer Payments and do not necessarily gain by being cast in the same API.

Anyway, standardization in this space is hard, very hard, as proven by this recent blog from the W3C Payment WG Chair:
https://www.w3.org/blog/wpwg/2019/10/28/the-evolution-of-payment-request-api/
If you read between the lines it seems that the W3C still are (after 5 years+ of WG activity), quite unsure of what to do. Personally I claimed early on (and to many people's great dismay), that there is no need for a specific Payment API in browsers, only "primitives" enabling other parties developing whatever Payment APIs they want.

Kind regards
Anders Rundgren

> 
> On Wed, 30 Oct 2019 at 16:35, Chris Michael via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
> 
>     Hi Anders
> 
>     The OBIE example below is where all non-essential steps are removed from a redirect authentication. This solves some use cases but, as you state, is notb as good as Apple Pay, especially in a Point of Sale scenario. It would however work for an app-app (e.g. online purchase via a mobile app) scenario.
> 
>     As I am sure you are away, the CIBA standard we developed with/by FAPI WG members does allow much better UX which gets closer to Apple Pay. This is also included in the OBIE standard. However, no ASPSPs are implementing this yet, as it has not been specifically required by any regulators at this time.
> 
>     Here is a working demo of one of the 4 x supported CIBA flows
>     https://www.youtube.com/watch?v=SXiRhCAYRCE
> 
>     I like your concept below, however creating additional TPP roles may take some time for the industry to get to grips with
> 
> 
> 
>     Chris Michael
>     Head of Technology
> 
>     +44 7767 372277
>     http://www.openbanking.org.uk
>     2 Thomas More Square, London E1W 1YN
>     Twitter | Facebook | LinkedIn
> 
>     ________________________________________
>     From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net <mailto:openid-specs-fapi-bounces at lists.openid.net>> on behalf of Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>>
>     Sent: 30 October 2019 15:49
>     To: Financial API Working Group List
>     Cc: Anders Rundgren
>     Subject: External : [Openid-specs-fapi] Open Banking NG
> 
>     Hi FAPIers,
> 
>     This picture from OBIE shows a payment scenario that is very far from Apple Pay:
>     https://standards.openbanking.org.uk/wp-content/uploads/2019/06/4.1.1-Wireframe.png
>     Yeah, using various kinds of "workarounds and fixes" it can surely be improved, but will that really scale?
> 
>     I have updated the "Dual-mode" Open Banking API proposal which if implemented should make Open Banking payments entirely "on par" with Apple Pay but with the added advantage that it builds on A2A (Account-to-Account) transactions which also is compliant with P2P (Person-to-Person) payments:
>     https://cyberphone.github.io/doc/payments/dual-mode-openbanking-api.pdf
> 
>     To make the proposal more acceptable I have introduced an (optional) TTP role which (unlike PIS) is already known by payment professionals; the Payment Gateway.
> 
>     WDYT?
> 
>     Thanx,
>     Anders
> 
>     On 2019-10-22 07:16, Anders Rundgren wrote:
>      > A months has passed and it begins looking quite promising:
>      >
>      > https://www.linkedin.com/posts/andersrundgren_open-banking-api-saturn-my-subversive-activity-6591608038912729088-31sr
>      > Updated: https://cyberphone.github.io/doc/saturn/openbanking-api-for-saturn.pdf
>      >
>      > Anders
>      >
>      > On 2019-09-21 10:26, Anders Rundgren wrote:
>      >> This is probably not a use case people subscribed to this mailing list is particularly interested in.
>      >> However, there are a couple of reason why this is a relevant issue:
>      >> - If the bank can use the API themselves it will likely be better maintained
>      >> - If the consumer payment market rather prefers schemes like Swish, TWINT, MobilePay https://empsa.org/ , <https://empsa.org/> FAPI and similar Open Banking APIs could fall in importance
>      >>
>      >> FWIW, I have just started (yesterday...) to investigate how Open Banking APIs could work in a local scenario:
>      >> https://github.com/cyberphone/swedbank-psd2-saturn
>      >> Swedbank uses the Berlin Group API but I guess the differences (on a higher level) compared to FAPI are not that big.
>      >>
>      >> Anyway, since I'm not versed in OAuth2, I wonder if anybody out there have any ideas how to "patch" OAuth2 in such a way that an Open Banking API implementation could work in both local and remote mode without moving [too] many parts?  Local mode = trusted service not needing user consent.
>      >>
>      >> Cheers,
>      >> Anders
>      >>
>      >
> 
>     _______________________________________________
>     Openid-specs-fapi mailing list
>     Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 
>     Please consider the environment before printing this email.
> 
>     This email is from Open Banking Limited, Company Number 10440081.  Our registered and postal address is 2 Thomas More Square, London, E1W 1YN.  Any views or opinions are solely those of the author and do not necessarily represent those of Open Banking Limited.
> 
>     This email and any attachments are confidential and are intended for the above named only.  They may also be legally privileged or covered by other legal rights and rules.  Unauthorised dissemination or copying of this email and any attachments, and any use or disclosure of them, is strictly prohibited and may be illegal.  If you have received them in error, please delete them and all copies from your system and notify the sender immediately by return email. You can also view our privacy policy (https://www.openbanking.org.uk/privacy-policy).
>     _______________________________________________
>     Openid-specs-fapi mailing list
>     Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 
> 
> 
> -- 
> <https://www.pingidentity.com>Ping Identity <https://www.pingidentity.com>		
> Rob Otto	
> EMEA Field CTO/Solutions Architect	
> robertotto at pingidentity.com <mailto:robertotto at pingidentity.com>	
> 
> c: +44 (0) 777 135 6092	
> 
> Connect with us: 	Glassdoor logo <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>	LinkedIn logo <https://www.linkedin.com/company/21870> twitter logo <https://twitter.com/pingidentity>	facebook logo <https://www.facebook.com/pingidentitypage>	youtube logo <https://www.youtube.com/user/PingIdentityTV>	Google+ logo <https://plus.google.com/u/0/114266977739397708540> Blog logo <https://www.pingidentity.com/en/blog.html>	
> 
> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ><https://www.pingidentity.com/en/events/d/identify-2019.html>
> 
> /CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you./
> 
> _______________________________________________
> 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