WPWG Code-a-Thon

Consent and user journeys in faster checkout and QR use cases

Entersekt's versions of demos after code-a-thon discussion:

• just-in-time installation of payment app for bank and EDT bank specific version
• Desktop checkout with QR code display by payment app, completed via phone payment app

Erhard: We brought two topics to the code-a-thon, both focused on 3DS
... recall flow: user forwarded to issuing bank to get a payment handler and enroll ...then during checkout streamlined WebAuthn
... We focused a lot on consent-driven epxeriences

Demo flow:

- IN payment app, click "provision" button, which takes user to browser on bank's domain for provisioning

scribe: and the bank installs a payment handler with user consent

preesnt+ NickTR

scribe: then the user enrolls a FIDO token

Danyao: Nice demo! After the consent screen, followed by FIDO provisioning...would FIDO provisioning happen for all flows or only some?

Arno: Not all flows. Depends on the implementation (whether FIDO integration integral to the payment handler). But there is no strict dependence on the two.
... FIDO is a great example of how native UX takes over during enrollment, and we should strive for that for consent part as well

(Demo: JIT installation of PH and QR code)

Arno: Different journey since PH is installed by a third party (while on merchant site)
... the demo shows a consent view to install the PH
... the goal is for the consent to be managed by the browser.
... if user agrees, PH installs an opens window to show QR code
... user scans QR code and is prompted on phone to approve the payment
... the server talks to the payment handler which shows success and the payment app sends results back to merchant.
... I think a consent screen is very handle when a PH is installed (including JIT installation)
... I think this will be the best way to convey consent (with details about privs granted by user)

IJ: Is that a native app or Web app on the phone?

Arno: Actually, a hybrid.
... the QR code has a URL. In this demo, the app receives the information from the QR code
... the phone does an HTTP POST (ideally with some credential) to say the bank has done the transaction
... the PH front end and back end community (in this case over web sockets)

IJ: So is native app or web site?

Arno: The QR code is not just a link. So it's an app that knows how to handle the QR code

IJ: Anything preventing you from doing it in the browser?

Danyao: This scenario is basically showing how to stitch things together (desktop + native payment app)

IJ: Could you do it with web-based payment app?
... I can scan the QR code without having to find my APP
... would be great if QR code were just a URL with query params

<Zakim> danyao, you wanted to share a bit more learning

danyao: Thanks very much to Entersekt for talking about QR code use cases.
... I was wondering why the QR code needed to be displayed "natively" by the borwser
... and I think the answer is "better security"
... when the user scans the QR code, they want to trust that the QR code was generated by the party that had the information.
... the browser could help build trust by verifying the origin of the site requesting the generation of a QR code...and the browser could do the generation of the QR code.

Rouslan: And the browser could put a signature in the QR code

Gerhard: What if the QR code were to point to the bank's payment handler?
... BEFORE installation...another use case of JIT installation

don_changfoot: Cool demo. I have some questions about what the PH needs to provide at registration
... is it just the name of the Payment app? Is it checked or verified by the browser?

Danyao: The UX we are trying to show (in the mockup)...the browser fetches the payment method manifest from the handler's origin
... the URL comes from the payment method owner

Donovan: Cool, thanks

<Zakim> rouslan, you wanted to say pointing QR code to not-yet-installed PWA is possible today

rouslan: Is it possible to point the QR at a PH that's not yet installed
... yes, already today.
... PHs are PWAs
... if you point your QR code to the URL of your web app, you should be able to proceed with payments
... in the same flow you can install your SW and home screen icon

<clinton_> +q

clinton_: The QR code presented on the desktop side. Is it generic? when you scan it, have you chosen a payment app?

Arno: The idea here is that the customer has a trusted banking app on the phone.
... that specific banking app is integrated with a payment service provider that offers pay with QR code functionality
... this is "company A QR code"
... where company A is a service provider that serves a number of apps
... so the app knows how to interpret the dynamically generated QR code

