See also: IRC log
rouslan: Defining common tests
that can be run on all browsers
... goal is to share HTML+JS tests across browsers
... we started doing this in payment request
... challenge around user interaction
... what we've decided to do among the implementers is to
introduce web-platform-test payment method with params that
tell the browser what to do
... browser can "act as though there were user
interaction"
... and then the JS can look at the result
... this approach came from Marcos
... I think that I will add support to this into Chrome
... I think Marcos has a small (payment method) spec he has
written up.
IJ: I have asked Mike Smith to document this process
<AdrianHB> ... Mike has said he will create a resource for this
<AdrianHB> ... During CR as the suite is fleshed out, will changes to the spec be accompanied by changes to the test suite? (Question to editors/implementors)
IJ: Are editors moving in direction of test-driven changes during CR?
zkoch: We have not discussed yet
adrianhb: Don't want to spend
much time on today's call but it's an important issue to
address.
... I think there is misunderstanding about the WebIDL in
payment method specs
... the question came up a long time ago about whether the spec
needed to be written in WebIDL or, since ignored by the
browser, we were using it because it is a widely liked data
model formalism.
... it seems that a lot of the recent developments around PR
API and basic card suggest that is not a shared
understanding
... I think we need to decide what we want, and for other
payment method specs as well
... if browsers plan to do data validation, then we are
creating an implementation burden on browsers and making them
gatekeepers.
... Marcos indicated that he thinks that what should happen for
al payment methods, which I think flies in the face of
expectations about distributed payment methods.
... but even if the scope is just W3C-defined payment methods,
we need to clarify whether browsers have to implement the
WebIDL, do validation, etc.
... the debate is somewhat complicated by the filtering
discussion....
=> https://github.com/w3c/payment-handler/issues/157
<AdrianHB> ian: current thinking is to move payment handler matching back into handlers
<AdrianHB> ... let's focus on "should browsers look at this data"
AdrianHB: I think the
implementers need to give us direction and tell us what is
practical
... we need to determine whether using WebIDL with no
expectation of data validation is ok.
... marcos seems to think this is a bad idea; I asked this very
question 2 calls ago
... we need vendors to figure out whether they are going to
treat data as opaque.
... IMO PR should not involve data validation
... I think there is currently a disagreement among the
editors
... or may be
nicktr: Zach, thoughts?
zkoch: I think it's nuanced.
Suppose you call basic card and have your supported type as
"banana"...nobody can fulfill that...so it seems strange to let
user go through experience if a failure can be detected in
advance. Or similarly, if the merchant has a typo
... Enum types can be validated by browsers for well-defined
payment methods....of course this does not apply for
proprietary methods
<Zakim> AdrianHB, you wanted to agree with Zach but suggest that shoudl stay out the spec
adrianhb: I agree with what Zach
said...anything the browser can do to avoid bad UX makes sense,
but I don't think it should be part of PR API. PR API should
leave that open and browsers can add validation logic if they
want.
... I don't think PR API should make assertions about data
validation
zkoch: I think the problem is
interop.
... you don't want an exception on one browser and not on
another.
adrianhb: In my mind, that
relates to browser implementation of basic card handler
... I submit a payment request to the browser...the first thing
the browser does is call its known handlers that support those
PM's.
... browser passes data and handler responds yes/no
... you are saying that for basic card, the browser does it in
its capacity as a payment handler
... marcos is proposing changes to PR API...my interpretation
is that all payment methods have to define their request
methods in WebIDL and browsers must validate, etc.
zkoch: I don't understand it that way.
<Zakim> Ian, you wanted to suggest "MAY"
IJ: Would it make sense to clarify in PR API that user agents may validate data for some payment methods.
AdrianHB: I may not understand
Marcos' perspective completely about support for opaque
data.
... but on interop, new payment methods will lead to different
user agent behavior .
zkoch: Not quite...what we want
to avoid is two known / implemented payment methods that are
supported differently.
... basic card merits special consideration
... I will talk to Adrian and Marcos about this issue
<zkoch> I emailed editors about testing and CR, to which Marcos replied: “Damn straight we are:) no test no (normative) change. Them's the rules.”
nicktr: Let's get clarity among the editors and come back to this on another call.
nicktr: Congrats to the WG, I'm really pleased to see this happen! Thanks to all who helped get us there.
<AdrianHB> +1 nice job at Google I/O zkoch and max
<AdrianHB> ian: Great Google i/O preo from zkoch and co. Specifically mention of Paypal involvement and desktop implementation
IJ: Thanks to Google for extending PR support and to Rouslan for beginning to implement Payment Handler
<zkoch> don’t worry, i can irc and drive!
IJ: next up for us: implementations, issues
<zkoch> (jokes, on shuttle)
AdrianHB: draft payment method
spec =>
https://w3c.github.io/webpayments/proposals/interledger-payment-method.html
... the way it is structured may change based on conversations
since today it is WebIDL'y .. and has complex types
... but if it were just to be JSON, it would change into, e.g.,
URL-encoded strings
... it gives you a flavor of what we've been playing with for
how inter ledger could work with PR API and payment
handlers
... I'd like to take it up within the WG
... the payment method takes two forms
... when you submit a PR you can either submit a URL that
points to a "simple payment setup endpoint"
... and the handler will fetch data about how to do the
payment, then submit the payment and ultimately send a proof of
payment in the response
... the second method is an inter ledger payment request, with
merchant-prepared data...and all the payment app does is submit
the data to an inter ledger node
... we are having a 2-day workshop 1-2 June in Berlin; this
will be on the agenda
https://interledger.org/workshop
scribe: at hackathon we want to get the bobpay demo working with interledger
nicktr: The spec has been available for review for some time..have reviews happened?
(IJ reviewed it)
https://github.com/w3c/webpayments-methods-tokenization/wiki
<AdrianHB> ian: q around payment methods specs is "Who will implement?". Lots of activity in tokenization and credit transfer for example
<AdrianHB> ... what is expectation for implementors around Interledger
IJ: who would implement?
adrianhb: Anybody!
... anybody can implement. .... currently there is a network of
about 20 people running inter ledger nodes as an experimental
network (with real money, though)
... there is also a project around bringing inter ledger to
mobile money networks
... there needs to be more people accepting inter ledger
payments before we see lots of payment apps
... I concede it is not currently as popular as credit cards.
:)
nicktr: I encourage people to have a look at the spec.
AdrianHB: I note that both tokenization and credit transfer were taken up prior to implementer interest...I don't mind if we decide that's our bar for acceptance, but I would point out it has not been our bar historically
mweksler: 8 August meetup at Airbnb...650-person meetup group...about 50 have already RSVP'd
https://www.meetup.com/Bay-Area-Billing-and-Payment-Engineers/events/240044104/
scribe: the range of topics is
pretty diverse (agenda in flux)
... probably about 2 hour agenda with several 10-15 min
presentations on payments, billing
... might be a good platform for someone from our WG to talk
about PR API
... e.g., as zach did at Google I/O...this would be a smaller
audience but a very focused one on payments
... since I'm hosting I would prefer not to present
... anyone else interested in presenting 10-15 mins?
nicktr: Thanks, Michel!
mweksler: If interested, please contact me
IJ: Should we meet?
<Zakim> AdrianHB, you wanted to say we're having a similar meetup in SA in July
NickTR: My sense is that nothing
has changed since Chicago.
... anyone want a FTF before TPAC in Nov?
[Nobody indicates they want a meeting before TPAC]
RESOLUTION: Next FTF meeting will be at
TPAC.
...specifically: 6-7 Nov
https://www.w3.org/2017/11/TPAC/
AdrianHB: There is a payments
company that wants to host an event on 27 July
... with a section dedicated to our wokr
... if any of you have engineers in the region who are
interested in participating, let me know
... I will send more information to the list
nicktr: Maybe we should explicitly call out next FTF meeting of WPWG in standalone email
Proposed: 1 June
NickTR: Regrets for 1 June
Proposed: 8 June
<rouslan> +1
<AdrianHB> +1
<mweksler> +1
RESOLUTION: Next call 8 June