Agenda · 27 May minutes · 28 May minutes
<Ian> Adrian: Thanks everyone! It's late for some; thank you!
<Ian> ...be gentle on us, this is our first code-a-thon (in person or virtual)
<Ian> AdrianHB: Welcome Viji from GSMA
<Ian> NickTR: Welcome all
<Ian> meeting page
<Ian> PH starter kit
<Ian> Anne_Pouillard (Worldline)
<Ian> Anne: We've been working with the APIs for several months. We have already created some demos
<Ian> ...we are very interested in the "minimal UI" proposal
<Ian> ..we'd also like to work with Web Authentication via the "minimal UI"
<Ian> ...we have to address PSD2 requirements around Strong Customer Authentication
<Ian> Arno from Entersekt
<Ian> Minimal UI explainer: https://gist.github.com/rsolomakhin/eba91c185028899883d2c7f37f357d7c
<Ian> Test instructions: https://groups.google.com/a/chromium.org/forum/#!searchin/paymentrequest/minimal$20ui%7Csort:date/paymentrequest/MV9YCOVg54Q/fQLswvcjBAAJ
<Ian> Gehard_Oosthuizen (Entersekt)
<Ian> Gerhard: We've been using the APIs for a while. We would like to focus on payment handler adoption
<Ian> ...bootstrapping of payment handlers to enable more interoperable examples of them
<Ian> Erhard_Brand (Entersekt)
<Ian> Erhard: We are interested in payment handlers
<Ian> John (from Entersekt as well)
<Ian> Brandon_Every (Modo Payments)
<Ian> Brandon: I'm focused on front end
<Ian> David_Devor (Modo Payments)
<Ian> David_Devor: We plan to contribute to a team.
<Ian> Bryan_Luo (Amazon Pay)
<Ian> Bryan: I'm interested in the brainstorming!
<Ian> Cairin (from Coil)
<Ian> ...we have worked on the Rafiki money demo (payment handlers, minimal UI)
<Ian> Donovan (Coil)
<Ian> Donovan: We're been working on payment handlers for a while
<Ian> Matt_de_Haast (Coil)
<Ian> Matt: Want to figure out how payment apps can create an open ecosystem for payments on the web
<Ian> Danyao_Wang (Google)
<Ian> Danyao: I'm really interested in payment handler use cases.
<Ian> ...looking for feedback on APIs and how to support use cases.
<Ian> ..most interested in minimal UI and Web Authn
<Ian> Rouslan_Solomakhin (Chrome): I am available as a resource to understand how the APIs work
<Ian> ...very interested in minimal UI and payment handlers
<Ian> ...how to build the best, slickest payment experience on the web
<Ian> MaxLG (Chrome)
<Ian> maxLG: I have been working on API usage with play store..and also created the starter kit
<Ian> ...interested in feedback on APIs and implementation in chrome
<Ian> Dom_Hazael-Massieux (W3C)
<Ian> ...I'm interested in WebAuthn and launched a relevant Community Group about adoption
<Ian> Olivier_Maas (Worldline)
<Ian> Rob_Martin (Capital One)
<Ian> Sebastian_Giraldo (Worldline)
<Ian> Sebastian: I am an intern interested in these APIs
<Ian> Viji_Pathy: GSMA. I am the API architect for mobile money
<Ian> ...interested in a POC for integrating mobile money into a payment handler
<Ian> ...some use cases include bill payments, for example.
<Ian> Rob: I am interested in integration of card on file and account creation use cases
<Ian> AdrianHB: Minimal UI is something the chrome team has been working on and Coil has been experimenting with to provide feedback
<Ian> ...one of the interesting things is that we've recently been talking about how Minimal UI could be used in conjunction with WebAuthn for a low-friction, high security flow
<Ian> ...currently available only on mobile
<Ian> ...in this flow, the payment handler does not create a window, but provides hints to the browser to render in native browser UX
<Ian> https://github.com/w3c/webauthn-pay/blob/gh-pages/proposals/pr-webauthn-txconf.md
<Ian> (Rafiki demo is animated gif therein)
<Ian> AdrianHB: We have a demo shop that sells virtual coffee.
<Ian> https://checkout.rafiki.shop/
<Ian> AdrianHB: We want to integrate the minimal UI with Web Authentication
<Ian> ...so the whole process includes a FIDO authentication. Currently the demo is just a presence check.
<Ian> Rouslan: Building this in the browser could be challenging (more than 2 days work ;)
<Ian> AdrianHB: If others would like to get a working version of getting minimal UI working, see our code and Rouslan's explainer
<Ian> Ian pitch
<nicktr> scribenick: nicktr
ij: authentication is a really
hot topic for us
... we have been looking at integration in many ways
... I would love to be able to show the payments industry the
work-in-progress and engender more enthusiasm
[Ian's slide#2 - Problem Statement]
ij: changes are happening in
browsers which are breaking existing capabilities in browser
fingerprinting and third party storage
... and we note something similar is happening in web
advertising
... [Goals]
... a flow where flows are preferred in this cascade order.
Minimal UI
... WebAuthn from payment app window
... Prompt user to return browser stored pw credentials
... prompt the user to enter name/pw
... [SCOPE]
... In scope: bootstrapping and minimal UI/payment app opening
window for user interaction
... Out of scope: Multiple profiles, payment app installation,
credential lifecycle management, shipping
... [DELIVERABLES]
... Demo and blog post
... [RESOURCES]
... How to Fido, decision tree
... doc on auto-sign in with Credential Management API
... Idea for CM API class of credential
... questions?
AdrianHB: You'd like to see a demo that uses CM to store the info?
ij: yes - maybe we can play with
CM to help fix the cookie problem
... or we could just rely on cookies
<Ian> https://www.w3.org/2020/05/18-paymentcredential.txt
ij: I have plausible deniability on this idea. It might be Adrian's bad idea or more great idea
Pre-provisioning video: https://www.icloud.com/iclouddrive/0SKKVU0frrbJ-zN9CgqrE4A2Q#Provision
QR based checkout: https://www.icloud.com/iclouddrive/0VuXvJqCpbj0Y_fWmWjOxBI6g#QR
<Ian> scribenick: Ian
[Erhard does a presentation]
Erhard: Two main use cases we are interested in:
- "Fast checkout": E-commerce push provisioning
- "Pay using QR code"
Erhard, for fast checkout:
- User can opt-in to register a bank payment app
- When next on a merchant site, the payment app can be used to authenticate to the bank
scribe: if that's successful, the bank can provide proof of payment to the merchant who submits it for the transaction
[We see a demo]
[It uses Webauthn as an option]
<Zakim> Ian, you wanted to ask why billing address is shown
(Answer: bug!)
[Collaboration opportunities around fast checkout code)
- User consent during installation step
- team up with a merchant to demo fast checkout
- set bank PH as "preferred payment handler"
- easier mechanisms to jump between mobile app and mobile browser and vice-versa
- Minimal UX
IJ: What's the coding complexity of a browser supporting a preferred payment app?
Rouslan: that might be a good starter project for someone on Chrome
IJ: I am interested in the global preferred payment app "Just use this one whenever it can be used."
Rouslan: That's feasible. The first 80% would be really easy and the last 20% challenging.
[Arno on Paying with QR code]
Arno: This would be for banks to
do
... the demo shows a JIT install of a payment app
... the merchant has a pay with QR code during checkout
... the customer uses a mobile app to scan the QR code
... authentication is up to the payment service provider
... if successful, the bank (or payment service provider) gives
back a proof of confirmation to the merchant
... in the demo, the user is purchasing something in a desktop
browser
... there's a Pay with QR code option
... JIT installation of payment app
... payment app shows a QR code
... QR code includes amount and merchant id
... then the user scans the QR code
... user does authentication on the server side
[Collaboration]
- We'd love to build a pay with QR code with a merchant
- Would like to see whether it could be possible to add native QR support in side of a payment handler
scribe: and using QR code as identification for future payments
ack
IJ: what does native support for QR codes mean?
Arno: We showed a Basic Card
payment
... the service worker would not necessarily have to open a
window in this use case
... could the browser natively show the QR code on the payment
handler's behalf?
AdrianHB: Could be alternative
authentication mechanism to WebAuthn
... I was wondering whether we could allow a fallback to
one-time pin as well...and could that be built into minimal
UI.
ask me
danyao: What is the advantage of showing the QR code in the PH instead of on a merchant page?
Arno: I think integration may be
easier
... I also think it looks nicer. The PH has nicer UI
... and the additional checks we can without using an
iframe
Gerhard: I think there's a good
opportunity for interop here.
... suppose there is a payment app that can bridge merchants
and banks.
... the banks can route the consent through the merchant
... supports independence: merchants don't need to support
every banks, and banks don't need to support every
merchant
... there are many forms of auth, the idea here is just to use
QR the first time
<Zakim> Ian, you wanted to ask about in-store use cases
IJ: Could be useful to do something QR-code based in an in-store setting (because of COVID)
Gerhard: I agree it could be used in a non-ecommerce setting. May not even need to be only about payments
John: We've also looked a loyalty
provisioning via QR codes
... Adrian mentioned OTPs
... it might be better for user to use other APIs (available on
iOS devices, for example) instead of typing in OTPs
AdrianHB: Those latch onto your keypad. You already have an input box. ....
John: It's like a URL that you are kind of selecting
AdrianHB: We've had some
discussion recently bout how we could have something that
combines minimal UI and webauthn
... and have it as the "ultimate goal" of web checkout,
especially on mobile
... the popup shows you who you are paying, how much, and
done.
... one appeal is consistency across sites
... but something that "counts against" this proposal is web
auth not yet available
... so can you have additional authentication approaches in the
same flow?
... so instead of seeing a fingerprint scanner, there's another
UX re: OTP
... and the decision of which authentication approach to use
would depend on some activity being done in the background in
the payment app
AdrianHB: What I'd like to solve
-- there is a large population of people with mobile money
accounts.
... People access those accounts through USSD
... you access menus with numbered options
<nicktr> link https://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data
AdrianHB: but as smartphones
become more widely available, there are opportunities to use
better UX for those payment methods
... I'd like to do a POC for paying online with your mobile
money account, via GSMA APIs
... so the idea is that the payment app represents the mobile
money provider.
... you authenticate to your payment app, and in the background
it submits info to the mobile money APIs
<Zakim> dom, you wanted to ask how many operators/subscribers interface with Mobile Money
dom: I am still a telco guy. :)
Isn't it the case that each operator has their own mobile money
service?
... so that's one payment app per operator?
AdrianHB: Yes
Dom: How many operators expose a mobile money endpoint?
AdrianHB: I don't know; can check
with Viji
... I thought of this as something like a standardized data
model, but perhaps one PMI per operator
... or the merchant specifies supported mobile operators as
input
https://raw.githack.com/ianbjacobs/webpayments/mobilemoney/proposals/mobilemoney.html
Dom: I'm interested in this
Ian: Any mobile operators you think might be interested?
Dom: +1 to involve operators, but depends on usage of the GSMA APis
This comes from https://www.w3.org/2019/09/15-wpwg-minutes.html#item07
IJ: The goal was harmonizing card
selection UX
... another idea is front-end updates
... but that's more complex due to need ot identify the
card
Rouslan: Cool idea; could be
combined with JIT installation
... would be harder to do with already installed payment
handlers.
IJ: I assume that the merchant or their PSP would pass a token or token identifier to the payment app
Rouslan: Goes like this:
* Merchant generates a UUID per card
* Creates 3 just-in-time installable payment handlers
* Passes the identifiers in the payment method data
* The sheet shows the (3) cards
* If the user selects one of those cards, then the merchant gets back the signal at that URL
* The merchant then replies with one bit
* Because the payment response includes the UUID, the merchant knows which card was selected
<nicktr> +1 that is an interesting use case - it allows card on file to be presented with a consistent payment request experience
IJ: Account creation was : pay me, then give ok to use data to create an account
<nicktr> You could also capture CVV in the one-off payment handlers (which is not stored)
<dom> [re mobile money, the GSMA publishes metrics about adoption/usage hhttps://www.gsma.com/mobilefordevelopment/m4d-tracker/mobile-money-deployment-tracker/]
1) How to add a bit of Ux to the browser to avoid PH UX
2) Focus on auth
scribe: what are auth paths that might have a standard UX ?
- webauthn
- OTP
- QR
- passwords
IJ: Any thoughts from the Chrome team?
Danyao: Could be interested.
----
AuthenTic
Minimal UI
Mobile Money
Faster checkout / provisioning
QR Code
Card on File
----
Danyao: We'd need to scope each
project
... Maybe we need a lead for each topic
<dom> [more data on mobile money, incl some more specifically on the GSMA API adoption https://www.gsma.com/mobilefordevelopment/wp-content/uploads/2020/03/Mobile-Money-API-Industry-Report-Towards-Seamless-Integrations-2.pdf]
Leads:
Danyao: Can we create subchannels
Q: Can people do more than one?
Danyao: Would be interested in starting with the ability to do more than 1
https://pad.w3.org/p/code-a-thon-poll
<nicktr> https://forms.gle/w26LEMzrpbYsyiaq7
<nicktr> https://docs.google.com/forms/d/18etlmjEd69Ddl-hSSVfzjqwQ_SQq5PUDcZb_UFuwZSc/edit#responses
Results:
First: Minimal UI
2: AUthentic
3: QR code
Tie: Mobile, Faster checkout / provisioning, card on file
Adding:
#wpwg-fastercheckout
... #wpwg-qrcode
... #wpwg-cardonfile
1) Go to chat rooms of interest
2) Project manage (lead, scope, deliverables)
3) Reconvene here in this channel at same time tomorrow.