IJ: Welcome Tom Lowenthal (Brave) and Fawad Nisar (Discover)
Tom: Brave supports Brave
rewards
... we'd like to extend our system to be able to make small
payments to get through paywalls to get an instant subscription
to a site, etc.
... we'd like to use PR API
Fawad: Discover; I am based in Sydney
<Ian> Press release of Web Authentication publication as Recommendation
ij: web authn is now a
recommendation
... does anyone have any questions?
... we have also invited the chairs of webauthn to our f2f
danyao: I think many payment stakeholders would think webauthn would be good in iframe
ij: any short-term responses from the group?
danyao: we have already flagged inside Google that we think this would be a good idea
<Ian> ACTION: Nicktr to work with Ian to bring the question of prioritizing "WebAuthn from an iframe" back to the WPWG
<trackbot> Created ACTION-112 - Work with ian to bring the question of prioritizing "WebAuthn from an iframe" back to the wpwg [on Nick Telford-Reed - due 2019-03-14].
<Ian> Ian notes:
<Ian> ====
<Ian> * Privacy review 28 February
<Ian> https://lists.w3.org/Archives/Public/public-privacy/2019JanMar/0070.html
<Ian> * Proposed some new informative text based on review
<Ian> https://github.com/w3c/payment-request/pull/843
<Ian> * Several threads:
<Ian> - On billing address information shared through new event.
<Ian> * Sam Weiler proposed more negotiation so that the merchant could ask
<Ian> for less than the entire billing address.
<Ian> * Today we have redactList (optional). We plan to update the spec
<Ian> to increase the redactList size. But doing so will also raise the risk
<Ian> that a merchant does not have enough information for proper tax
<Ian> computation.
<Ian> * One question is whether redactList should be mandatory; but right now
<Ian> there are different implementations. Need to check with browsers
<Ian> whether to make redactList mandatory.
<Ian> * Some discussions have taken place about a feature where merchants
<Ian> can indicate the fields they require. Question for the group will
<Ian> be asked in the form of an upcoming CFC to return to CR.
<Ian> - canMakePayment() abuse mitigation
ij: as part of getting to candidate review, we needed to go back to the privacy working group
<Ian> Some of the threads relate to implementation; some relate to potential
<Ian> specification changes.
<Ian> * Finer grain error messaging when false() (e.g., to indicate
<Ian> privacy preference or for debugging)
<Ian> * Whether to inform the user in the UI when canMakePayment is called
<Ian> * Some suggested clarificaitons to the specification
<Ian> https://github.com/w3c/payment-request/pull/843#issuecomment-470262761
<Ian> ====
ij: most of the changes are
editorial
... there was a lot of conversation about billing address
event
... Sam Weiler suggested we should investigate ways to
send less billing information (when not required by the
merchant)
... I reviewed the various threads with browser vendors
... we fixed a bug in the Basic Card specification
... but we would need to change the API to add more functionality than the redactList
... my sense is that this is an edge case and that we should
push the discussion to V1
... the working group can weigh in during the CFC process for
our return to Candidate Recommendation
... I also observe that the idea of merchant indicating required
data relates to issue 97 raised previously by MattS
... A second question is around whether redactList should be informative
or normative
... implementations differ
... Thirdly there was a question on canMakePayment
... a) fine-grained error messaging
... b) secondly indicating that canMakePayment is active to the
user
... do browser folks see implementation changes?
tomlowenthal: we are making some
changes similar to FF to reduce fingerprinting risk
... it seems like there are at least two browsers that would
like to re-open that issue
Rouslan: I think Marcos' comments
refer to previous definition of canMakePayment()
... implementations are converging on same behavior of
canMakePayment() (as discussed at TPAC)
... the spec has changed accordingly
... the consensus definition of canMakePayment() is that it does not check for instruments; just
checks for presence of the payment handler
... so for Basic Card, whatever is in the user browser,
canMakePayment will return true() for FF, Chrome 74, and
Edge
... Safari will return false() for BasicCard but true() for
ApplePay
... and the spec does not need to be changed
... regarding other PING comments
... I think in the long term Chrome will implement things like
better error granularity and user controls
... but in the short term, if there are concrete suggestions to
the spec that are requested, we should use issues on GitHub and
then discussing the proper changes there
... note that Chrome has already started to implement 1.1
features (hasEnrolledInstrument())
... I think it would be reasonable that canMakePayment()
returning a third value, e.g., could be a 1.1 feature
... but first we need more discussion
... including at the FTF meeting
<nicktr> +1 to discussing at the F2F
Rouslan: we also need to write tests
<Ian> https://github.com/w3c/payment-request/pull/843
ij: I want to point out a pull
request from the privacy review
... right at the end there is a little bit of explicit
discussion of the reponses that could be returned
ij: I see Marcos saying FF would return "true" which aligns with the "handler is registered" approach
<Ian> tomlowenthal: the difference between 'can' and 'is primed' is subtle
<Ian> ...we share Mozilla's preference to make responses to non-interactive calls as uniform as possible to reduce value of fingerprinting factor
<Zakim> rouslan, you wanted to confirm ian's point
rouslan: Yes, in agreement now with Marcos
https://github.com/w3c/payment-request/pulls
<nicktr> scribenick: nicktr
ij: PR833 is v1.1
... my pull request on the privacy review
<Ian> https://github.com/w3c/payment-method-basic-card/pulls
ij: there is a bug which needs
fixing
... to Rouslan's point, we will need to converge on pull
requests and we can then use the CFC
... I anticipate the CFC next week
... and allow 10 days to repond
<Ian> Possible timing:
<Ian> * 11 March: Start CFC
<Ian> * 21 March: End of CFC
<Ian> * 26 March: Publish new CR
<Ian> * 2 April: FTF meeting
ij: this allows us to publish a
new CFC before the F2F
... please look out for that
<Ian> 2-3 April FTF meeting page
nicktr: We moved agenda items
around to enable Marcos to attend remotely
... let us know if that creates any issues for you
... our thinking is that we'll spend a bunch of time on morning
of day one on SRC
<nicktr> ij: we anticipate demos from Mastercard and Visa
<nicktr> ij: we are at 25 registrants and anticipate more
<nicktr> ij: and I wanted to point to the list of guests which is growing and diversifying
<nicktr> ij: For the first time we will have firstdata and adyen...also Teddy Toms from Paypal
<nicktr> ...and (thanks to Laura Townsend's efforts) Target, BestBuy and Walmart will have participants
<nicktr> ij: I wondered if we might have a panel with merchants?
<nicktr> ij: I am sure merchants will also weigh in on SRC
<nicktr> ij: how do we get most useful session with merchants?
lte: We can set up time with guests to brainstorm together
<scribe> ACTION: Laura Townsend to organize a call among interest parties (notably merchant guests) on how to organize a merchant/adoption session
<trackbot> Created ACTION-113 - Organize a call among interest parties (notably merchant guests) on how to organize a merchant/adoption session [on Laura Townsend - due 2019-03-14].
IJ: Who would like to be invited to a discussion about structuring a merchant panel?
NickTR: Me
Ian: Me
Luis: Me
<nicktr> luis: what is your current expectation around an ACH demo?
IJ: Luis, status of ACH session?
Luis: Working on a prototype;
thanks to Chrome colleagues for helping out
... hoping to have a prototype at the FTF meeting
<nicktr> That sounds awesome
<nicktr> ij: demos are super useful for driving engagement
<nicktr> ij: could Brave bring something?
<nicktr> tomlowenthal:
<nicktr> tomlowenthal: I don't think we have anything just now
<nicktr> ij: thanks laura
<nicktr> ij: any other questions?
<nicktr> ij: visa are working out dinner plans
<nicktr> ij: any one who is around on 1st April - we could hang out informally
<nicktr> ij: watch the meeting page
Q: Would a primer on the ecosystem of web payment specs be valuable?
Tom: Yes
Danyao: Yes
Luis: Yes
NickTR: Let's start with a deck
21 March
NickTR: it would be super useful to bring any FTF needs to the 21 March call
Cheers!