W3C

Web Payments Working Group Teleconference

05 Jan 2017

Agenda

See also: IRC log

Attendees

Present
scribe, Olivier, Pascal, adamR, Rouslan, AdrianHB, Alan, Stan, zkoch
Regrets
Nick
Chair
Ian
Scribe
Ian

Contents


Deployment

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.

Manifest Specification

Payment Method Manifest draft

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.

Basic Card

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/

FTF Meeting

register!

(Registration form)

(Who has registered)

Also the WPIG is likely to meet on 22 March; expect a decisio on that soon, e.g., next week.

Next meeting

<AdrianHB> 12 Jan

Summary of Action Items

[NEW] 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]
[NEW] ACTION: Ian to investigate HTTP Link header deployment status [recorded in http://www.w3.org/2017/01/05-wpwg-minutes.html#action03]
[NEW] 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]
 

Summary of Resolutions

  1. Adopt the network list proposal (pending trademark input)
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/01/05 16:41:06 $