See also: IRC log
<scribe> Scribe: ian
-> Agenda
https://github.com/w3c/webpayments/wiki/Agenda-20161201
Upcoming calls: 8 Dec, 15 Dec. No calls 22 and 29 December. Next call 5 Jan 2017.
[FTF update]
Ian: I am still working on a meeting venue in Chicago 23-24 March 2017 week before the IETF meeting
https://github.com/w3c/webpayments/wiki/Agenda-20161201
https://github.com/w3c/browser-payment-api/issues/311
https://github.com/w3ctag/spec-reviews/issues/147#issuecomment-262427149
Should we use .allowPaymentRequest and anticipate migration to Feature Policy?
zkoch: This is about the iframe
thing
... background is that we wanted iframe support, so we proposed
an attribute
... there was pushback on this due to emerging "feature
policy"
... and some discussion about how to spec this out.
... and interim proposal came from Chrome developers working
elsewhere on the web platform
... goal is short-term compromise with migration path to
Feature Policy
... the short-term proposal is to "allow" and then we say in
the spec when feature policy is available, to defer to
that.
rouslan: Now we know that Feature
Policy in chrome is coming soon
... that is preferable to monkey patching....but then we heard
from Marcos (Mozilla) that they are not planning to implement
the full Feature Policy in the same time frame
... so that makes it harder to do Feature Policy sooner
... idea was to allow=paymentRequest in iFrame and Mozilla is
on board with that
... so the consensus view right now is allow=paymentRequest on
iFrame and plan for migration to Feature Policy
... now the question is: will Edge support this?
... and same question to other browser vendors
to allow=paymentRequest
IJ: Can edge support that?
Rouslan: either allow= or
enable=
... it's the shorthand attribute from the Feature policy
work
adrianba: We don't currently have a Feature Policy plan; that doesn't mean we won't do it; we need to re-review
Rouslan: Question is whether to
make the iframe attribute future-compatible to Feature
Policy
... and use "=" rather than shorthand
adrianba: Is it really forward compatible or are we just guessing?
Rouslan: Should we continue discussion on GitHub?
adrianba: I believe we currently
implement what's in the spec and are not likely to change the
implementation soon; I will double check and we can continue
discussion on GitHub
... can we really make it forward-compatible? We need to
specify parsing rules; handling unrecognized tokens
... if we support it and expect only a single value, when
people provide multiple values in the attribute, if we didn't
allow that in our code today then we will not have accomplished
anything, and may be even more damaging as they can't actually
use the other Feature Policy features and do payments in a
backwards-compatible way
... so seems risky unless we understand how the attribute will
evolve
<zkoch> q—
nicktr: Sounds like we need to bring back
https://github.com/w3c/browser-payment-api/pull/316
zkoch: Mahesh wrote a pull
request for canMakeActivePayments...there was good
feedback
... one of the larger issues was on "active" as being both
technically difficult and raising privacy implications
... my proposal to Mahesh was to take the algorithm as written
but remove the "active" part
... that will make it an implementation decision on whether
something is "active" or not
... so there's a new pull request from Mahesh
<zkoch> https://github.com/w3c/browser-payment-api/pull/316/commits/b87613d1d4411dfa31ca6462f85a2c09c658141b
nicktr: Question - what's to stop a bad actor just having lots of different domains from which they launch requests, and you aggregate them?:
zkoch: the short answer is that
nothing prevents that, but that's logistically very difficult;
a person would have to visit all those sites
... we need to ack that this is a compromise - between the
requirements of different players
nicktr: on the one hand you have a privacy issue, and on the other you have a functionality that merchants already have today
zkoch: I would challenge the notion that this functionality exists today - whether user has support for a payment method
nicktr: Yes, that's true, but you
can start by saying 'I only accept X" one at a time
... merchants can nudge people as well since the merchant
controls the experience
zkoch: Those seem like separate issues. I think that ways that you can poke into the system today are still available via PR API
nicktr: I think this is a hard
sell for merchants
... I think the overall concern is the passing of control to
someone else; this is one feature we are providing to
ameliorate that but the concern is more general
IJ: Has there been implementer discussion about user configurability (and impact on scope)
<dlongley> "`example.org` wants to see what payment methods you have available, allow/deny?"
adrianba: If user can configure off then the merchant might (1) disable use of API or (2) create a bad UX
IJ: My thought was that function would be "off" until first specification of creds and it would be on by default
zkoch: Apple has a flag
... I think we've thought about adding a similar thing in the
UI
... it's a way to disable PR API (in some way)
... and merchants would fall back to traditional flow
... the question for me was whether to be in the spec or
not
IJ: Usually I would push this to the browser, but it might be interesting to connect to "scope" of this function if it's configurability
adrianba: there's a question
about user opting out of the payment request ecosystem...and
what that means (e.g., removing something from the type system
so make it look like the browser does not support PR API)
... if you turn off the "detection" piece there's a question
about what impact will that have on the merchant
ecosystem.
... we are hearing from merchants that they want to hear
whether there is some level of support for a payment
method
... we are hearing that the request is there because people
want to avoid sending people into a browser UI if the user has
never used it before
... or if the user may not be able to make a payment
... if you allow the user to turn that off (or not work the
first time) then you defeat the reason people are calling for
this functionality.
nicktr: Sounds like there is consensus among implementers that this is the way to go
PROPOSAL: Merge the updated Mahesh PR https://github.com/w3c/browser-payment-api/pull/316/commits/b87613d1d4411dfa31ca6462f85a2c09c658141b
<adrianba> what are the updates?
1) New name
2) Date / time algo gone
zkoch: I suggest we endorse the concept and accept that there will be edits (e.g., with adrianB and Marcos) to get the PR right
<ShaneM> +1 to what zach said
<dlongley> +1 to zach
zkoch: so let's propose the spirit of the pull request
adrianba: Is the spirit that the spec allow variability around mentions of "active"
zkoch: Yes, the algorithm will say "payment method available" and allow some flexibility
adamR: As written, you can call
this once per TLD per universe.
... it doesn't talk about the quota resetting
... is there a frequency expectation?
zkoch: There might need to be
mention of resetting in the algorithm.
... however, we have left it intentionally vague so that
implementers can differentiate according to privacy preferences
(e.g., 30 mins or 24 hours)
AdamR: I am fine with leaving that undefined; let's just say clearly in the text that it is undefined.
<adrianba> sounds good
IJ: I Hear that the algo should (1) talk about resetting and (2) say explicitly that reset timeout is defined
rouslan: There is some text in there already to that effect
nicktr: I hear no objections to this direction and that some polishing is in order
+1
<zkoch> +1
<rouslan> +1
<adamR> +1
<ShaneM> +1
<jenan> does this include consensus on "active" vs not?
<dlongley> +1
Jenan: It didn't seem to me we
had consensus yet on dropping the "active" part
... some class of merchants will want to allow just in time
registration of payment (apps)
... some class will want instant checkout without
registration
... can we have both of these options?
<dlongley> `.requiresRegistration` ?
<adrianba> we can't support active in our implementation
<dlongley> `.enrollmentRequired?`
<adrianba> the proposal currently uses the term "available" but doesn't define it
zkoch: I think that you are right
there is ambiguity here
... the original idea was "true if IMMEDIATE way to pay"
... there was pushback
... the compromise is to drop "active" and allow implementers
to implicitly make it active
... Even if we separated this into two calls, we will run into
the same issue - some browsers may not support the call
... over time, if market forces are strong enough in either
direction I think you will see browsers normalize
adrianba: Our implementation relies on Windows underlying, and that functionality opens UI, so we cannot implement this without presenting UI
IJ: does "not detecting" solve this? (IJ is not sure)
<dlongley> semantics aren't clear to merchants ... so how do they use the method?
Jenan: It's about ambiguity...harder to optimize checkout if you don't know whether you are going to get one-click or whether you want to enable registration
IJ: What about a flag from the
merchant as input like "allowRegistration"
... and implementations can prompt user if they want
zkoch: I agree with Jenan's point
that there is ambiguity.
... at this point we either accept the compromise and let
market/merchant forces drive consistency,
... or we scrap the conversation
Jenan: I am ok with the spirit of the proposal right now and would not block forward progress
dlongley: Ian's suggestion that
the merchant signal could cause this to be a simpler API
... where you don't have to make a separate call..instead you
just make the payment request call with your preference and the
UA can decide whether to reject the request
zkoch: It feels like it pushes the problem out
<jenan> I don't think that solves the problem. canMakePayment true -> show payment request with noRegistration -> nothing available
dlongley: I don't know what they
plan to do in this situation in Edge
... would they say "yes' or "no" when they can't tell?
adrianba: We understand what payment methods are supported. What we can't tell without unlocking the store is whether someone has already provided credentials.
<dlongley> i'll say in IRC...
nicktr: I think there is more to do here. Let's have one more go around
<dlongley> i think this sounds like it may be really specific to basic card
zkoch: I see +1 to the direction. What more concretely needs to be addressed?
<dlongley> and perhaps the real solution is that merchants just provide their own payment app for that case and go with the API?
<zkoch> sgtm
IJ: Propose we resolve "yes" to the direction and give 1 week for updated PR
<adrianba> I think it would be good for us to update the pull request and maybe include more explanation
<adrianba> then we can merge after discussion next week
SO RESOLVED: Support direction of canMakePayment and will review updated PR next week
nicks: I managed to pin down
David Singer for discussion of Feature Policy; I don't think we
have an ETA yet. I would assume that we would not be
implementing it in parallel with payment request API.
... I would be comfortable saying that if the browser does not
support this feature then iframe payments are not
permitted
... that is current Apple functionality
... I will talk to webkit team further
https://github.com/w3c/browser-payment-api/issues/224#issuecomment-263995469
<zkoch> I have to go I’m afraid! Late for next meeting! Thanks, bye!
https://github.com/w3c/browser-payment-api/pull/292/files
https://w3c.github.io/webpayments/proposals/method-practice/#network
IJ: Please review those so we can merge those next week
<dlongley> maybe we need a concept of "temporary payment apps"...
<dlongley> to get the merchant checkout flow into the payment request UI when basic card is used