WPWG Virtual Meeting

22 Oct 2020



Ian Jacobs (W3C), Hervé Robache (STET), Anne Pouillard (Worldline), David Benoit, Tetsuya Kono (JCB), Chris Dee (FIS Global), Takashi Minimii (JCB), Jonathan Vokes (FIS Global), Myungho Han (INCA), Frank Hoffmann (Klarna), Olivier Maas (Worldline), Nick Telford-Reed, Jean-Michel Girard (Worldline), Gavin Shenker (Visa), Fawad Nisar (Discover), Mathieu Hofman (Stripe), Adrian Hope-Bailie (Coil), Danyao Wang (Google), Dave Fortney (TCH), Giulio Andreoli (Apple), Bryan Luo (Amazon), Jeff Hodges (Google), Gerhard Oosthuizen (Entersekt), Ortwin Scheja (Berlin Group), John Fontana (Yubico), Joshue O'Connor (W3C), Stephanie Rieger (Yiibu), Andy Estes (Apple), Erhard Brand (Entersekt), Mahesh Kulkarni (Samsung), Ciciley Nelson, Mustaq Ahmed (Google), Clinton Allen (American Express)
Nick Telford-Reed


Open Banking Updates

Herve: Hi all. Here's the update on PSD2 APIs in France
... since we met last the European Banking Authority published an opinion that created some obstacles for provisioning PISPs and AISPs.
... the French regulatory authority surveyed 14 French banks
... the August results are "75% ok"
... each French bank has at least one compliance issue with the new opinion
... either due to incomplete implementation of the STET API, or "extra-API" features
... What we saw in August is that for AIS things are "pretty good"
... with roughly 80 million requests from TPPs to French banks
... what's more August is a holiday month, so this are pretty good numbers
... ...banks have also begun to transition from screen-scraping to the API
... PISP activity remains, however, pretty low
... the API issues raised during this review are small in number, e.g., related to API data field meaning, or missing fields
... we are working with banks to clarify these points
... version 1.5 of the API will be published next week
... there are 51 changes, 27 are small clarifications, 16 are minor corrections (e.g., adding optional fields for info to the TPP)
... there are 8 major changes such as new resources or API entry points
... for post 1.5, we continue our coordination with other API efforts like the Berlin Group, as well as EBA (including Open Banking Europe), and SWIFT (on convergence of API data models within ISO 20022)

IJ: Would SPC be interesting in open banking?

Herve: It could be useful, but there needs to be a lot of work on other features (e.g., app-to-app)
... that is, frictionless redirect between TPP app and Bank App
... that's the main focus for banks nowadays

IJ: What about web authentication adoption by banks in Europe? Any obstacles?

Herve: Web authentication is not a focus currently. We are more focused on Oauth2 approaches
... and enhancements like FAPI

<Zakim> nicktr, you wanted to ask about PISP market

NickTR: You mentioned that there had been 80 million requests around AISP, but less initiation (PISPs)
... could you share thoughts on what is stopping the PISP model from building momentum?

Herve: There are two factors. The first has to do with French specificity regarding payment. About 70% of transactions in France are card-based, so transitioning to credit transfer or instant payment is a change for users and will require some time
... the second factor [no pun intended] is that payment initiation involves more complexity (cf ISO 20022 structures)
... we tried to simplify the structures in JSON but there is still complexity within the structure. TPPs and banks need more time to figure out how to handle these structures efficiently
... I do think we are on the way up the ramp for PISPs, however.

Ortwin: Thank you for the chance to provide a Berlin Group update
... first, implementation varies a lot by country
... mostly depending on whether there is a legacy market
... where there has been a legacy market, adoption is around 50%. Adoption is at times more challenging because of requirements related to fallback procedures in place (screen scraping)
... as herve said, there's a big challenge now on app-to-app redirection
... most NCAs (national competent authorities) have mandated this be dealt with by year's end
... I think the major topic is to get people to used to the new payment methods. It's more about user habit than UX
... The Berlin Group is rebranding to "Open Finance Task Force".
... we are starting to develop a full open finance API
... we will probably publish a roadmap in November for the next couple of years
... services for new account types, and full credit card capabilities on APIs
... you'll be able to separate authorization, reservation of funds, etc.
... these functionalities will begin to appear in the API
... and addition of "Request to Pay" functionality
... we are also discussing administration management APIs since this will all be accompanied by contracts
... we intend to support automation through the APIs (on-boarding, signing, pricing, etc.)
... it's a significant work package. we have two groups (business and technical sides) starting to work on this
... It will be interesting to see how schemes arise around this.
... we imagine banking communities creating frameworks of contracts, e.g., for onboarding for such services
... I think this is in line with the EC's retail payment strategy.
... they are expecting banks to develop these sorts of programmes
... they also indicated their intent to "regulate this" whatever that means
... in any case there is support from the regulatory side
... I expect most of the work will be done next year

