Agenda · 26 May minutes · 27 May minutes
Entersekt's versions of demos after code-a-thon discussion:
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 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
<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
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.