See also: IRC log
<scribe> Scribe: Ian
<scribe> Chair: Ian
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/att-0008/00-part
PROPOSED: Adopt Rupay in the network token list
<rouslan> +1
IJ: Any objections to adding rupay to the list?
<zkoch> ::reading about rupay::
<zkoch> +1
SO RESOLVED
<scribe> ACTION: Ian to update the network id list with rupay [recorded in http://www.w3.org/2017/06/08-wpwg-minutes.html#action01]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
https://github.com/w3c/webpayments/wiki/Agenda-20170608
Pull request 536 https://github.com/w3c/browser-payment-api/pull/536
zkoch: For issue 546, I think
that Marcos will issue a pull request for this.
... We did spent a chunk of time during editors meeting
discussing PR 536.
... I think the editors came to the following conclusion....the
gist of this issue
... is that there is a bit of disagreement whether, for specs
that are like basic card, whether the browser does any
validation on the data
... concretely - what should happen if you call PR API with
basic card and pass in a supported network of "bob"
... and that's not on the list
... there are different behaviors possible, e.g., browser does
nothing v. browser validates data and throws error
... I don't think the issue centers around WebIDL. I think our
conclusion is this: the WG decided a long time ago that there
are two ways to define payment methods.
... and browsers have said that just because a payment app says
they support a short string doesn't mean that browsers will
match on it
... it follows that browsers should validate on data for short
string payment methods
... in order to ensure the best user experience
... if you don't want the browser to do validation and you want
to treat the payment method data opaquely, the approach is to
use a URL
... that will ensure that (1) it's enabled by default and (2)
the data is opaque
... but our view is that for short string payment methods
browsers will likely validate data that can be (easily)
validated
... there is some room for flexibility, but the goal is to give
the users the best experience
IJ: what might the spec say about
browser validation?
... e.g., basic card
zkoch: My understanding from
yesterday is, when implementing a short string payment method,
one can find things in WebIDL and it is a MUST to validate some
things, such as well-known enums
... in the example you just gave, I don't understand whether
expectations about browser implementation of the payment method
is relevant. What's important is the user experience, and we
should not pass broken data through knowing it will create a
bad user experience.
nicktr: Are we saying that "if there is a short string there needs to be a specification that says how to behave"?
zkoch: I think that's correct.
nicktr: That also maps to my understanding.
ack adrianba: I think that statement is true but I want to reiterate a point zkoch made earlier. For us to approve a short string (1) there needs to be a spec that is broadly agreed upon and (2) browsers need to take action to support that payment method
scribe: this is an important
piece of preventing squatting strings
... browsers take action to support matching on that short
string
... I wanted to answer ian's question about what spec should
say what. I think it's necessary to say something in PR API. I
think we need to indicate at what point that validation
occurs...and what the consequence of failure to validate
is...we need to be explicit about whether there is an exception
(and its value) or failure of a promise.
... it makes sense also that we would provide some information
in the basic card spec. We need to decide whether the text we
add to the basic card spec be explicit about the validation
<nicktr> q
scribe: as zkoch said, there is
some flexibility about which fields are validated. It's
possible for basic card to be explicit about which fields are
validated. We need to decide whether we want to say that (and
make it normative)...or more informative
... the final piece is whether we say "must validate' or "may
validate"
... zkoch's comment on "best user experience" suggests to me
"quality of implementation" and therefore room to distinguish
oneself
... there's a strong argument that says that we need to protect
people from a quality of implementation issue. I am open-minded
about must v. should v. may....but (1) we definitely need to
say something in PR API about where validation occurs and (2)
we should put something in basic card
nicktr: I am hearing that where there is a short string, PR API needs to say something about validation AND there needs to be a (W3C) specification for that short string that deals with validation rules specific to that method
adrianba: The key thing is that we should not need to update PR API for new payment methods.
Ian: +1
IJ: Is WebIDL sufficient to say "what can be validated" or do we need to also say something in the prose?
AdrianBA: I think you could say
it should be valid according to the WebIDL
... but there could be additional validation that needs to
occur (though not necessarily for basic card). E.g., there
might be validation rules about relationship between two
fields; that's not something that is expressible in WebIDL
IJ: Other than normative statements in basic card, is there anything special to say about validation?
zkoch: I don't think so
IJ: What should happen here since
AdrianHB is not on the call?
... Can we wait for AHB to get back and have a decision by the
next call?
NickTR: What's the decision about?
zkoch: There's a concrete pull request about validation
<adrianba> https://github.com/w3c/browser-payment-api/pull/536
https://github.com/w3c/browser-payment-api/pull/536/files
nicktr: We can meet next week if needed.
zkoch: We were hoping to get closure today; I think we can wait until next week.
IJ: Should we do a straw poll today?
nicktr: +1 to straw poll
PROPOSED: For w3c-defined payment methods (i.e., those with short strings), PR API implementations (at least) may validate payment method request data.
<zkoch> +1
<adrianba> +1
[Please say +1 if you support the proposal]
<cweiss> +1
<molly> +1
<Roy> +1
PROPOSED: For w3c-defined payment methods (i.e., those with short strings), PR API implementations MUST validate payment method request data that can be validated economically
<adrianba> the PR suggests it must if the payment method spec requires it
<zkoch> +1 to must
nicktr: Makes sense to me to say
"MUST" if the payment method spec says "MUST"
... makes sense to me that if payment method spec says "MUST"
then browser MUST enforce that validation
Mission => https://github.com/w3c/webpayments-methods-tokenization/wiki
<nicktr> ian: tokenisation task force meeting regularly and is working on network and gateway tokens separately
<nicktr> ... Mastercard are working on a revised explainer
https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params
<nicktr> ... We have the beginnings of a gateway token spec
<nicktr> ... In short - good progress on tokens
UNKNOWN_SPEAKER: just met today
<nicktr> ... five issues being worked through
<nicktr> ... by mid-Jul, an update to the WG
https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0004.html
<nicktr> Ian: Thanks to Rouslan and Samsung for issues and PRs on implementation experience
<nicktr> ... and _even_ Zach
<zkoch> :)
nicktr: Good to hear the progress
zkoch: One quick comment - there's a lot happening in that spec, and I realize that it was in a task force to get started. Now that PR API has fewer issues, it could make sense to bring payment handler issues into the main call
nicktr: +1
IJ: Is the model that editors
bring issues into the WG from time to time?
... as with PR API?
zkoch: Yes, but there are some issues I want to put before the full group such as "wallets"; but in general +1 to editor judgment on what to bring forth
15 June (to try to wrap up 536)