See also: IRC log
<scribe> Scribe: Ian
<oyiptong> Regrets today
<nicktr> agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170126
<AdrianHB> PR: https://github.com/w3c/webpayments-method-identifiers/pull/21/
AdrianHB: Reworded to say that
the resource must be fetchable securely
... allows some flexibility
<scribe> New text:
+ <p>When URIs are used for payment method identifiers they MUST be absolute URIs including only the schema, authority, and path parts. The URI must be usable as a locator, (a URL) such that user agents are able to locate and fetch the payment method manifest identified by the URI. The URI scheme MUST support fecthing the resource in a secure manner (e.g. https). These URLs MUST NOT include query string parameters or fragment identifiers.</p>
<adamR> I’m okay with this change.
(IJ notes a typo)
<nicktr> notes a tiny nit: spelling of 'fetching'
IJ: Should we say UAs ignore query/fragment as more of a processing requirement?
AdrianHB: That bit could move as well to the section on matching
(Ian does not feel strongly about that particular change)
rouslan: I suggest we preserve
the original intent of requiring no fragment identifiers or
query string. I suggest that the user agent ignore any URL that
has a fragment / query string rather than ignoring the
offending parts
... that reduces the cost of parsing
... browser can do a match on the URL and reject it if not
well-formed
AdrianHB: I will refresh the PR based on these comments
<adamR> +1
+1
(I also suggest merging your sentences 2 and 3)
nicktr: There is a new task force
at EMVCo called "Secure remote commerce"
... they are looking at how to do payments on the Web. They
recognize the work we are doing her is important.
... it would be good for the organizations to work together;
there may be challenges (e.g., visibility of
proceedings)
<scribe> ACTION: nicktr to work with Ian to help foster EMVCo/W3C formal relationshiop [recorded in http://www.w3.org/2017/01/26-wpwg-minutes.html#action01]
<trackbot> Created ACTION-45 - Work with ian to help foster emvco/w3c formal relationshiop [on Nick Telford-Reed - due 2017-02-02].
nicktr: I have volunteered to be
the conduit in the short-term
... There's an EMVCo meeting just prior to the WPWG FTF
meeting; good time for a sync-up
... e.g., around tokenization and architecture
... also payment apps
... I came away from the conversation with EMVCo feeling
positive. We will need to work through issues such as time
scales for deliverables and communications mismatches
IJ: Please work to get review comments real soon now so we can discuss any important ones at the FTF meeting if necessary
nicktr: Regarding use of strings
for network names (and EMVCo)...I would characterize the
response as (1) this is not really for EMVCo, it's a question
for the individual networks and (2) at least one short name
there is not an EMVCo member
... I've asked them to carry the question to their
membership
Card Network Identifiers Approved for use with Payment Request API
https://www.w3.org/Payments/card-network-ids
IJ: W3M has committed to maintenance
PROPOSED: We adopt https://www.w3.org/Payments/card-network-ids for reference from Basic Card
<rouslan> +1
<adamR> +1
IJ: Tokenization will also point to this list
RESOLUTION: To reference https://www.w3.org/Payments/card-network-ids
<ShaneM> ship it
IJ: How is it going? Do we need more resources?
ShaneM: I have not made progress
on this.
... I expect to have more time in a week or so
Mike: There hasn't been anything
happening with the test suite for a while
... one of the reasons is that the mechanism we need to test
requires that we do something more than we can do in JS
... we need to emulate a payment transaction in a way that
gives us a payment response that we can work with
... we know there are ways to do this but somebody needs to put
together something to do it
Mike5: So there's an opportunity
for others to help out here.
... I can help people who want to get up to speed on how the
test suite works (the JS part)
... there is a python server built in
... we built our test runner on top of that
... the web server that serves the test suite locally
... we need someone with cycles
<Zakim> ShaneM, you wanted to talk to the server-side python server stuff
<ShaneM> Note that there is some infrastructure in place for providing the server-side activity. Web Annotations and ARIA both have nice server-side components that we can leverage.
<ShaneM> There is also a Javascript component from Annotation testing that we could leverage to get a client-side payment thing started.
IJ: This is a call for help to develop the emulator
Roy: Please contact me
<scribe> ACTION: Shane to work with Mike to reach out to Stan and Roy re: test suite help [recorded in http://www.w3.org/2017/01/26-wpwg-minutes.html#action02]
<trackbot> Created ACTION-46 - Work with mike to reach out to stan and roy re: test suite help [on Shane McCarron - due 2017-02-02].
Payment Method Manifest Specification
https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html
<nicktr> Issue 19: https://github.com/w3c/webpayments-method-identifiers/issues/19
IJ: How is it going re: HTTP Link headers?
rouslan: We've looked into it.
Looks easy and also well-supported
... we can reuse the logic.
... so we support the HTTP Link header appraoch
<ShaneM> Yes - there is a lot of reliance on link headers at the W3C.
https://github.com/w3c/webpayments-method-identifiers/issues/19#issuecomment-274484201
IJ: Any other implementer experience?
<Zakim> AdrianHB, you wanted to say I'd like us to allow content neg
IJ: Any more thoughts on "just do
it one way" v. "cascade"?
... Pros and cons to each
adrianHB: I feel like link
headers we picked because it was easier to implement than
Conneg
... but I still think that conneg is the better way to do
this
... I think we should support it as well
<adamR> -1 to conneg
<ShaneM> I feel like conneg is way way harder to get right than link headers. And link headers are ubiquitous.
Ian: I suggest we pick this one
and get more implementation experience since it is supported
and also architecturally fine
... let's keep simple
AdrianHB: Ok to not complicate
nicktr: I am hearing consensus to move in the link header direction
PROPOSED: Resolve issue 19 with the solution of HTTP Link headers
[Checking in with Samsung]
Alan: the last time I spoke with Mahesh he felt the existing proposal was workable
IJ: Can we get Samsung to weigh in on this proposal by next meeting?
Alan: I will try to help get a decision
<scribe> ACTION: Alan to try to get Samsung to weigh in on issue 19 for decision by 26 [recorded in http://www.w3.org/2017/01/26-wpwg-minutes.html#action03]
<trackbot> Created ACTION-47 - Try to get samsung to weigh in on issue 19 for decision by next meeting [on Alan Marshall - due 2017-02-02].
https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html
IJ: Can we hear from editors / implementers on plan for advancing this spec?
Max: I think for the next step
for this proposal, we can update it according to our
discussions and to reflect changes
... if there are any other people interested in the spec,
please make suggestions
... regarding the timeline, if we can get consensus on the
direction of the proposal....
IJ: How about work on the spec to get mature proposal in place by FTF?
Max: +1
... would like to get WG support at meeting or soon after
IJ: Would you be willing to work with Zach to get a plan for next wek?
Max: +1
<scribe> ACTION: Max to work with Zach on a plan for advancing Payment Method Manifest [recorded in http://www.w3.org/2017/01/26-wpwg-minutes.html#action04]
<trackbot> Created ACTION-48 - Work with zach on a plan for advancing payment method manifest [on Dapeng Liu - due 2017-02-02].
(For Nick): Any PR API issues we need to discuss?
AdrianHB: What about payment apps?
AdrianHB: Marcos Caceres has
written an alternative proposal and we are hashing it out in
the payment app task force.
... but part of Marcos' proposal affects PR API
... we are going to discuss in the task force whether we think
this is the right approach
IJ: Despite short term chaos, I
think this is all very good for the spec
... also "ordinary" to have this friction when small group
encounters views from first-time readers
Mike5: I've read through the
threads but I've not been involved as much in the payment app
spec
... in general I would say that I've worked with Marcos (and
Jake but not as long)....I value their insights based on my
experience with them
... understand that disruption can create annoyance, but it's
good to pay that cost early
Ian: +1
[Mike5 recounts similar experience with PR API]
Mike5: I agree with Marco's position to reuse Web platform primitives
<Zakim> Mike, you wanted to comment
adamR: Thanks, Mike. I wanted to
point out that a lot of the changes that Marcos has
proposed.....the reason we are taking in a particular direction
has to do with feedback from merchants and payment
providers
... so we have to balance needs and web model
... we are taking into account priority of constituencies as
well
IJ: Our goal is to work it out and have something robust at the FTF meeting
Mike5: This is not about architectural purity.
2 February
FTF meeting please register:
https://www.w3.org/2002/09/wbs/83744/wpwg-201703/
<nicktr> thank you everyone