NickTR: I don't really understand the nature of the relationship between the Berlin Group and the scheme formerly known as "PEPSI"...are Berlin Group involved?

Ortwin: No, not directly. Now it's called "EPI"
... if you see the requirements from EC on SCT INST support for Pan-European payment solutions, a potential connection could make sense from an architecture point of view.

<Zakim> AdrianHB, you wanted to ask about clearing systems offering APIs

AdrianHB: Regarding the integration cost and complexity. You mentioned "Frameworks" to help. One way I've seen this addressed is, for example, in India there is "integration in the center". PISPs can integrate into the registry.
... do you see that happening in Europe to accelerate this process?

Ortwin: I think this would happen in the market. I see huge clearing houses starting to work on this, as well as huge processors offering connectivity services
... so I think it will happen but will be market driven.

AdrianHB: Would this exempt banks from regulation?

Ortwin: This is already supported by API providers. Processors are offering the services; if they are using certificates and it's outsourcing, then banks don't have to do this themselves

NickTR: Thanks to Herve and Ortwin for the updates!
... makes sense to me that AISP activities would take off first. Glad to hear PISP moving forward as well.

Ortwin: The EC's retail payment strategy could include a price regulation for SCT INST, which would probably support the usage of SCT INST via APIs e.g. in eCommerce.

Web Monetization

[AdrianHB slides providing Web Monetization update]

AdrianHB: Recall that Web Monetization is a declarative approach where sites can provide a URL (via LINK element) where they can accept payments.
... the browser can stream payments to this payment pointer
... we are experimenting with users being able to send tips and donations to these payment pointers
... to accept payments, the merchant creates a wallet that talks to the interedger network.
... they get a payment pointer corresponding to that wallet
... ...each time the browser queries the URL, it gets back a UNIQUE address on the inter ledger network (plus some secrets)
... the site can listen to the "monetizatinprogress" event as money streams to the payment pointer
... and the site can take actions in response to receipt of funds, such as removing pay wall, showing confetti, etc.
... we've had a lot of experimentation in the past year by content providers and platforms.
... e.g., Cinnamon is a video-hosting platform. When people view videos on the platform, the streaming funds go to the video creator, not the platform.
... we've also had experiments with games platforms, some publications
... there's a contest we saw for small games (under 13K) where the game can be enhanced if the user pays through web monetization
... we worked with Igalia to have code added to chromium to track deployment of web monetization
... although the deployment is small, it's been slowly increasing
... in terms of browser support, there are Coil extensions. Mobile is a big challenge due to lack of extension support
... but there are interesting developments especially on the "sending funds" side
... the Coil extension is open source
... meanwhile, the Interledger rails continue to expand
... we have focused more on Fintechs than banks
... for them (like Uphold, Gatehub, Stronghold), it amounts to implementing an API
... the average size of a payment is less than 1 penny USD

Ian: What use cases are common for streaming payments?

AdrianHB: The streaming is perhaps a red herring. We don't want to limit this to streaming use cases. At the moment, the way Coil's extension works (outside the standard), there is a monthly subscription fee. The arrangement we have with our users is that Coil will distribute funds to monetized sites.
... we think that low-value discrete payments will be a big use case (tipping, donations)
... an easy way to think about use cases is how people make digital goods purchases in apps...low-value frictionless payments today in closed loop systems...we want to move those to an open loop model
... We are also looking at other open payments ideas like P2P beyond Web monetization
... so check out: openpayments.dev
... Web monetization is, essentially, the first deployed use case for open payments on the inter ledger network, where payment pointers are payment instruments.
... meanwhile, we've launched the Interledger Foundation in 2020 to build the Interledger network and develop the protocols further
... we see an opportunity for (1) rails for low-value payments and (2) open protocols for wallets and services that sit on that.
... we also announced Grant for the Web, and we'll talk about that next week during TPAC breakouts
... grant for the Web goal is to boost the use of alternative monetization models on the web
... they announced some flagship grants this week for about $7.5M.
... I understand the goal is to have the fund fully committed within 5 years

Ian: How do PR API and PH API connect to this?

AdrianHB: Very tightly. See our Rafiki demo.
... ...most of the experiments we did with the Rafiki money wallet used Payment request with graceful fallbacks. We see "Open Payments" as a payment method
... and if the user has a wallet that supports open payments, they would have a wallet that can dereference payment pointers
... we have a rough idea for using OAuth for authentication (inspired by open banking initiatives)
... but all this revolves around URLs, REST, and content types...so very Web architecture grounded

