See also: IRC log
<manu> Ian: I've started to work on an end of year Blog post at the end of the year, talking about progress, topics we've been looking at.
<manu> Ian: Some payment method spec advancements, keep an eye out for that.
<manu> Ian: The purpose is to give a high-level mention of topics for folks not closely following this work.
<manu> Ian: In Lisbon, we discussed advancement to CR - take away was that folks wanted to see third party payment apps further along. Test suites, a couple of other things, I feel like we've made substantial progress on 3rd party payment app API. The Task Force resolved to go to FPWD for that spec. Trying to get what we can get done between now and then.
<AdrianHB> +1 on Payment Apps progress
<manu> Ian: So late January, early Feb, we'd have FPWD of Payment Apps API
<manu> Ian: We're getting lots of edits/refinements of Payment Request... it's solidifying, we're getting deployments, if we look ahead, going to CR in February timeframe, one of the CR entry criteria is wide review. Can we start wide review process in early January?
<manu> Ian: Since we have auto-publishing, all changes are in TR page, now I can point people at those specs comfortably. For example, have discussions with Privacy IG. Can we begin outreach, wider review of specs, make decision to go to CR -we've fulfilled that portion of that criteria.
<Zakim> manu, you wanted to be concerned
manu: My read for payment apps
further along is we want to see implementation
... I have no problem with getting review of PR API (the wide
review part)
... We still haven't answered the digital signature question
around payment requests
<manu> Ian: I think that we can get wide review and that is independent of the need to close additional issues. I can't guarantee that there won't be new issues raised. We can continue to get wide review, so people can get a broader sense of these specs.
<manu> Ian: Regarding payment app implementation - we're getting implementations. We know of native implementations, we are also doing experimentation with web-based payment apps.
<manu> Ian: That is not a criteria for getting to FPWD, but there is a request to understand if web-based payment apps work with the Payment Request API.
<manu> Ian: Regarding digital signatures, that's something that as a group, we'd want to address known issues (https://github.com/w3c/browser-payment-api/issues/291) before requesting to go to CR. I'm not suggesting that we rush that, only that we start the process of getting wide review, because that takes a while.
<manu> All that sounds good, Ian.
Ian: Thanks Manu
<manu> Ian: The sense I have from watching the Github discussions, implementers increasingly want stability, we've tried to move faster with PaymentApp API, we may get pushback from implementers of significant changes.
<manu> Ian: It's thrilling to have implementations, people are excited about that.
<manu> Ian: When we get wider review, we may face some challenges. That's the reality of doing this work.
AdrianHB: You've listed digital
signatures as an issue you think we need to resolve before we
go to CR
... are you satisfied if we say "The group has decided digital
signatures are a payment methods specific topic"
Manu: The issue is "what is our
strategy around digital signatures" and if our response is
"it's per payment method" then I think it's not good enough; I
want to ensure the group realizes it's painting itself into a
corner
... it's not that I'm preposing a particular signature
approach, I would like to have clarity around strategy
Manu: No objection from me to
putting out a call for pre-CR review; that's good and
healthy
... we'll get reviews and then we'll have to show more review
over changes
NickTR: I hear no objections to starting the process of soliciting wide review
<manu> Correct, no objections (from me)
<AdrianHB> +1 let's start wide review process
<scribe> ACTION: Ian will begin soliciting wide review of PR API in January 2017 [recorded in http://www.w3.org/2016/12/15-wpwg-minutes.html#action01]
adamR: I can't speak to the issue itself, but what I want to verify is whether we are doing this for "payment methods" or "active payment methods"
rouslan: The current text is
silent on whether it's active or not. The Edge plan is to
always return "true" for basic card
... the Chrome plan is to check whether the autofill store has
info and return "true" accordingly
... but this is left to the implementer
AdamR: And both are considered explicitly valid?
Rouslan: Yes
mahesh: Here's an update on the pull request
<pascal_bazin> Sorry I'm late
mahesh: I spoke with Zach and he
proposed to make some editorial changes to the PR
... Domenic Denicola is also reviewing it
... so it will be modifications to the current pull request.
<AdrianHB> https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md
adrianba: Zach and I met
yesterday and we merged the new pull request.
... we anticipate making some further changes
... this pull request doesn't distinguish active v. not
active
... that's kind of by design, but the conversation Zach and I
had was, based on WPWG discussions and the fact that we use the
word "support" to mean different things in the specification, so we need to elaborate
on the text that's there for clarity
... so that's now in the current spec and available for
review
... we intend to add a note indicating that it's valid to limit
"support' to mean "active" and also valid to not make that
check
<manu> Ian: Matt Saxon has been concerned about issue 367, was closed prematurely
adrianba: Right now the language
in the spec leaves it to implementations to make a
determination about "the right way of limiting"
... nobody is happy with timeout alone, even though timing is
mentioned as a consideration
... we will probably change how we do this over time
<manu> Ian: So, I'm hearing that the issue should stay open.
adrianba: I don't think we
need to say anything elsein the specification and therefore
would close the issue
... changes and experimentation will continue after the spec is
frozen
<manu> Ian: I don't think Matt Saxon is on the call, we could ask him if he's ok to close the issue (but I don't think he is yet). So let's wait before closing it.
nicktr: Thanks IJ for raising the issue that Matt is tracking; with my Worldpay hat on, I'd like the issue to stay open for now....the question is whether we signpost that in the spec or not.
IJ: Regarding the question of
PR API encryption and tokenization: I will put tokenization and
credit transfer on a January agenda
... progress on both!
<manu> Ian: Based on filtering, use of URLs, etc. we've updated the >PMI Specification.
<manu> Ian: There are still a number of issues, notably around Manifest spec, but AdrianHB raised some issues, before we get to those, there is one particular one... Issue #17
<manu> Ian: We said that we constrained the shape of URls for PMIs, which include HTTPS every time. AdrianHB raised if that was overly constraining because of things he cited in the issue. Let's discuss
Text from AdrianHB's issue:
-----
There is a concern that having browsers all over the world fetching a manifest all the time will put significant strain on the hosts of the manifest.
There are protocols that are better at serving static content than HTTP such as IPFS. While they're not supported in most browsers yet, they may be soon.
So, should we be limiting the PMI URLs to https as the scheme or rather wording this as something that requires fetching the manifest through a SecureContext or similar?
----
Ian: There is a link from the spec to that issue
AdrianHB: HTTPS is restrictive in
terms of how a manifest is hosting
... hosting a manifest is potentially a resource-intensive
thing (for popular payment methods)
... while there are CDNs and cachgin, and there are better
protocols e.g., for distribution
... so I would prefer we not have this limitation to HTTPs
<Zakim> manu, you wanted to provide input, if that would be helpful.
manu: +1 to AdrianHB's comment; I
would not restrict to HTTPs
... the spec can say something about expectations for secure
transport (e.g., HTTPs)
AdrianHB: +1 to HTTPs as an example
rouslan: +1 to not saying HTTPs and talking about secure hosting
<manu> Ian: We have a draft payment method manifest spec (also on the agenda, but we may not get to it today). That seems to be the appropriate place for discussion of secure hosting of payment method manifest files.
Ian: One piece of implementing a loosening of the constraint is to delete "The URL scheme MUST be https. " from PMI spec. So, this would mean that it's no longer a syntax of the payment method identifier.
<manu> Ian: There is another conversation that's happening, whether to merge the PMI spec with the payment method manifest spec. I don't think there will be substantive impact to merge specs, but we could discuss more.
<scribe> ACTION: AdrianHB to propose changes to PMI spec and Payment Manifest spec regarding loosening of the HTTPs syntax requirement and secure payment method manifest hosting [recorded in http://www.w3.org/2016/12/15-wpwg-minutes.html#action02]
<trackbot> Created ACTION-40 - Propose changes to pmi spec and payment manifest spec regarding loosening of the https syntax requirement and secure payment method manifest hosting [on Adrian Hope-Bailie - due 2016-12-22].
See issue 19
<manu> Ian: There are proposals for: Hard-coded URL, HTTP Link Header, Content Negotiation, Serve JSON for PMI, then link to human readable content from there.
<manu> Ian: Those are four proposals on the table, some pros and cons based on what folks suggest. We need to figure out which of those we want to do. Are there any other options people have considered?
<manu> Ian: There is a related issue for payment app identifiers (as AdrianHB started to discuss), but should postpone payment app identifier discussion after payment method identifiers.
<manu> Ian: In the Payment Method Manifest spec there is a section called "Manifest File Addressing." I cheated and am leaning in the direction of an algorithm; we should determine whether we want a cascade. For example, you can use HTTP Link headers, and if that doesn't give you an answer, you can use a hard coded URL. Maybe not restrict and allow for more than one method via an algorithm. For example, HTTP header takes precedence over hard coded URL.
AdrianHB: I have a few questions
about the options in that issue.
... first high-level question - for a link header what would be
the URL I would be visiting?
IJ: The payment
method identifier URL. You do a Head request on the
PMI
... and we would register the header type with IANA
AdrianHB: So I am hearing that
the PMI points to (a potential) machine readable page, and HEAD
on the PMI gives you a link for a registered header type.
... so options 2 and 4 seem relatively interchangeable
adamR: We can add new link
relations in the HTTP Link approach, but option 4 does not
allow that
... Regarding an algorithm...we accrue the list of "cons"...I
would steer us away from that approach
<manu> Ian: One of the limitations of option #1 - you can only have a single manifest file.
<manu> Ian: In different jurisdictions, you may want to serve different manifest files, therefore, having the ability to only get one takes you closer to content negotiation.
<manu> Ian: You may be able to address multiple manifest files.
<manu> Ian: Are there real world use cases for having different manifest files is useful?
<manu> Ian: Or, would you serve different files and you don't need to address them differently.
<Zakim> AdrianHB, you wanted to consider the ability of servers to do HEAD properly for option 2
AdrianHB: One of the cons listed
for conneg is the challenge of setting up servers; I appreciate
that can be difficult to do
... but I am wondering how easy it is to set up Link
headers
... is it possible to do HTTP Link stuff via <link>?
<Zakim> manu, you wanted to wonder if conneg is a problem for payment method creators? How many of these folks are out there? Aren't they technically capable?
manu: I don't think there will be
a lot of payment method manifest files; maybe several
hundred
... I think that it's not that hard to do
<AdrianHB> +1
<manu> Ian: There are concerns to caching as well
<AdrianHB> (proxy support is a concern with conneg I think)
adamR: I was also going to say that, in terms of entities that will create these identifiers, those entities will have no difficulty with link headers config
<AdrianHB> adamR:... or headers (option2)
IJ: Remind me whether servers look at META for Link headers?
Shane: Not in general
<manu> Ian: There are four options listed, suggestions about other options and support for existing four are welcome.
IJ: Welcome both other options
and indications of support or concerns about the existing
4
... will return to this in January
---
Any optimization desirable for the case where someone wants to say "I have a URL for my payment method and want to allow any payment app to implement it; but don't want to host a manifest file."
---
<manu> Ian: Matt was concerned around the ability for W3C to mint new URLs w/o paying the cost for serving manifest files where everyone else does.
<manu> Ian: We don't want to prevent people from minting short names, but they need explicit support in browsers for shortnames.
<manu> Ian: There are modern techniques for managing server load wrt. multiple trips to get manifest file and server load in HTTP/2 and proper config, these are much less significant performance issues. We should go in the direction of good practice to help them do the right thing.
<manu> Ian: There may or may not be a connection to the approach that we're going to take for the addressing. We should hang on to this, don't recall if we have an issue for this explicitly. We should not lose sight of this wrt. payment method good practice note.
<scribe> ACTION: Ian to add a note to the payment method good practice spec to not lose track of the performance topic [recorded in http://www.w3.org/2016/12/15-wpwg-minutes.html#action03]
nicktr: I am seeing traction within EMVCo to engage with W3C on basic and tokenization topics
<manu> Ian: Asking for input on the Proposal to Manage Card Network Identifiers Separate from Basic Card Spec. This will also be relevant for the credit transfer and tokenization specs. Please provide feedback.
<Zakim> nicktr, you wanted to note all those short names are EMVco members
<scribe> ACTION: NickTR to ask EMVCo if they would be ok with our use of short strings this way [recorded in http://www.w3.org/2016/12/15-wpwg-minutes.html#action04]
<trackbot> Created ACTION-41 - Ask emvco if they would be ok with our use of short strings this way [on Nick Telford-Reed - due 2016-12-22].
<adamR> Tentative +1 to put network names in their own spec (or registry, but W3C doesn’t have a registry story….)
Next teleconf is 5 January
PROPOSED: Next WPWG FTF meeting is 23-24 March in Chicago
<adamR> +1 for date and city
<AdrianHB> +1 with dates and venue
<dezell> Does this mean the IG can or can't meet alongside those dates?
IJ: That is not precluded; I just focused on scheduling and funding the WPWG first.
<nicktr> +1 for dates and venue
RESOLUTION: Next WPWG FTF meeting is 23-24 March in Chicago
<MaheshK> Happy Holidays everyone!