See also: IRC log
(IJ: Call for consensus going well!)
IJ PROPOSED: CR "comment period" end date of 2017-10-31 (pre-TPAC) for both specs.
<adrianba> this is only the minimum time
<adrianba> so earlier is okay too
IJ: I think not harmful to give extra time (since people traveling in the summer)
<AdrianHB> +1
<mweksler> +1
<dezell2> +1
<adrianba> +1
<zkoch> +1
SO RESOLVED: Min CR review time is 31 Oct 2017
<scribe> ACTION: PR API Editors to update both PMI and PR API with 31 Oct 2017 as "min review" date [recorded in http://www.w3.org/2017/07/20-wpwg-minutes.html#action01]
<trackbot> Error finding 'Editors'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
https://github.com/w3c/browser-payment-api/blob/gh-pages/test-plan.md
<AdrianHB> ian: various people have been reaching out to get test resources. Contributions welcome from WG. Link is to page provided by Mike to help gather contributions
<AdrianHB> ... people should be able to clone the repo and then run the existing tests and writing new ones
<AdrianHB> ... we need to get sufficient coverage of the spec
<AdrianHB> ... Marcos is leading test suite dev project. Anyone who can contribute should contact him.
<AdrianHB> ... He is going to write up a process and share
<AdrianHB> ... We have also been talking to other testing companies. EG: PayCert have joined the WG
<AdrianHB> ... Ken has also introduced me to UL and FIME
<AdrianHB> ... To avoid overlapping work Marcos is coordinating
IJ: the goal is to satisfy the Director that we have achieved interop per our CR exit criteria
AdrianHB: Basic Card not going to
Note just yet.
... AdrianB made a good point that CR is an opportunity to get
feedback, but "Note" implies done, so we'll continue to iterate
until the other specs are further in the process
<zkoch> Nope :)
zkoch: No
adrianba: Don't think so
<AdrianHB> ian: [talks to himself a little]
https://www.w3.org/2017/07/13-prapi-cr-trans-req.txt
<AdrianHB> ... I have begun to draft the transition request
<AdrianHB> ... all going well with CfC so we should have a decision by 25 July
<AdrianHB> ... at which point we present this request to the Director
<AdrianHB> ... I urge editors to review this
<AdrianHB> ... has been reviewed internally within W3M. Questions were raised about open issues
<AdrianHB> ... there are some open issues not marked as CR issues.
<adrianba> yes
IJ: Can you editors confirm you are working to narrow that list?
<AdrianHB> ... editors, can you confirm you are addressing that
{No other PR API comments}
https://w3c.github.io/webpayments/proposals/method-practice/
PMI refers to it informatively
<AdrianHB> ian: PMGP document is stuff moved from other specs. Some support for taking this up in the WG so want to pursue. Also now an informative ref from PMI spec.
https://github.com/w3c/payment-request-info
<AdrianHB> ... asked if we should publish as not but suggestion from chairs was to publish in developer portal
<AdrianHB> ... less visible that way but easier to maintain
IJ: Any pref - Note or dev portal?
<zkoch> he’s fading :)
AdrianHB: Please type "Note" or "Portal" with your preference
<AdrianHB> Dev portal
<zkoch> Portal
Ian: Neutral
<AdrianHB> PROPOSAL: Pick up the Payment Methods Good Practice document as a WG work item and publish in the portal
<MattS> My vote is to start with a single note in the Portal! And then add functionality as needed
<AdrianHB> +1
zkoch: +1
<adrianba> +1 but that isn't volunteering
+1
<MattS> +1
RESOLUTION: Move payment method good practice to the developer portal
<zkoch> ill add to my todo to review
<scribe> ACTION: Ian to move the payment method good practice to the dev portal [recorded in http://www.w3.org/2017/07/20-wpwg-minutes.html#action02]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
https://w3c.github.io/payment-method-manifest/
IJ: I think this is being used!
zkoch: Google is using this. Next chrome version will leverage this.
IJ: What needs to happen to get to CfC for FPWD?
zkoch: Cleanup + prep for CfC
Ian: I volunteer to review it (and may suggest edits to turn it into a WD-like doc).
<adrianba> seems like the scope is set - we should move to FPWD asap
zkoch: This is like web manifest, and we've updated web manifest for our needs
<adrianba> doesn't have to be "done" to do so
<AdrianHB> +1
IJ: +1 to getting to CfC
soon
... Any other reviewers?
... any other parties in the WG making use of it?
... would make good reviewers
zkoch: I suggest sending an email
<adrianba> we'll take another look
adrianhb: We can still get feedback from non-WG people as well
IJ: What is good timing for CfC from editor perspective? Are things changing?
zkoch: Need to update some links, but I think we are ready to go
<adrianba> suggest 1 week for pre-fpwd comments, then prepare for publication, then CfC for 1 week, then publish
IJ: +1 to that calendar
https://github.com/w3c/payment-handler/issues/153
https://w3c.github.io/payment-handler/
https://w3c.github.io/payment-handler/#structure-of-a-web-payment-app
Three use cases drove wallet concept:
Multiple user profiles with a single provider (e.g., business wallet vs personal wallet). (One company that provides tax services expressed interest in this feature.)
White label wallets - one origin provides wallet services for multiple vendors.
Multiple instruments held with a single provider
<AdrianHB> I believe all use cases can be accommodated using subdomains and this is more aligned with the web's origin security model
zkoch: Of those three use cases,
none is uniquely solved by the wallet concept. there are other
ways to solve these with the primitives that have been
provided. But adding wallets adds a lot of complexity, both to
the spec and to the UI
... on mobile in particular.
[Recall that "on desktop" was more likely than "on mobile"]
zkoch: This is not something we'd
be adding visual support for at this time. I think Chrome
philosophy would be for consistency across platforms.
... I think there is little value add, more to test, and more
complexity.
... I agree these use cases exist but are both edge-casey and
can be solved through other means.
[Recall subdomain argument against was that is forced people to manage their web space a particular way ... ]
MattS: I want to add to recollection about subdomains --- you'd also need certs for https and higher cost to create wallets dynamically on an origin
<AdrianHB> Wildcard certs?
MattS: ....would be good to hear from browser vendors whether others would do similar to Google (and not render hierarchy)
<AdrianHB> Another argument against wallets is that they can easily be added later but will be hard to remove
[IJ: Mozilla has in the past said "interesting for desktop" and more recently Marcos said "drop it"]
IJ: I have not heard recently any implementation plans for this.
rouslan: Speaking to the comment
about subdomains - they are a good way to separate your payment
apps (same origin protections)
... but I think it's too heavy of a hammer for this small
nail.
... they way that you can simulate wallets is to have 2 service
workers that are responsible for different scopes
... e.g., one for personal and one for business
... Also, service worker might open a web page for a conf
dialog and in that dialog you can also present different
instruments.
... so I think there are ways to do this without wallet concept
as an API abstraction...
... we can use existing web technologies to solve this
problem.
<Zakim> Ian, you wanted to ask about visual representation in that case
IJ: How do you get a visual distinction in case of 2 service workers?
zkoch: each service worker can
have a unique mapping to its own manifest
... those manifests can be different.
IJ: I am glad there is a manifest approach to this; not sure what dependencies that creates
https://w3c.github.io/payment-handler/#paymentwallet-dictionary
IJ: It's just visual
zkoch: I still see Wallet as unnecessary, the payment handler itself can have a name and icon on it if you don't want to build in too strong a dependency
Summary:
* Can use manifest, but that creates a dependency
* You can get rid of wallet abstraction, but the payment handler itself has somewhere on itself a name/icon/instrument keys
<AdrianHB> Why is a dependency on manifest a problem?
<zkoch> Not a problem from my opinion :)
https://w3c.github.io/payment-handler/#paymentmanager-interface
http://caniuse.com/#feat=web-app-manifest
https://www.w3.org/TR/appmanifest/
<adrianba> i think it is a non-issue
IJ: Question is both web app manifest implementation and status of spec
adrianba: I think there is sufficient work on implementation that web app manifest will stay ahead in the process so the dependency won't be a problem.
<AdrianHB> +1 to adrianba
<AdrianHB> Also noting that implementation of Payment Handler from anyone other than Chrome is still uncertain
Proposal: Drop wallet concept in favor of using N service workers + independent web app manifests
<zkoch> +1
<adrianba> +1
<rouslan> +1
<AdrianHB> +1
<AdrianHB> Request that we get AdamR feedback before we merge this change
<AdrianHB> (As he was major proponent of wallets)
IJ: I Proposal also that we show an example of how to do personal/biz wallets; Rouslan could you write that up?
<adamR> My concern is mostly that you get sign-off from merchants and banks. If they don’t want it, I don’t really care. My concern all along was that we weren’t addressing their use cases.
<AdrianHB> Thanks AdamR
<zkoch> If were were removing use cases, I would agree. But I don’t think we’re removing use cases. We’re just saying “here is how you will do what you want"
IJ: Are other people on this call hearing demand for this?
<scribe> ACTION: Ian to go back to the payment app task force with this discussion and work with Rouslan on example (for in a few weeks) of biz/personal wallet [recorded in http://www.w3.org/2017/07/20-wpwg-minutes.html#action04]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
MattS: The demand from my
perspective would be from Worldpay (not merchants
directly)
... Worldpay would very much like this
<AdrianHB> +1 zkoch - noting that we can bring them back if implementation experience is that they are required
MattS: Worldpay would like this
feature. The two points I've heard in this call saying (1) can
be added later....I sympathize with that (2) no implementers
yet
... so let me say if it's implemented, Worldpay interested in
the feature
mweksler: I think we could potentially use this; but not must have right now
<AdrianHB> @matts - I think you'd use subdomains anyway for security and to isolate your different apps from each other
mweksler: the most compelling
argument to me is walk before we run
... so support "dropping for now as specified"
Our charter expires 31 Dec
scribe: We will start to discuss
rechartering at September calls
... People may suggest features of a revised charter by
email.
IJ: I have a question about the "out of browser" payments part of our charter scope
Proposed: 27 July
IJ: Any regrets?
RESOLUTION: 27 July is next meeting
<adrianba> i won't make it