Danyao: A lot of the closed loop options provide not just low value digital payments, but other services like inventory management
... how easy is it for developers to add the auxiliary services on top of low-value payments? And how important is it to provide those extras?

AdrianHB: We don't have a lot of experience yet.
... the only development we've seen rolled it relates to receipts.
... but I agree with you. The biggest service you get from an app store is discovery and distribution. But the Web offers those services differently (e.g., search, links)
... payment is often integrated into services like subscriptions that include more than just the payment part

AdrianHB: short answer: agree and we don't have a lot of experience yet

NickTR: Check out the Breakouts for TPAC 2020 next week

<AdrianHB> In particular the monetization breakout

IJ: Will there be blood on the floor?

AdrianHB: No. :) The question we posed is "what is the role of standards?"
... how much revenue-generating pie other than advertising do we expect, and how would standards support it?

Real-time payments (RTP) and registration for bill pay

Dave: I'll speak about TCH's RTP network and a bill pay use case
... it should become apparent that some of the APIs discussed in the WPWG could be relevant for the bill pay use case
... facilitating a direct deposit payment.
... Payments settle in real-time through a dedicated account that TCH maintains with the US Fed.
... settlement is final
... the network has a confirmation for every message. This is different from other payment systems where it's assumed all is well unless you hear otherwise.
... transactions are posted in real time to the receiving account at the receiving institution
... the network uses credit transfer (push)
... we do have an interesting feature "request for payment" that is live in the network
... so I could, for example, request a payment from Ian and Ian could accept or reject the request
... that's the closest we come to a "debit"
... the payer always controls which funds are paid from their account
... there's no concept in the network for a party to be able to pull funds from an account
... the whole thing is built on ISO 20022 standards.
... this gives us building blocks for internationalization, even if that doesn't exist yet
... the hope is that by having most of these systems on ISO 20022, connections in the future will be easier (even if there will be legal / regulatory friction)
... regarding bill pay, over the last decade there's been a shift in how consumers pay bills. First, more electronic (less check)
... within the electronic category, there is more desire to interact directly with the biller's Web site
... rather than interacting with the bank site
... top 7 bill categories: electricity, credit card payments, cable/internet, phone, oil/gas, water/sewer, auto insurance....and the rest is about 50% of volume
... We are interested in leveraging RFP and RTP features for some bill pay use cases, and taking advantage of built-in confirmation message.
... we imagine primary interaction on biller web site, but authentication happening directly with the bank
... the mockups earlier this week (SPC) are relevant for this pattern

[Dave shows some prototype of user experiences]

Dave: In first mockup, the user receives a push notification on a mobile device. The message indicates that there is a new bill; this is a request for payment to the consumer's bank.
... the user goes to the bank app / site to manage requests for payment
... the user might find multiple requests, and those requests already confirmed and denied
... next slide shows details that could be displayed about the biller, the bill itself. The bank app can show details, or redirect the user to the biller for more details.
... then the user can confirm the payment...and due to round-trip nature of the network, time will be required; a slide shows the user that the payment was successful.
... We are also interested in not propagating user account information; thus we are interested in tokenization of account information
... some advantages like origin-binding, lifecycle management
... part of consumer registration experience could involve open banking (or "connected banking") experience where the consumer goes through an OAuth step to authorize the sharing of payment account credentials with a third party, and an option to share that info in tokenized form

nicktr: We heard earlier in the week about QR use cases. QR and RFP seem like a natural pairing. Is that something you are investigating?

Dave: The short answer is "yes."
... this is not a new idea. But it may make more sense once billers have embraced the idea of real-item payments more broadly.
... a QR code could help expand usage, but I think there needs to be some adoption before this would make sense.
... larger billers, in my opinion, are probably going to prefer registration at the biller's web site
... consumers already recognize that pattern

Ian: What is role of WebAuthn style authentication in these flows?

Dave: I see that happening at registration time to receive requests for pay (even if one-time experience is also an option)
... the highest friction occurs during what amounts to guest checkout.
... which typically involves form fields and validation of some data.
... user authenticates payments to the bank app (or delegated partner)

IJ: Are banks interested in the customer visit, or in delegation?

Dave: Banks will want what the consumers prefer. Today the experience is new to consumers.
... some banks have not yet provided visibility to RFP
... I think as they do, consumers will go to banks
... then over time consumers will migrate to other parties through delegation.

NickTR: If you had a magic wand and could get this WG to add capabilities you need for RTP/RFP, what would it be?

Dave: I think conceptually, checkout and bill pay will look very similar. That would be an interesting exercise to try out a real bill pay flow and identify what is in fact different. That would help us identify missing features.

