<AdrianHB> ian: UX document will evolve as we learn more
<AdrianHB> ... taskforce went through arch document yesterday
<AdrianHB> ... MasterCard raised some questions
<AdrianHB> ... goal is to get consensus on this approach and present at F2F
<AdrianHB> ... this was just a heads up that we're making progress
https://github.com/w3c/webpayments/wiki/FTF-Mar2020
<AdrianHB> ian: currently 30 registrants for f2f, I expect some more
<AdrianHB> ... I have also been looking for guests based close by to especially join the cod-a-thon to explore journeys
<AdrianHB> ... European Central bank looking to attend and can share experience from their own codathon
<AdrianHB> ... looking for a diversity of experimentation around different payment methods
<AdrianHB> ... recent work on participation, want to focus on some agenda bashing
<AdrianHB> ... we'll do a catchup on PR API and then also PH API (Chrome team been doing some work)
<AdrianHB> ... will get some updates/insight on payments from local experts (Europe)
<AdrianHB> ... discussion on increasing traction
<AdrianHB> ... what can we be doing to increase adoption?
<AdrianHB> ... will leave space for breakouts on day 1
<AdrianHB> ... will also get an update on WebAuthn shared task force and do some planning for codathon
IJ: Please contact us for agenda things you want!
<AdrianHB> ... if there is anythign to add please contact us
AdrianHB: I think maybe part of
the adoption discussion should be revisiting the value
proposition
... why is using PR API and payment handlers better than
not
See also Value Proposition blog
(for payment handlers)
AdrianHB: The ecosystem has
evolved over time since we started: SRC, more push payments,
real-time payments
... so we should review value proposition in light of these
changes
<AdrianHB> ian: we captured the value prop for PH API
<AdrianHB> ...(see blog)
IJ: +1
<AdrianHB> ... that was a good exercise and it would be good to do again
- TPAC 2020 is 26-30 October in Vancouver, BC, Canada.
- Money 20/20 is 25-28 October
<AdrianHB> ian: unfortunate overlap, unavoidable at this stage
Proposed WPWG meeting dates: 29-30 October (Thursday, Friday)
<AdrianHB> ... we CAN try to position our f2f in the latter half to avoid conflict
<rouslan> +0
PROPOSED: Meet end of TPAC week (29-30 Oct)
<laurenhelt> +0
<AdrianHB> +1 (won't attend Money 2020 but keen to have good participation)
<stpeter> +1
<Alex_liu> +0
<Fawad> +1
<scribe> ACTION: Ian to put the question to the WPWG via email; we'll have a decision by 13 February
AdrianHB: Perhaps for the FTF
meeting we should review whether PR API model is well-suited to
payment methods
... it feels like models of payment methods are similar...I
wonder whether a slightly different approach to solving the
proposal (or a more specific approach) would be more
effective
IJ: What prompted this?
AdrianHB: The discussions around
delegation with SRC and WebAuthn. Everything we are doing comes
down to the user authorizing a payment and some party feeling
confident that the authorization was done in a way that they
can trust
... cards are starting to resemble push payments
... the user ends up interacting directly with their account
holding institution
... what would happen if we assumed that is generally the case,
but in some cases authentication is delegated to the
merchant
... so what if we thought about payment request as "getting
authorization" rather than "evolution of autofill"
Gerhard: +1 to that perspective.
We have moved away from using the phrase "auth"...we are using
the word "consent"
... the user consents; the bank makes a decision
... so perhaps having consent as a separate activity /
API
... one idea is for an SRC handler to get customer consent,
then send it along the customer rails
AdrianHB: I think that one of the
things we've looked at in the past is "standardizing tokens";
maybe we should step back and think about "standardizing
consent"
... So the user sends a consent signal; there is some way to
authenticate it.
... I'm also tracking evolution of OAuth at IETF, and a lot is
driven by payment use case
<benoit_> +1 for further discussion, especially given evolution of capabilities in browsers, and changes to identity management standards
AdrianHB: Oauth may fall short
right now. You need to create a context first, then get
consent.
... I think we are seeing some of the same friction in
WebAuthn
... It would be interesting to step back and see if stepping
back we could make some adjustments in a way that involves
pushing less work into payment handler developers
... the API might be more specific (and less flexible) but
easier to use for more payments use cases
Gerhard: I want to add to this
that I need to have a second type of call where the bank (or
institution) commits that the money has been put into an
account or will be.
... in other words, a financial institution makes a commitment
and that is represented to the merchant
AdrianHB: Goal would be to standardize pieces in a way that can be used across different rails
<stpeter> This seems like a worthy topic of discussion, thanks for raising it AdrianHB
<scribe> ACTION: AdrianHB to work with Gerhard to formulate a discussion for Dublin
AdrianHB: People can join us in Capetown!
<benoit_> count me in ;)
IJ: I heard these aspirational outcomes:
- Easier to use (but maybe less flexible)
- Applicable to more payment methods
AdrianHB: What I am envisioning
is -- a web site asks the browser to get the user to consent to
making a payment for a particular amount to me
... the packaged consent solves many of the problems we are
trying to solve
... payment can then be made on different rails
... If you get a (1) consent package and (2) payment
credentials package...and with those two things you could get
the payment done
IJ: I am hearing this as "Give data to merchant that enables the merchant to get the payment done, whether push or pull"
Gerhard: payment handler might
give back consent in various forms
... merchant could pick the rails the merchant wants to use
(express a preference to the payment handler)
IJ: Please address issues we
already know about (UX, adoption, etc.)
... What about talking about OAuth evolution (although that's
more WPSIG-like)
(Please send links also to WPSIG list!)
20 February