See also: IRC log
<scribe> scribe: Ian
AdrianHB: Matt Saxon had a
concern that if you wanted to mint a short-string PMI, you had
to go through W3C, otherwise you use a URL which involves
real-world resource considerations.
... this is especially true for organizations that might want
to publish open payment methods (like "basic card")
... use case is orgs that want to publish a payment method
without a manifest
... we would need to define how a user agent behaves when it
encounters a short-string PMI that it does not recognize.
... a proposal is to treat it as an identifier and to match on
it as you would with normal string matching
<dlongley> we probably already have to specify that if the URL is "http" or "https" there could be a manifest ... otherwise maybe not.
<dlongley> URL doesn't rule out non-http schemes
IJ: I have written down privately
what I think needs to change, but relies on seeing updated PMI
spec.
... so I'd like to wait for Zach's updates
... I think this mostly affects PMI and possibly a minor edit
to PR API.
AdrianHB: I think it's a trivial for PR API.
IJ: I agree
Start with proposal from Mahesh:
https://github.com/maheshkk/webpayments/wiki/Detecting-if-payment-app-is-available
<dlongley> also, just because *we* think people won't try and grab short strings ... doesn't mean they won't. (i agree with the approach if our assumption is correct, just not sure about that) ... moving on :)
[Mahesh reviews his proposal]
MaheshK: Recall that Samsung has
both a browser and a payment app.
... we've been talking with Merchants (especially with large
numbers of transactions)
... a very common concern is "they don't have a way to detect
if a particular app is available"
... merchants are very cautious about changes to their
checkout
... they currently show multiple buttons
... to change to the w3c specification, they would want to know
that certain apps are available
... they want to know whether the app is available before they
show a particular button
... the current proposal has browser filtering payment
methods...the default behavior is card checkout
... some merchants think their current checkout is superior to
checkout via the browser
... e.g., they have card on file
... it would be a 1-step checkout from their perspective.
... so the question is how to determine whether a particular
payment app is available.
... the proposal is to add an API
... note that Apple has this API (canMakePayment())
... this is also good for user experience
... hide buttons when apps are not available
... I recognize that this has been discussed...the concern has
been leaking of information
... the proposal here is to delegate the decision to the
payment app.
... the merchant asks the browser to ask the payment app.
... the payment app could, if it has a relationship with the
merchant, could validate the merchant and if so, it could
return a positive to response through the browser that it can
be used.
... if for some reason the app is not available, or the app
does not trust the merchant, then (@@ scribe missed the nature
of the response@@)
... note that payment apps are also learning about merchants,
which leaks a bit of information...so a refinement is that the
merchant can only ask whether a payment app from its own domain
is available.
... note that another approach involves the use of an iframe as
a way to determine trusted relationship
... [Mahesh points out that this sort of thing is already
possible; goal here is to make it easier.]
<Zakim> Ian, you wanted to ask what the specific requirements are
IJ: What is the requirement?
- Is there support for any payment method?
- Is there support for a particular payment method?
- Is there any payment app ready to pay?
- Is my payment app available?
- Is at least one payment app available?
- Is a particular payment app available?
IJ: It feels to me like a new requirement to hide things before the mediator is called.
Mahesh: "At least one of these
payment methods" would be valuable to know.
... that would allow merchants to hide some buttons outside of
that list (since at least one of a preferred list would be
known)
<adamR> So I’m hearing “a particular payment method” from what he just said, if I understand correctly.
AdamR: Due to the timing
differences between two steps, returning an error in step 4 is
a big signal "The app is here but doesn't want you to know." So
for 1.1, the proposal does not protect privacy.
... 1.2 is very clever and may not need additional
standardization
... but merchants could work with app providers to be installed
at a particular point.
... I agree that 1.3 is not elegant, and that the flaws are
larger than any benefit it might provide
dlongley: I think I would always
want the option to pay with my open app, even with basic card.
I would not want to be forced to go through the merchant
checkout.
... my app might be doing things i want it to do
... another option is to put info in the page (user agent?) but
not allow merchant access to it.
<Zakim> jnormore, you wanted to give merchant perspective
jnormore: From a merchant
perspective, it is important to show options before
mediator
... Shopify does this today...and the reason is that right now
we cannot provide our own app for basic card.
... one of the biggest reasons we want to detect whether a
payment method/app is available is because of the user
experience
... whether within the mediator or before
... we don't want to show, for example, Apple Pay as the
primary method of payment if the device does not support or the
card is not set up
... the same would go within the mediator's display
... we would not want the user click on a button only to get a
message that says "not available"
... we would especially not want unsupported apps/methods to
show up high in the list
IJ: Which of the requirements that I named is important to you?
jnormore: "one of the following
payment apps" still enables the possibility of showing buttons
that the device does not support.
... it's ok if the merchant doesn't get the information, but at
least the mediator needs the information.
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions
IJ: it feels to me that we are able to specify mediator behavior (in the dropdown list) but more out of scope to say what happens before the mediator runs.
jnormore: With Mahesh's proposal, even if the merchant doesn't show the buttons in the web page separately (and they are relying on the mediator), then at least they are able to eliminate unsupported things from the mediator's list.
MaheshK: To AdamR's points - the
timing is a legitimate issue for fingerprinting
... I would still like to make the point that "this is already
possible"
... a payment app that could have something like a cookie or
service worker that merchants can use to determine app
availability.
... for merchants, knowing "at least one payment app is
available" is the MOST IMPORTANT information
<dlongley> "the merchant knows its experience is better" is impossible knowledge, IMO.
AdamR: You are correct that
there's nothing that prevents parties from colluding. Those
interactions are controlled through CORS and other mechanisms
that requires both sides to opt in.
... i'm concerned that the proposal leaks information that we
don't want shared
<dlongley> +1
AdamR: the fact that it "can be done" without us adding anything, in a way that leverages web platform privacy mechanisms, suggests we don't need to add anything
<jnormore> dlongley: whether it is better or not is irrelevant, if the merchant *thinks* theirs is better and they can't use it it will prevent adoption of the spec
AdamR: I would not want to see the shape of 1.1 go forward
dlongley: Trying to find out whether a payment app is available....if a merchant runs its own app it can always make available basic card, installed on demand, and used by PR API
jnormore: It's not really about
basic card. Merchants should be able to implement their own
payment app....but we don't have the payment app spec
yet.
... my point is mostly about non-basic-card payment
methods
... we don't want to show the apple pay button if the user's
device does not support apple pay
... we may want to change the order based on whether the app is
available
<MaheshK> +1 jnormore
<dlongley> not just privacy, i want app functionality
<dlongley> but privacy is also important.
AdrianHB: I think it's not well-understood what's available in the merchant toolkit today
<dlongley> +1 exactly, merchants can write a payment app to offer a better experience (for that particular concern)
AdrianHB: merchants can mint PMIs and implement payment apps
<dlongley> without infringing upon other app developers and user's desires to use certain apps.
https://github.com/w3c/browser-payment-api/pull/292/commits/af2d188ee7df21e9a8f35e57a73f828dc96d7923
Roy: We discussed on Tuesday push payments
<Roy> https://www.w3.org/2016/10/18-wpwg-push-minutes.html
Roy: we settled on this scope for a problem statement:
"enable merchant to know authoritative info on transfer or pending transfer (in case of failure)"
scribe: we came to ground on two pieces:
- mediator generates a unique TX ID that is part of the payment request object
- merchants can specify callback URL for PSPs to send TX ID + payment method identifier + any payment method specific data.
scribe: so that is the heart of
my pull request
... callback URL from merchant is optional
... but when provided, enables the authoritative source of
information (through server or payment app) to deliver a
response to the merchant outside the browser flow.
<dlongley> we may want to coordinate with Web Payment HTTP API on this.
IJ: Additional note: the shape of the status is payment method specific. So merchant gets back: transaction ID, payment method, status data
AdrianHB: One of the reasons we
think that this approach is useful is that it is cross payment
method - so that merchants can provide a single service to be
called back, and it will work across payment methods
... transaction ID is used for reconciliation
<AdrianHB> +1 on HTTP API sync
dlongley: I want to agree largely with what AHB is saying; it may help to coordinate with the web payments HTTP API...we are looking at sending a payment response to an HTTP end point
<Roy> great idea, I hadn't thought of that, I'll look into it
<AdrianHB> ... or maybe just HTTP API MEssages spec
<Zakim> Ian, you wanted to mention why we preferred merchant-provided URL rather
IJ: One bit of rationale for why
we favored merchant URL over ability to ping the PSP - current
practice where PSPs avoid too much traffic
... please comment on Roy's PR
... let the full set of editors know about your support (or
not) of the proposal.
AdrianHB: I originally proposed
hosting us in Captetown in Feb...but I realize it's a long way
to travel. Therefore, I am looking into other work-related
events to make it a worthwhile visit.
... Ian also suggested that we might want to coordinate a
meting alongside IETF 98 in Chicago; proposal is 23-24
March
... We will also meet in TPAC (Nov, near SFO)
... so that raises one additional question - should we meet in
July/Aug?
<scribe> ACTION: Ian to start a thread on proposals for next meeting [recorded in http://www.w3.org/2016/10/20-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).
Next call: 27 Oct. (Regrets: AHB).
- We plan to meet weekly through the year except for 24 Nov, 22 Dec, 29 Dec.
- NOTE: 3 November call will be 1 hour earlier for many people (e.g., Europeans) due to end of DST.