Gerhard: It is an interesting use case...if we can get the right standard going...it would help with discovery of a payment service provider
... so banking apps could find payment service providers

IJ: I am surprised that decoupling is possible here.

Gerhard: If we assume that this follows the QR code standard...suppose the PSP is Stripe who generates the QR code
... this could allow Stripe to engage with, say, Bank of Canada via the user's Bank of Canada app
... and the user gets credentials from their bank

IJ: Does BoC respond to Stripe on the backend?

Gerhard: Yes. The browser signs the QR code
... BoC then posts data on the back end
... the back end URL is provided via the QR code
... EMVCo has a standard
... if we want more than payments (e.g., identity) we might need something else

<nicktr> EMVCO QR spec https://www.emvco.com/emv-technologies/qrcodes/

IJ: Next step ideas

- Phone's app is a Web App

- QR code is standardized and allows discovery of back end connection (including starting from a browser)

Anne: No demo today due to meetings

IJ: Any learnings about minimal UI?

Danyao: Prior to the code-a-thon, Anne pointed us at an interesting edge case ...we will sort this out
... I also heard Anne express interest in minimal UI + WebAuth, so that's good input to push forward
... reach out to us, Anne as you continue the prototype!

Mobile Money

Mobile money doc started by AdrianHB.

AdrianHB: Not as much progress as I would have liked, but I started a document to help make progress
...Most mobile money platforms are closed.
... if a merchant is in a country with multiple mobile money platforms, they would likely have onboarded with all of those platforms.
... there are some use cases where they onboard with a network, but in most cases it's to the platforms.
... in our use case: user shopping on merchant site and wants to pay from a mobile money account. The payment handler used by the user manages the user's mobile money account
... The thing that was most difficult to figure out is that the payment method identifier (PMI) is specific to the platform.
... so the merchant onboards to one or more "platforms"
... when the merchant calls payment request, if the user has a payment handler from ANY platform it can be used.
... In first use case, user sees transaction details in app, agrees to the terms, and the app submits the transaction to the mobile money platform.
... this in fact may not be a common use case.
... where there's a user initiated payment
... but I think the most interesting case is where the transaction is merchant initiated
... in this case, the user's app is the "caller" and the FSP (financial service platform) is the platform
... the app speaks to the platform to create a pre-auth request
... the authorization code is returned to the merchant
... this includes the user's details and the auth code
... the merchant would then submit this to the mobile money platform
... the value there is that the user is no longer in this part of the flow
... there's another variation where the app returns only the user details. The merchant submits the transaction to the backend, which then prompts the user to authenticate.
... I think the data lends itself to a payment method specification that only defines a data model, and where each platform defines its own PMI.

IJ: Confirming platform means "operator" or "aggregator"?

AdrianHB: Yes.
... PMIs provide the useful function here of showing only the relevant payment apps

Viji: One quick comment on payer-initiated transactions....they do happen
... One point on PMIs...would it be better to do that or a single mobile money PMI?

AdrianHB: You can do either - PMIs or input data.

IJ: PMIs give you control over payment apps; single URL doesn't give you that

Viji: The data set should be completely standardized

<Ian> IJ: Any payment handler distributor leads?

<Ian> AdrianHB: First I'd like to write up the document

<Ian> Danyao: Thanks for writing up that document; the use cases are really helpful!

<Ian> Next steps:

<Ian> - Continue to work on the doc

<Ian> - Identify partners for doing POC?

<Ian> AdrianHB: We have a reference wallet at Coil; we could try to do a POC with it

<Ian> ..the target for this is mobile operators

<Ian> ...also, there are browser vendors who specifically target this market.

<Ian> ...that would be a new set of browser implementations of our APIs

<Ian> IJ: What's the relationship here to carrier billing?

<Ian> Viji: In our API set we have a bill payments API

<clinton_> +q

<Ian> ...they can do that with their mobile money account

<clinton_> M-pesa

<Ian> AdrianHB: I agree the stakeholders the same, but it's not the same APIs

