See also: IRC log
https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
* Change the title (Payment Handler API)
* Update the model description per the Proposal
* Move explanatory information to an appendix
* Add code samples
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md
* AdamR to flesh out his proposal per 28 Feb discussion
https://www.w3.org/2017/02/28-apps-minutes#item02
adamR: I wasn't able to update
the proposal last week due to IETF deadlines; that's likely to
continue to next week.
... so that's ok if you move a lot of things around during that
period.
... part of what I wanted to do with my edits is add in
examples.
... from marcos' document
... I already borrowed IDL...will include exmaples
... I thank we will have incorporated most of what Marcos has
provided...I also think that Marcos created that document to
demonstrate some code and my understanding is that once I've
taken the info into account, he won't develop that document
further
... When you are done with the big structural moves, if you can
tag me let me know.
Discussion of AHB's proposal:
https://github.com/w3c/webpayments-payment-apps-api/issues/91#issuecomment-283111711
is on the WG agenda this week:
https://github.com/w3c/webpayments/wiki/Agenda-20170309
IJ: Anyone want to add to the GitHub issue in favor of sharing line items?
AdrianHB: Line items in payment
request are not the things that you buy
... they are typically things like subtotal, tax, total
... so if a payment app wants full details about what is being
purchased,
... that can be a payment method specific piece of data.
... I think that that's where we are headed on that issue.
<Zakim> adamR, you wanted to ask Adrian a clarifying question
adamR: Adrian, regarding the method you described passing through does that that imply redundancy of information passed through the top level?
AdrianHB: My proposal is that
there's a flag in PR API...and if you want to pass line items
to payment apps you would set the flag.
... zach's point is that we don't expect merchants to use line
items to list products
... if there are no use cases for getting "total", "tax" etc.
then we can drop the proposal, otherwise if there are use cases
(which Klarna's is not an example of), then the proposal can
stand
IJ: Privacy issue goes away if the line items are just used for tax and total information
AdrianHB: The breakdown was to show a change in total based on user actoins
AdamR: I understand the use case
and the google use case, but I suspect that developers will use
the line items for other purposes.
... The number of web developers who read specs for good
practice is close to zero
AdrianHB: I think the only way we
will address the concern from AdamR is to change the API to be
less flexible.
... I also think that Google limits the number of things you
can send through the API
... due to UI consideratinos
... the spec should not hard-code a limit, but I believe there
is one
rouslan: We don't currently
enforce a limit (we use scroll bars)
... we'll probably send a PR on the spec soon that says you can
provide something like 50 shipping options and 50 line
items
... for security reasons
<AdrianHB> If the intent is explicitly to not show shopping cart items then we should limit to 5
Proposal: Payment Handler API for the title
<AdrianHB> +1
<adamR> +1
<rouslan> +1
<jnormore> +1
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md
IJ: Has anybody had a look? What is relationship to Marcos' code?
AdamR: This is input to drive the API; the examples in the spec are meant to explain the API.
AdrianHB: One thing immediately
useful from the code samples is that if you don't have time to
read the whole spec,
... I see the first example and say "Is our intent to get
permission by calling options.set?" Is it implicit? Or do we
want an explicit function to get permissions?
adamR: I think we had an open issue on this.
https://github.com/w3c/webpayments-payment-apps-api/issues/94
https://github.com/w3c/webpayments-payment-apps-api/issues/94#issuecomment-275600989
https://github.com/w3c/webpayments-payment-apps-api/issues/94#issuecomment-275618212
AdrianHB: that example shows an
explicit permissions call
... asking for 'payments' permission
AdamR: yes, this can be incorporated.
AdrianHB: I suggest we respond on the issue and try to get a general approach
AdamR: I am confident in Marcos
and Jake here
... if we want further validation, let's find another person
who is familiar with how web apps ask for permissions.
IJ: Is PaymentManager more clearly captured in the new text (from Adam)?
AdamR: there is a page on the
payment app's web site that installs the payment app...that's
not the service worker
... there is a thing on the service worker registration that is
where we are setting things like supported payment
methods
... but I think this is something else (on window)
- Filtering mostly for w3c (abstraction) specs
AdrianHB: I disagree with
that.
... the whole point of the filtering is that new payment
methods can be introduced that have their own unique
filters
<adamR> I said it last Thursday, but for the record, I disagree with Zach’s characterizatin here. If Chrome wants to do things that way, it’s fine, but I don’t think it should be required of all browsers.
<adamR> And this is particularly distressing when you consider, e.g., Safari, which comes out every 18 to 24 months.
<AdrianHB> ian: we want to be able to support filters for 3rd party payment apps
- payment handler api needs a stnadard way to provide capability information
https://w3c.github.io/browser-payment-api/#show-method
For each paymentMethod in request.[[serializedMethodData]]:
Consult the appropriate payment apps to see if they support any of the payment method identifiers given by the first element of the paymentMethod tuple, passing along the data string given by the second element of the tuple in order to help them determine their support.
IJ: I proposed a more neutral framing to make it possible that browsers do the matching
AdrianHB: Let's get a resolution rather than a neutral stance
IJ: We got again into the security issues
I distinguished two things:
* Unconstrained string syntax
* Unlimited list length
<AdrianHB> IJ: Nick-TR pointed out that generic string matching would also resolve an issue around the ability of networks to get included on the hard-coded network list
https://www.w3.org/Payments/card-network-ids
1) We need to clarify the process for accepting new identifiers. (e.g.,a simple anti-spam verificatino)
2) A disclaimer that appearance in the list is not a guarantee of interoperability across browsers.
<AdrianHB> Sounds like this boils down to: Is there a strong enough case for a hard coded list (enumeration) or can we have a more flexible (but still constrained) list?
<AdrianHB> For the record I would be a big +1 to doing away with the networks list if we can
IJ: Can we basically say (1) here's how you provide capabilities from a payment app and (2) here's in PR Api where that's taken into account, and leave it at that?
adamR: I'm not sure I followed
that...we need to think about these things from the POV of
browsers that are released less frequently, such as every 18
months.
... so a network list that is only infrequently updated in a
browser is a problem.
... I also would like there to be an authoritative list of
network strings (to avoid e.g., amex v. americanexpress
confusion).
<AdrianHB> To be clear, having a list that helps avoid confusion and conflicts is fine but that's different to a list that has a gatekeeper to be added
AdamR: We also don't want
duplicates
... so ok with WG having lightweight approval process and
indicating browser support is independent
<AdrianHB> -1 to "lightweight approval process"
AdrianHB: I don't think there
needs to be "approval". I think you can avoid duplicates
without an approval process.
... an approval process is dangerous
<ConorhWP> I won't interrupt - I need to drop off now. Thanks all, goodbye.
14 March