See also: IRC log
Upcoming discussion on merchant adoption.
Proposed time /date is 20 January at noon ET
IJ: I called for review by W3C Chairs of PR API suite as part of preparing for CR.
IJ: Any experimentations that should be reflected in this spec?
zkoch: As we've explored
third-party apps we've expanded a bit to solve various use
cases like certificate change
... but these would fall under the "Android" heading of a
payment method manifest file
... I think the biggest open question is probably the
addressing question
... how do you get the manifest file given the payment method
identifier?
This is issue 19
rouslan: the manifest file spec
shape comes from Google/Alipay discussions
... the Web section aligns with the payment app api spec
... in the payment app api spec we talk about manifest format
(not files)
so the manifest file format has web and extension points
scribe: and the manifest format also allows some scoping of which payment apps may be used to implement a payment method
IJ: Need to address big issues like security here
rouslan: Definitely issues about
security and who can do what needs to be spelled out
... 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
(Issue 19)
rouslan: If you have a payment method manifest file, that file describes how to get the payment app
zkoch: Ian is right - there is clearly a lot to be written...
adamR: I do think that writing
down the issues in the doc is a good idea
... I have a strong opinion about defaults
https://github.com/w3c/webpayments-method-identifiers/issues/19
adamR: -1 to "more than one way
to do this"
... you end up with non-overlapping choices by implementers
zkoch: I think realistically the
two ideas with the most traction are HTTP link headers and
known string (options 1 or 2)
... 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.
rouslan: HTTP Link headers...is that what goes into Web page?
<adrianba> https://www.w3.org/wiki/LinkHeader
rouslan: If server-level config,
this means that we'd not be able to handle payment methods on
github, for example
... what is level of support for HTTP Link headers?
<zkoch> This is just HTTP I think
<Zakim> AdrianHB, you wanted to ask which format is mandatory
adrianhb: If we have dev documentation and also machine readable.
<adamR> Not worth taking time on the queue, but Firefox most certainly implements Link: headers
adrianhb: it feels to me that the
human-readable info is OPTIONAL and the machine-readable thing
is MANDATORY
... and so perhaps we should favor the payment method
identifier pointing to the machine-readable information
... and the JSON points to documentation
... that feels to me like the right priority
zkoch: I agree with the prioritization (machine-readable is most important). It seems to me ok to pursue both worlds.
rouslan: One thing to keep in
mind - android pay has a bunch of documentation
... serving JSON from that space is probably not feasible
... and asking merchants to switch URLs would be a burden
<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.
<zkoch> -1 on 4 :)
IJ: Option 4 favors the data and is basically "2" but inverted
zkoch: I think it's easier for
people to find human-readable documentation when they are
hunting around
... so I would put that first.
... it's not really that hard to do both worlds (e.g., via HTTP
Link Headers)
... Known assets works
[Review of link headers]
<adamR> BTW, http://www.rfc-editor.org/rfc/rfc5988.txt
adamR: .well-known is for constrained situations (that we are not in)
<Zakim> Ian, you wanted to talk about proposal next steps
PROPOSED: Resolve issue 19 with HTTP Link Headers
IJ: This approach suggests a link type registration
zkoch: I'd like to test this approach and come back to the group
<Zakim> AdrianHB, you wanted to ask what PMI points to then?
adrianHB: What does the PMI point to?
https://w3c.github.io/webpayments-method-identifiers/
zkoch: My understanding is this is the desired behavior:
1) Given a PMI, user gets human readable documentation
2) Given a PMI, the user agent can HEAD on this URL and get a response header that points to the JSOn
3) The response header uses an IANA registered relationship
adrianHB: I think we could
support both options - PMI gives back JSON and from there the
browser can find human-readable
... rouslan's point is interesting about hosting these files on
other sites, like github
<zkoch> This makes me think #1 is the correct route :)
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...
... we probably could specify this such that link headers in an
HTMl document can be used when HTTP headers are not
available
... but this is more costly because you have to GET a full
document
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
... so I am hearing the default is "HTML" with a Link
element...but that can be inefficient
<zkoch> But if we accept that as true, then why not do #1? This was my complaint from the beginning.
adrianHB: the alternative is to favor the JSON and find documentation from there
rouslan: the point from AdamR is
that if we define two ways to access this, then there will be
interop problems
... why don't we define an algorithm?
... that will increase browser dev cost, but it will meet
adrianHB need (e.g., allow files on github more easily)
... 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
AdamR: I'm ok with that
... I think a lot of machinery for that exists
<AdrianHB> +1 to rouslan (also doubt we'll actually have many PMI inventors with minimal technical capability)
adrianba: I am fine with any of
the choices except for option 4
... at the risk of prolonging the discussion, I don't think we
should optimize for people creating payment method
identifiers
... in the end we will have relatively few of those compared to
the number of developers using those URLs to make payment
requests
Straw pool:
<AdrianHB> +1 to adrianba (but we should be explicit about that design decision and priority of constituents)
Option 1) HTTP Link header
Option 2) HTTP Link header, otherwise look in HTML for Link element
<adamR> Option 1
<adrianba> 1
<stan> 1
<pascal_bazin> 1
<zkoch> Umm… which is the one I’ve been saying?
<AdrianHB> 1 (but still prefer content neg) :)
<zkoch> :)
<oyiptong> 1
<zkoch> Great, 1?
<zkoch> _1
<rouslan> since, adrianhb is 1, i am 1 too
<zkoch> sgtm
<rouslan> +1
<scribe> ACTION: zkoch to experiment with HTTP link header as a means of addressing issue 19 [recorded in http://www.w3.org/2017/01/05-wpwg-minutes.html#action01]
<trackbot> Created ACTION-43 - Experiment with http link header as a means of addressing issue 19 [on Zach Koch - due 2017-01-12].
alan: We will do the same
<scribe> ACTION: Alan to experiment with HTTP link header as a means of addressing issue 19 [recorded in http://www.w3.org/2017/01/05-wpwg-minutes.html#action02]
<trackbot> Created ACTION-44 - Experiment with http link header as a means of addressing issue 19 [on Alan Marshall - due 2017-01-12].
IJ: When should we bug you about your findings?
<zkoch> ::looks at Rouslan::
<zkoch> 2-3 weeks sgtm
rouslan: +1 to 2-3 weeks
<rouslan> web-payments-manifest
<rouslan> payment
<rouslan> pay
payment-method-manifest
<AdrianHB> application/json+payment-method-manifest
<AdrianHB> sorry, that is a mime-type :)
<adamR> BTW, existing relations are listed here: http://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1
<adamR> “payment-method-manifest” would be, by far, the longest name in that table. :)
rouslan: Another place to experiment is to determine how well http link headers are deployed
<AdrianHB> +1 payment-method-manifest
<scribe> ACTION: Ian to investigate HTTP Link header deployment status [recorded in http://www.w3.org/2017/01/05-wpwg-minutes.html#action03]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
<adamR> Ian: I think the number of registered relations speaks to how well deployed this is.
<AdrianHB> +1 adamr
Ian: We will return in 3 weeks to this question.
https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md
<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/
<zkoch> +1, let’s do it
<adamR> SGTM
PROPOSED - adopt this proposal => https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md
<zkoch> The strings are already being used in the wild, sooo *shrug*
<adrianba> +1
<AdrianHB> +1
<rouslan> yep
<rouslan> we also have "mir"
<AdrianHB> (but would like to hear from card acquirers...)
[Added "mir"]
<zkoch> Have to go to next meeting. See ya!
<zkoch> ahhh
Ian: Would like to get trademark input before we finally adopt
RESOLUTION: Adopt the network list proposal (pending trademark input)
<AdrianHB> p.s. Open source card data: https://github.com/binlist/
register!
Also the WPIG is likely to meet on 22 March; expect a decisio on that soon, e.g., next week.
<AdrianHB> 12 Jan