<Ian> Viji: Ah, I see what you mean now

<Ian> IJ: I just thought as long as talking to these stakeholders, we might want to talk about other payment methods where the operators might be interested in the PR APIs

<Ian> AdrianHB: It would be different markets, but I agree stakeholders are similar

<Ian> Viji: The model that I was thinking of could also be integrated. if you are a service provider and you have a web site...that could be use case that is through mobile money and we have an API for it

<Ian> ..the user can go straight from their generic provider's web site and set up billing through mobile money

<Ian> clinton_: When you say "mobile money" do you mean "stored value"?

<Ian> Viji: stored value

<Ian> AdrianHB: Mobile money common outside of places where cards are common

<Ian> AdrianHB: One challenge for us has been mobile money with Web, but that's changed since we've started this work.

<Ian> ...that's changed a lot in the past 2 years

Feedback on the virtual code-a-thon

<Ian> Arno: We were very happy with the experience; got a lot out of it. Would have been better with Guiness in Dublin

<Ian> ..I've not done one before; really enjoyed it

<Ian> ...conversations with browser folks were very valuable (thanks Danyo and Rouslan)!

<Ian> ...would love to do this again

<Ian> Erhard: Agreed!

<Ian> Viji: This is the first one of these I've done remotely

<Ian> Viji: ...really useful to see comparison with other industries using the APIs and how we could

<Ian> ...as another standards organization, it's important to collaborate

<Ian> ...our industry is fragmented, and we are trying to grow our consistency, which is what consumers and merchants want

<Ian> ...really valuable to see the demos from other groups...we are tacking similar questions

<Ian> ..e.g., connecting laptop experience with phone payment

<Ian> ...that interests us as well

<Ian> ...disadvantage is being pulled away to other meetings.

<Ian> Danyao: I found it a great opportunity to hear more from developers!

<Ian> ...eye-opening so thank you

<Ian> Danyao:...I would second Viji's feedback on getting pulled away to other meetings. :)

<Ian> Danyao: I think that time zones are also a challenge

<Zakim> AdrianHB, you wanted to provide some thoughts

<Ian> AdrianHB: Two things for me...I agree with Viji and Danyao. If we did this again, maybe we could stretch this out over a week, with only a few hours each day spent on coding

<Ian> ...regarding time zones, if you disconnect from IRC you lose conversation

<nicktr> +q to say that I wonder if we could have done more to have the "what next" set up after the lightning talk and on tooling

<Ian> ...so you need a proxy or Slack

<Ian> Viji: +1 to Slack

<Zakim> nicktr, you wanted to say that I wonder if we could have done more to have the "what next" set up after the lightning talk and on tooling

<Ian> NickTR: A learning to me: We had a really great first session

<Ian> ...and then I found myself thinking I would have liked to understand how to immediately segue into next steps

<nicktr> scribenick: nicktr

ij: I wasn't sure if it was necessary to show up with something to work on or just jam on something new
... but the big winners were where there was pre-existing work
... that let us flesh things out
... but the exception was mobile money
... we had the right people in the room, and then people with energy to write things uo
... I had a slide deck but no developers

ij: to follow up on what nicktr said, I think a bit more project management would have been helpful

<AdrianHB> /me is very happy to have connected more developers with browsers!

clinton: I found the demos valuable

<Ian> clinton_: All the demos and discussions were valuable

<scribe> scribenick: ian

Clinton: with videos and all the things, will be interested in seeing how this is repackaged

IJ: I plan to blog. I invite others to share their experiences as well!
... Would it be valuable to do this with an SRC focus?

clinton_: I think there could be a second round, even with demos we saw this week, to take back and see how matches with SRC
... For SRC maybe we need a sort of test platform to support demos

Thanks!

NickTR: Thanks to everyone!

<Sebastian_WL> thank you so much

Viji: If we develop a POC...is there a plan for that later?

AdrianHB: The WPWG meets regularly. If anybody has follow on from this an put a demo on a WG call we would welcome it.