See also: IRC log
<scribe> Scribe: Ian
<manu> Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161117
<nicktr> https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md
see pull request https://github.com/w3c/browser-payment-api/pull/316
zkoch: I think that Mahesh put in a pull request for review
rouslan: I looked at the pull
request which looks great. We already have a patch that does
what the pull request describes.
... the discussion on the patch so far seems to involve some
naming choices
... should we call it canMakePayment or
canMakeActivePayment?
... also some questions about formatting HTML (but I don't
think hat's critical path for the issue)
... there's also been some questions about throttling, but i
think I've resolved those without requiring changes to the
PR
<Zakim> MikeSmith, you wanted to comment
MikeSmith: MarcosC has been doing
a careful review of the PR API spec; today he spent a lot of
time looking at the PR in question
... it looks like good progress on this.
... the one thing i'd say is that, given the maturity of the
rest of the spec, what we probably want to do here is get as
much browser implementer feedback as we can so we can move this
forward.
... I have not been on the last few WG calls where this has
been discussed
... where does Microsoft stand on this PR?
... and it would be good to get Nick Shearer's view on
this.
... along with the PR, the Chrome team wants to get this
implemented and shipped in Chrome
... so I hope that more folks will do a detailed review to give
feedback to the editors
... by the way, this call time is suboptimal for Marcos but
he's been active in GitHub
nickTR: Previously we have not gotten traction for a second call in a more favorable time zone
MaheshK: I just went through the
PR and the good comments from Rouslan and Marcos
... I agree with most of the comments from Rouslan
... I will also look at the patch
... thanks to Marcos
;;
scribe: I will update the pull request
jenan: The square space example
was from me...I think that the issue is that shared origin
pages would run into trouble if they want to share different
payment methods potentially from different merchants
... squarespace is an example where all merchants share the
same domain
... the proposal was to query ahead of time from the merchant
pass and pass that along
... I think that's viable but klunky for a case like
squarespace
... but it doesn't work if you can't make a decision about what
you want to present before the hosted page, or if you can't run
code at all
... imagine a hosted page where merchants aren't running code
from the host payment page ahead of time
... how do people think about addressing this case.
... and I also have a question - how are we thinking about what
'active" means?
... with apple pay and the web, if they have a card in the
wallet ...
... but with a number of payment methods for PR API you will
have both "just in time" registration and non just-in time
<dlongley> i left some comments on the use of "active" here: https://github.com/w3c/browser-payment-api/issues/310#issuecomment-261130645
jenan: is that a component of this PR or has this been considered already?
nicktr: Good questions!
... the point you make about shared top-level domain had not
occurred to me previously, but it will affect a number of
hosted page offerings
rouslan: I think that the word
"active" is the best we've got in the function name
... it means that "even if the payment app has just in time
registration, the user already has done the registration of
their profile information into the app"
... so the user would not be taken through that flow
<dlongley> `pr.requiresRegistration()`
rouslan: merchants want to know
for sure whether they will be taken through the flow (of
browser or payment app) or whether they will be able to click
and pay quickly.
... regarding shared origin - I think it's not as scary as
people think
... note that the throttling is done on the user side
... so for example, two users using two user agents will not
impact one another
... we are trying to prevent polling on the same user
... we are thinking of resetting the quota in 30 minutes
... and only for users that are making purchases on your
site
... regardless, my opinion is that we should put this in the
hands of merchants to play with and see what feedback they
give
... our stance at Chrome is that this PR looks good as-is and
we are good to ship it.
... we'd love to hear from Microsoft and Mozilla implementers
hear about this
zkoch: I think for shared
merchants / retailers there are limitations.
... some people want to do specific buttons; others want
show/throw
... we are looking for balance
... this request has come up numerous times
... I think the square space scenarios is overblown ... user
hopping from square space site to square space site with
different payment methods
... I think feedback will be useful from merchants
<Zakim> dlongley, you wanted to say that if this API is about checking to see if a payment request requires some kind of registration to complete, the name should reflect that
dlongley: What is the reason
again for this call?
... I don't think the name is clear; I wouldn't know as a
merchant why to call this. I think we need to be clearer on
that.
... since the method is attached to a payment request since
payment requests don't make payments
... isPaymentMethodConfigured? isUserReady? see other github
comments
<dlongley> https://github.com/w3c/browser-payment-api/issues/310#issuecomment-261130645
<dlongley> requiresRegistration
<Zakim> manu, you wanted to mention that this approach doesn't prevent crawling payment instruments, which was its intent. A privacy review would show a privacy violation for a concerted
Manu: I am fine with the way
things are proceeding; want to keep an eye on privacy
concerns
... we are not really protecting privacy
... for a concerted party that wants to profile you, if you
spend a lot of time on their site, over several days they can
find out whether you are using common payment methods
... while i appreciate the length people are going to to
protect privacy, but I think we are failing to do that
zkoch: I don't think you are
missing anything. I think that over long-term sustained use,
someone who was motivated to find out something could do
so.
... some merchants are happy to use payment apps and PR API if
they can guarantee that a payment method is immediately
available.
... they are not interested in using payment apps for backup
flows
... in the absence of metrics we need to find a balance
... I don't see a good way to prevent attacks over a
duration
... my original proposal is to limit access "within
reason"
... I think merchants also figure things out through
transactions over time
rouslan: I agree that if a user spends hours on a site the site can learn a lot about the user (but that is true outside of payment request)
<AdrianHB> +1 to dlongley
rouslan: utlimately it's up to
the user agent to act in the user's interest
... that's why we are clear in the proposal about how
throttling works exactly. We don't know for sure if 30 minutes
is the right amount
... we might vary it if we think that there is abuse
... we can also notify the user if we detect abuse
... whatever we apply, I think it requires investigation...but
the blocking action is needed for the function to exist
<manu> I'm happy to stay vague in the spec and have the browser vendors making sure this is safe for the user by experimenting.
<dlongley> +1 ... and it seems the current approach likely doesn't offer sufficient protection.
<ShaneM> +1 to being okay with leaving the details outside of the spec.
nicktr: Any mozilla or microsoft comments here?
<adrianba> we're still reviewing - we have some architectural challenges with the proposal
nicktr: So let's bring this topic back next week, after changes to pull request
<dlongley> maybe the call always returns false if the user isn't active on the tab ... much like video won't play if you're not looking at a tab in chrome these days.
IJ: I am hearing the action is on mahesh to take comments into account
<MaheshK> +1 on the action
zkoch: Yes, and I'll work with Mahesh. I would like to time-box this.
<MaheshK> +1 on time boxing
zkoch: I think that everyone (especially Mozilla, Microsoft) be prepared with all comments by 1 December call
<rouslan> dlongley: I'd prefer to resolve/reject the promise only when user is active instead. Then, if the user looks at the tab, the website can receive the response to their query at that time.
<zkoch> brb
<dlongley> rouslan: that could work
(Roy not hear so skipping)
https://w3c.github.io/webpayments-methods-card/
https://w3c.github.io/webpayments-methods-card/#request
IJ: I hear there's an idea to
reference a list of networks from the spec
... what's the status of that proposal
rouslan: I've not spoken with Zach yet....I think the best place for this list is in github
zkoch: I think it may be easiest in the spec rather than outside, but I don't feel strongly
rouslan: I am in agreement with
zkoch...I think the list should be in github so people can make
pull requests and what should be added
... so there's a new card network ("mir") that chrome plans to
support.
<ShaneM> mir == peace?
rouslan: it would be great for
devs at mir to make a pull request into a list
... this list is not intended to be machine readable, so it
might as well be hard coded in the spec.
(IJ clarifies that we can't update the spec easily)
rouslan: So let's have a separate list
nicktr: I was going to say that
there are often rules around who can have a bin
... I think we will get consumers and ourselves in a difficult
place if we are not specific
IJ: We will be specific; question is "in" or "out"
nicktr: My instinct is to keep inside the basic card spec
<Zakim> manu, you wanted to mention alternatives that have worked at W3C... hand spec over to CG w/ W3C oversight for management.
-1 to maintenance outside of the WPWG
manu: we can have a CG that maintains the list
(IJ: Not sure why the WG would hand over the list to a CG while the WG exists)
manu: We can have someone at W3C (staff) update a spec in TR space based on CG consensus
rouslan: I have a question - I know that in some specs there are extension points...can we specify a base list in the spec and then some means to extend the list
<manu> Ian: I propose that we take this question offline, wanted to raise it given some initial feedback.
<nicktr> for information - this is useful -> https://www.bincodes.com/bin-list/
<manu> Ian: I like that extension point proposal. At present, I don't like the idea of handing that list off to a CG while this WG is operating.
<nicktr> in particular note that only cards starting 4,5,6 are "financial"
<manu> To be clear, this WG would be in charge of the list until this group ceases to exist.
<manu> (I intended that to be a part of my proposal)
<manu> Ian: I've been trying to get in touch with Kris Ketels wrt. naming and relevant card specs for ISO and alignment with those specs.
<scribe> ACTION: Ian to work on a proposal around network list [recorded in http://www.w3.org/2016/11/17-wpwg-minutes.html#action01]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
https://github.com/w3c/webpayments-method-identifiers/pull/16
https://github.com/w3c/webpayments-method-identifiers/pull/16
IJ: My gut says a bit more time on github for discussion
NickTR: What if AHB calls in to state them here then take to github?
QUESTION: Should PMIs that are URLs be limited to HTTPS?
AdrianHB: I think we need to say
that manifests need to be retrieved securely, but I'm not
excited to hard-code HTTPS
... also fetching static resources with HTTPS would not be
optimal from a performance perspective.
<manu> +1 to make it secure and note that HTTPs is ONE possible mechanism.
IJ: HTTPs requirement came up at the Lisbon discussion
QUESTION: What about sub resource integrity support?
scribe: that's difficult to do when all you have is a URL..but "ni" URL scheme could be used
<manu> +1, good point AdrianHB
scribe: so you could have a
payment method identifier with "ni" that would map with an
HTTPS URL, but that would be associated with a (numerical)
hash
... I suggest we continue on github
https://tools.ietf.org/html/rfc6920
<manu> ni:// spec - https://tools.ietf.org/html/rfc6920
<nicktr> AdrianHB's issue: https://github.com/w3c/webpayments-method-identifiers/issues/18
rouslan: concerns about slowing
down due to dependencies
... on specs that are not yet implemented
adrianhb: The proposal is not to go off to implement another spec, it just is about the constraint on URLs as PMIs
<AdrianHB> https://github.com/w3c/webpayments-method-identifiers/issues/18
IJ: Can I update the spec with a link to the issue 17?
<AdrianHB> https://github.com/w3c/webpayments-method-identifiers/issues/17
<AdrianHB> +1
AdrianHB: Yes, and then I will merge the PR
<zkoch> +1!
<manu> Ian: I did edits to the PMI spec, tried to see if Max would help w/ Zach's proposal.
<manu> Ian: A couple of questions have come up wrt. where the spec should go.
<manu> Ian: How do we find these manifests? HTTP headers, content negotiation, etc. We don't have a lot of time, but we have to get through this issue.
<Zakim> AdrianHB, you wanted to propose that manifest is defined in the PMI spec
Q1: Should manifest spec be in PMI spec?
Q2: How do we get the manifest: Payment method URL or derived URL?
<manu> Agreed with AdrianHB - why does it need to be in a separate spec?
<AdrianHB> +1 to push changes in current PR to TR space
<manu> Ian: I'd like to update the PMI spec in TR space first, then get these other changes in, then update TR space again w/ manifest stuff.
<manu> Why aren't we using Echidna yet?
<ShaneM> +1 to rev the PMI spec
IJ: I don't mind having manifest info the PMI spec
<AdrianHB> propose we branch pmi spec and work on manifest
PROPOSED: Push PMI spec without manifest bits in it, and begin work in parallel on the Manifest bits to be included in the PMI spec for a future release.
<AdrianHB> +1
+1
<manu> doesn't the group have to make a decision on it?
<Max> +1
<manu> https://github.com/w3c/echidna/wiki/How-to-use-Echidna
<rouslan> +0
<nicktr> +1
<manu> +1
<dlongley> +1
SO RESOLVED
<ShaneM> +1
PR API issues
Payment app spec reviews
Push payment proposal
Test suite
Updates:
* Payment app spec reviews: (Zach reviewed but owes comments on github)
* PR API issue (making progress on key issues is my understanding)
* Push payment proposal (in progress)
<ShaneM> test suite we have set up a mailing list and now that there are two implementors actively working I am planning a push
<AdrianHB> - push payment is a PR against payment req spec, needs to be merged or changed
<rouslan> canMakeActivePayment?
<AdrianHB> +1 on priorities
<AdrianHB> canMakeActivePayment is a PR API issue
1 December
scribe: happy Thanksgiving to those who celebrate it