Ian: Can we take offline whom to recruit (bank, biller) for experimentation?

Dave: Yes.

Wrap-up / next steps

NickTR: We saw a bunch of interesting topics this week. Want to take some time to start to build shared vision of priorities over the next year.
... I have a strawman proposal

1) Get PR API 1.0 => Recommendation

2) Advance SPC

3) Continue to flesh out SRC support

4) Adoption

danyao: Regarding adoption, we need to (1) make sure current payment flows still work in the face of browser changes around privacy, for example. (2) helping merchants to adopt new APIs (e.g,. SPC)...basically doing things better
... I think that "making things don't break" is a higher priority than "doing new things"

NickTR: Thank you for calling out that point

Danyao: Regarding Chrome, we are very interested to work with developers to ensure that privacy changes don't break things. I expect we will pick up our previous privacy analysis work.
... e.g., 3p cookies to be deprecated by 2022.
... the chrome team is interested in fleshing out how these changes will affect payment flows, and what new features are needed before the 2022 deadline

AdrianHB: +1 to Danyao's comments, but I think the WG can work in parallel. Some of the new things are also envisioned to help some other things from breaking.
... I'd like for us to think about what new things we can add will support existing payment experiences and use cases.
... so a lot of the architecture thinking revolves around this question: keep things working when capabilities change AND improve the UX
... I would add to NickTR's list something related to "Alternatives to payment handlers"
... also some interesting discussion happening around managing privacy concerns related to hasEnrolledInstrument.
... I am interested in supporting two flows: (1) through payment handlers .... supported by Chromium browsers (2) via the merchant site.
... the latter case can allow for fallback flows where payment handlers are not supported.

NickTR: Priority?

AdrianHB: Should be considered in parallel with SPC.

Gavin: +1 to Danyao and Adrian. We'd like to support SRC and 3DS in the face of changing browser behavior around cookies

Ian: Do the revised hypotheses I shared on Monday align with the list of priorities that emerged here? Adrian today mentioned "two paths" that we should be considering: payment apps and merchant-side. Different use cases may call for one path more than another. Or some parties may prefer one path over another. Or the "merchant-size" path might be a fallback when there is no payment app in the user's environment or their browser doesn't support payment apps. I like this model and it suggests that we will want to do more work to identify core capabilities (per the architecture discussion on Tuesday) and ensure they are available "on both sides." This may or may not lead us to change the APIs (e.g., by breaking out capabilities into smaller components). I agree with Danyao re prioity of implementation and pilot around SPC, but also with Adrian re doing things in parallel related to architecture. The reason for that is that we need to keep engaging with many stakeholders to ensure core capabilities align with reqs so that when we are ready for experimentation, the designs are already well-informed by real-world flows.

NickTR: Interested in hearing from browser vendors on these topics. Have heard a bit from Chrome.

Danyao: We are also interested in combining form-fill gestures and SPC authentication to reduce friction. No details yet.

NickTR: Any Apple perspectives to share at this time?

Andy: Nothing to share at this time. I have appreciated the sessions this week and regret I've been less involved in the payments work this year.
... I can share more thoughts by email later.

Mahesh: From a Samsung perspective, we've been following the work closely
... we'd like to see how SPC works on desktop and then see how it can work in a mobile context with Samsung Internet Browser

NickTR: Any other opportunities for work that we've not yet covered?

Clinton: Over the past few months leading up to TPAC 2020 I had thought we had lost some momentum. This meeting has been extremely successful in bringing us back to a sense of direction and urgency.
... Congrats on hitting the objectives we discussed in September.

Merchant Business Group

NickTR: Short pitch for the newly formed Merchant Business Group, newly formed (and for which I am the staff contact). We want merchant input on Web payments but have consistently heard feedback that the WG meetings can be too technical.
... the business group will NOT develop specifications (making IPR commitments easier)
... we have two co-Chairs: John O'Brien (FIS) and Melanie O'Brien (Coles in Australia). (No relation)
... Melanie's background is on accessibility, indicating broad remit of the BG
... this is a call for your help in helping to get this group off the group
... I may call on you to present to the BG to share your initiatives, and to hear from merchants on problems they are facing
... our hope is that we will have merchants of different sizes, as well as merchant orgs like Conexxus, MAG, and Vendorcom
... our first meeting will take place on 26 October.

Clinton: Regarding the Merchant BG, do we have to join the group to get involved?

Join the Merchant BG

NickTR: Note that W3C Members can join (through their AC rep)
... people are welcome to attend the first meeting as guests.

Next WPWG calls

Canceled: 29 October call

Next full WPWG call: 12 November

NickTR: Thanks to all!!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/10/23 13:56:25 $