IRC log of wpwg on 2017-01-05
Timestamps are in UTC.
- 14:58:07 [RRSAgent]
- RRSAgent has joined #wpwg
- 14:58:07 [RRSAgent]
- logging to http://www.w3.org/2017/01/05-wpwg-irc
- 14:58:09 [trackbot]
- RRSAgent, make logs public
- 14:58:09 [Zakim]
- Zakim has joined #wpwg
- 14:58:11 [trackbot]
- Zakim, this will be
- 14:58:11 [Zakim]
- I don't understand 'this will be', trackbot
- 14:58:12 [trackbot]
- Meeting: Web Payments Working Group Teleconference
- 14:58:12 [trackbot]
- Date: 05 January 2017
- 14:58:56 [adamR]
- adamR has joined #wpwg
- 14:59:57 [pascal_bazin]
- pascal_bazin has joined #wpwg
- 15:00:33 [Adam_]
- Adam_ has joined #wpwg
- 15:00:45 [Ian]
- Ian has changed the topic to: WPWG Conf Call - 5 January https://github.com/w3c/webpayments/wiki/Agenda-20170105
- 15:00:48 [Ian]
- agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170105
- 15:01:17 [Ian]
- present+
- 15:01:22 [Ian]
- present+ Olivier
- 15:01:25 [rouslan]
- rouslan has joined #wpwg
- 15:01:27 [Ian]
- present+ Pascal
- 15:01:30 [adamR]
- present+
- 15:01:34 [Ian]
- present+ Rouslan
- 15:01:44 [Ian]
- regrets+ Nick
- 15:01:49 [Ian]
- Chair: AdrianHB
- 15:03:23 [Ian]
- present+ AdrianHB
- 15:03:26 [Ian]
- present+ Alan
- 15:05:00 [stan]
- stan has joined #wpwg
- 15:06:19 [Ian]
- present+ Stan
- 15:06:21 [zkoch]
- zkoch has joined #wpwg
- 15:06:28 [Ian]
- present+ zkoch
- 15:06:55 [Ian]
- https://github.com/w3c/webpayments/wiki/Agenda-20170105
- 15:07:05 [Ian]
- topic: Deployment
- 15:07:15 [Ian]
- https://github.com/w3c/webpayments/wiki/Adoption2017
- 15:07:40 [Ian]
- Proposed time /date is 20 January at noon ET
- 15:08:32 [Ian]
- [review]
- 15:08:45 [Ian]
- call for review: https://lists.w3.org/Archives/Member/chairs/2017JanMar/0002.html
- 15:10:14 [Ian]
- topic: Manifest Specification
- 15:10:23 [Ian]
- https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html
- 15:11:08 [Ian]
- IJ: Any experimentations that should be reflected in this spec?
- 15:11:45 [Ian]
- zkoch: As we've explored third-party apps we've expanded a bit to solve various use cases like certificate change
- 15:11:49 [oyiptong]
- oyiptong has joined #wpwg
- 15:11:49 [rouslan]
- q+
- 15:12:03 [Ian]
- ...but these would fall under the "Android" heading of a payment method manifest file
- 15:12:04 [Ian]
- q+
- 15:12:20 [Ian]
- ...I think the biggest open question is probably the addressing question
- 15:12:38 [Ian]
- ...how do you get the manifest file given the payment method identifier?
- 15:12:49 [Ian]
- This is issue 19
- 15:12:52 [Ian]
- https://github.com/w3c/webpayments-method-identifiers/issues/19
- 15:13:46 [Ian]
- rouslan: the manifest file spec shape comes from Google/Alipay discussions
- 15:14:04 [Ian]
- ..the Web section aligns with the payment app api spec
- 15:14:14 [Ian]
- ..in the payment app api spec we talk about manifest format (not files)
- 15:14:42 [Ian]
- so the manifest file format has web and extension points
- 15:15:06 [Ian]
- ...and the manifest format also allows some scoping of which payment apps may be used to implement a payment method
- 15:15:07 [Ian]
- q?
- 15:15:10 [Ian]
- ack me
- 15:16:15 [rouslan]
- q+
- 15:17:01 [pea13]
- pea13 has joined #wpwg
- 15:17:03 [canton_]
- canton_ has joined #wpwg
- 15:17:05 [zkoch]
- q+
- 15:17:30 [Ian]
- IJ: Need to address big issues like security here
- 15:17:33 [Ian]
- ack rou
- 15:17:45 [Ian]
- rouslan: Definitely issues about security and who can do what needs to be spelled out
- 15:17:51 [adamR]
- q+
- 15:18:32 [Ian]
- ...one thing that zkoch mentioned that is important is how to map between the payment method manifest file, the way to invoke the payment app, and the payment method and payment app identifier
- 15:18:35 [Ian]
- (Issue 19)
- 15:19:01 [Ian]
- rouslan: If you have a payment method manifest file, that file describes how to get the payment app
- 15:19:25 [Ian]
- ack zk
- 15:20:06 [Ian]
- zkoch: Ian is right - there is clearly a lot to be written...
- 15:22:05 [Ian]
- ack ad
- 15:22:26 [Ian]
- adamR: I do think that writing down the issues in the doc is a good idea
- 15:22:33 [Ian]
- ...I have a strong opinion about defaults
- 15:23:09 [Ian]
- https://github.com/w3c/webpayments-method-identifiers/issues/19
- 15:24:13 [adamR]
- q+
- 15:24:23 [Ian]
- ack a
- 15:24:36 [Ian]
- adamR: -1 to "more than one way to do this"
- 15:24:44 [zkoch]
- q+
- 15:24:47 [Ian]
- ..you end up with non-overlapping choices by implementers
- 15:24:49 [Ian]
- ack zk
- 15:25:09 [Ian]
- zkoch: I think realistically the two ideas with the most traction are HTTP link headers and known string (options 1 or 2)
- 15:25:28 [rouslan]
- q+
- 15:25:29 [Ian]
- ...I'm ok with either one. Let's pick one and go with it and see how it plays, then come back and change if we need to.
- 15:25:47 [Ian]
- ack rou
- 15:26:00 [Ian]
- rouslan: HTTP Link headers...is that what goes into Web page?
- 15:27:00 [adrianba]
- https://www.w3.org/wiki/LinkHeader
- 15:27:02 [AdrianHB]
- q+ to ask which format is mandatory
- 15:27:21 [Ian]
- rouslan: If server-level config, this means that we'd not be able to handle payment methods on github, for example
- 15:27:38 [Ian]
- ...what is level of support for HTTP Link headers?
- 15:27:57 [zkoch]
- This is just HTTP I think
- 15:27:58 [Ian]
- ack A
- 15:27:58 [Zakim]
- AdrianHB, you wanted to ask which format is mandatory
- 15:28:23 [Ian]
- adrianhb: If we have dev documentation and also machine readable.
- 15:28:35 [adamR]
- Not worth taking time on the queue, but Firefox most certainly implements Link: headers
- 15:28:41 [Ian]
- ...it feels to me that the human-readable info is OPTIONAL and the machine-readable thing is MANDATORY
- 15:28:59 [Ian]
- ...and so perhaps we should favor the payment method identifier pointing to the machine-readable information
- 15:29:01 [Ian]
- ...and the JSON points to documentation
- 15:29:11 [zkoch]
- q+
- 15:29:15 [Ian]
- ...that feels to me like the right priority
- 15:29:17 [rouslan]
- q+
- 15:29:17 [Ian]
- ack zk
- 15:30:19 [Ian]
- zkoch: I agree with the prioritization (machine-readable is most important). It seems to me ok to pursue both worlds.
- 15:30:26 [Ian]
- q+
- 15:30:29 [Ian]
- ack rous
- 15:30:44 [Ian]
- rouslan: One thing to keep in mind - android pay has a bunch of documentation
- 15:30:59 [Ian]
- ....serving JSON from that space is probably not feasible
- 15:31:12 [Ian]
- ...and asking merchants to switch URLs would be a burden
- 15:31:14 [Ian]
- ack me
- 15:33:00 [AdrianHB]
- To be clear, proposal is to have PMI point to JSON and use link header (or link within JSON) to point to human-readable.
- 15:33:02 [zkoch]
- -1 on 4 :)
- 15:33:09 [Ian]
- IJ: Option 4 favors the data and is basically "2" but inverted
- 15:34:21 [Ian]
- zkoch: I think it's easier for people to find human-readable documentation when they are hunting around
- 15:34:28 [Ian]
- ...so I would put that first.
- 15:34:42 [Ian]
- ...it's not really that hard to do both worlds (e.g., via HTTP Link Headers)
- 15:35:13 [Ian]
- zkoch: Known assets works
- 15:35:27 [Ian]
- q?
- 15:35:45 [adamR]
- q+
- 15:35:48 [Ian]
- ack ad
- 15:35:56 [Ian]
- q+ with a proposal
- 15:36:08 [Ian]
- q?
- 15:36:26 [Ian]
- [Review of link headers]
- 15:36:27 [adamR]
- BTW, http://www.rfc-editor.org/rfc/rfc5988.txt
- 15:37:27 [Ian]
- q+ to talk about proposal next steps
- 15:37:56 [Ian]
- adamR: .well-known is for constrained situations (that we are not in)
- 15:38:02 [Ian]
- ack me
- 15:38:02 [Zakim]
- Ian, you wanted to talk about proposal next steps
- 15:38:11 [Ian]
- PROPOSED: Resolve issue 19 with HTTP Link Headers
- 15:38:53 [AdrianHB]
- q+ to ask what PMI points to then?
- 15:39:05 [Ian]
- IJ: This approach suggests a link type registration
- 15:39:25 [Ian]
- zkoch: I'd like to test this approach and come back to the group
- 15:39:41 [Ian]
- ack adrianhb
- 15:39:41 [Zakim]
- AdrianHB, you wanted to ask what PMI points to then?
- 15:40:01 [Ian]
- adrianHB: What does the PMI point to?
- 15:40:02 [Ian]
- https://w3c.github.io/webpayments-method-identifiers/
- 15:40:43 [Ian]
- zkoch: My understanding is this is the desired behavior:
- 15:40:59 [Ian]
- 1) Given a PMI, user gets human readable documentation
- 15:41:22 [Ian]
- 2) Given a PMI, the user agent can GET on this URL and get a response header that points to the JSOn
- 15:41:38 [Ian]
- 3) The response header uses an IANA registered relationship
- 15:42:13 [adamR]
- q+
- 15:42:20 [Ian]
- adrianHB: I think we could support both options - PMI gives back JSON and from there the browser can find human-readable
- 15:42:53 [Ian]
- ..rouslan's point is interesting about hosting these files on other sites, like github
- 15:43:20 [Ian]
- q+
- 15:43:22 [zkoch]
- This makes me think #1 is the correct route :)
- 15:43:22 [Ian]
- ack adam
- 15:43:50 [Ian]
- adamR: Link headers are defined to have semantic equivalents to link elements in an HTML document. in all likelihood we already have that in browsers...
- 15:44:07 [Ian]
- ...we probably could specify this such that link headers in an HTMl document can be used when HTTP headers are not available
- 15:44:19 [Ian]
- ...but this is more costly because you have to GET a full document
- 15:44:27 [Ian]
- s/GET on this URL/HEAD on this URL/
- 15:44:36 [rouslan]
- q+
- 15:44:40 [Ian]
- ack me
- 15:45:46 [Ian]
- adrianHB: If we want to accommodate people who can't easily do server-side configs, then we should define what the default form is what they host at that URL
- 15:45:53 [adrianba]
- q+
- 15:46:02 [Ian]
- ...so I am hearing the default is "HTML" with a Link element...but that can be inefficient
- 15:46:06 [zkoch]
- But if we accept that as true, then why not do #1? This was my complaint from the beginning.
- 15:46:20 [Ian]
- ...the alternative is to favor the JSON and find documentation from there
- 15:46:53 [Ian]
- ack rous
- 15:47:16 [Ian]
- rouslan: the point from AdamR is that if we define two ways to access this, then there will be interop problems
- 15:47:25 [Ian]
- ...why don't we define an algorithm?
- 15:47:35 [adamR]
- q+
- 15:47:47 [adrianba]
- q- later
- 15:47:58 [Ian]
- ..that will increase browser dev cost, but it will meet adrianHB need (e.g., allow files on github more easily)
- 15:48:25 [Ian]
- ...so I'd like to propose the algorithm approach of HTTP Link header first, then if not there, look for link relationship second after GET of HTML
- 15:48:29 [Ian]
- AdamR: I'm ok with that
- 15:48:39 [Ian]
- ..I think a lot of machinery for that exists
- 15:48:43 [Ian]
- q?
- 15:48:48 [Ian]
- ack ad
- 15:48:53 [Ian]
- ack adrianba
- 15:48:57 [AdrianHB]
- +1 to rouslan (also doubt we'll actually have many PMI inventors with minimal technical capability)
- 15:49:08 [Ian]
- adrianba: I am fine with any of the choices except for option 4
- 15:49:27 [Ian]
- ...at the risk of prolonging the discussion, I don't think we should optimize for people creating payment method identifiers
- 15:49:40 [Ian]
- ...in the end we will have relatively few of those compared to the number of developers using those URLs to make payment requests
- 15:50:36 [Ian]
- Straw pool:
- 15:50:44 [AdrianHB]
- +1 to adrianba (but we should be explicit about that design decision and priority of constituents)
- 15:50:51 [Ian]
- Option 1) HTTP Link header
- 15:51:04 [Ian]
- Option 2) HTTP Link header, otherwise look in HTML for Link element
- 15:51:12 [adamR]
- Option 1
- 15:51:16 [adrianba]
- 1
- 15:51:17 [stan]
- 1
- 15:51:25 [pascal_bazin]
- 1
- 15:51:30 [zkoch]
- Umm… which is the one I’ve been saying?
- 15:51:31 [AdrianHB]
- 1 (but still prefer content neg) :)
- 15:51:31 [zkoch]
- :)
- 15:51:33 [oyiptong]
- 1
- 15:51:46 [zkoch]
- Great, 1?
- 15:51:51 [zkoch]
- _1
- 15:51:56 [rouslan]
- since, adrianba is 1, i am 1 too
- 15:52:13 [rouslan]
- s/adrianba/adrianhb/
- 15:52:33 [zkoch]
- sgtm
- 15:52:35 [rouslan]
- +1
- 15:52:51 [rouslan]
- q+
- 15:53:00 [adamR]
- ack adamR
- 15:53:02 [Ian]
- ACTION: zkoch to experiment with HTTP link header as a means of addressing issue 19
- 15:53:03 [trackbot]
- Created ACTION-43 - Experiment with http link header as a means of addressing issue 19 [on Zach Koch - due 2017-01-12].
- 15:53:23 [Ian]
- alan: We will do the same
- 15:53:29 [Ian]
- ACTION: Alan to experiment with HTTP link header as a means of addressing issue 19
- 15:53:30 [trackbot]
- Created ACTION-44 - Experiment with http link header as a means of addressing issue 19 [on Alan Marshall - due 2017-01-12].
- 15:54:00 [Ian]
- IJ: When should we bug you about your findings?
- 15:54:02 [zkoch]
- ::looks at Rouslan::
- 15:54:10 [zkoch]
- 2-3 weeks sgtm
- 15:54:19 [Ian]
- rouslan: +1 to 2-3 weeks
- 15:54:28 [rouslan]
- web-payments-manifest
- 15:54:32 [rouslan]
- payment
- 15:54:34 [rouslan]
- pay
- 15:54:41 [Ian]
- payment-method-manifest
- 15:54:52 [AdrianHB]
- application/json+payment-method-manifest
- 15:55:12 [rouslan]
- q+
- 15:55:19 [Ian]
- ack rous
- 15:55:39 [AdrianHB]
- sorry, that is a mime-type :)
- 15:55:45 [adamR]
- BTW, existing relations are listed here: http://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1
- 15:56:12 [adamR]
- “payment-method-manifest” would be, by far, the longest name in that table. :)
- 15:56:26 [Ian]
- rouslan: Another place to experiment is to determine how well http link headers are deployed
- 15:56:32 [AdrianHB]
- +1 payment-method-manifest
- 15:57:18 [Ian]
- ACTION: Ian to investigate HTTP Link header deployment status
- 15:57:18 [trackbot]
- 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
- 15:57:23 [adamR]
- Ian: I think the number of registered relations speaks to how well deployed this is.
- 15:57:34 [AdrianHB]
- +1 adamr
- 15:58:16 [Ian]
- Ian: We will return in 3 weeks to this question.
- 15:58:35 [Ian]
- topic: Basic Card
- 15:58:44 [Ian]
- https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md
- 15:59:07 [AdrianHB]
- Web Linking (RFC 5988) is referenced by LOTS of other specs which suggests it is stable and widely used: https://datatracker.ietf.org/doc/rfc5988/referencedby/
- 16:00:26 [zkoch]
- +1, let’s do it
- 16:00:40 [adamR]
- SGTM
- 16:00:43 [Ian]
- PROPOSED - adopt this proposal => https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md
- 16:00:44 [zkoch]
- The strings are already being used in the wild, sooo *shrug*
- 16:00:45 [adrianba]
- +1
- 16:00:48 [AdrianHB]
- +1
- 16:01:00 [rouslan]
- yep
- 16:01:12 [rouslan]
- we also have "mir"
- 16:01:18 [AdrianHB]
- (but would like to hear from card acquirers...)
- 16:01:45 [Ian]
- [Added "mir"]
- 16:02:11 [zkoch]
- Have to go to next meeting. See ya!
- 16:02:18 [zkoch]
- ahhh
- 16:02:39 [Ian]
- Ian: Would like to get trademark input before we finally adopt
- 16:02:50 [Ian]
- RESOLVED: Adopt the network list proposal (pending trademark input)
- 16:03:11 [AdrianHB]
- p.s. Open source card data: https://github.com/binlist/
- 16:03:32 [Ian]
- Topic: FTF
- 16:03:34 [Ian]
- register!
- 16:03:37 [Ian]
- https://www.w3.org/2002/09/wbs/83744/wpwg-201703/
- 16:03:51 [Ian]
- https://www.w3.org/2002/09/wbs/83744/wpwg-201703/results
- 16:04:11 [Ian]
- Also the WPIG is likely to meet on 22 March
- 16:04:17 [Ian]
- (expect formal decision next week)
- 16:04:24 [Ian]
- Topic: Next meeting
- 16:04:35 [AdrianHB]
- 12 Jan
- 16:04:35 [Ian]
- 12 Jan
- 16:04:38 [Ian]
- rrsagent, make minutes
- 16:04:38 [RRSAgent]
- I have made the request to generate http://www.w3.org/2017/01/05-wpwg-minutes.html Ian
- 16:04:41 [Ian]
- rrsagent, set logs public
- 17:05:23 [stan]
- stan has joined #wpwg
- 17:57:41 [stan]
- stan has joined #wpwg
- 18:22:08 [Zakim]
- Zakim has left #wpwg
- 19:43:44 [Adam__]
- Adam__ has joined #wpwg