Web Payments Working Group

<scribe> Scribe: Ian

Status of publication of CRs

Status of publication of CRs

IJ: Editor update?

zkoch: We met yesterday and discussed all the open issues that we think are blocking for CR (3-4)
... we saw resolution on the issue of payment handler data

https://github.com/w3c/payment-request/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20-label%3A%22Priority%3A%20Postponed%22%20-label%3A%22Editorial%22%20-label%3A%22Process%20aid%22%20

zkoch: I think there is one PR pending
... and one more to submit, then we should be good
... so by end of next week we should be ready to do the transition request

Draft transition request => https://www.w3.org/2017/07/13-prapi-cr-trans-req.txt

Basic Card status

zkoch: Marcos re-raised.

ian: We have resolved 2 times
... let us take to email

IJ: Anything else about CR transition?

(Silence)

Status of Payment Method Manifest FPWD

<AdrianHB> ian: Did a review of manifest spec in prep for FPWD

https://github.com/w3c/payment-method-manifest/issues/11

<AdrianHB> ... main thing I noticed related to security

<AdrianHB> ... should spec say more about handling absence of manifest

<AdrianHB> ... want to focus on which spec needs to say what in order to acheive desired security properties

<AdrianHB> ... specifically where do we define default behaviour for no-manifest

<AdrianHB> ... rouslan has added considerations for this in handler spec but this is maybe not the right place for it (should be browser level)

<AdrianHB> ... want to cover this before FPWD

<AdrianHB> ... resolve or put issue markers

zkoch: I agree that the question of default for origin is one we need to answer.
... a simpler question is: is a manifest required for any URL PMI?
... I don't think it's just a security question
... should the ability to "stand by itself" be available as easily to parties who publish URL PMIs.

<AdrianHB> ian: my take is, what are the things I want to say and how do I say them. The manifest is one way to say them

<AdrianHB> ... you could say things in the PMI for example

<AdrianHB> ... it could be that one answers the question of origin control in two ways but we may want to only use one which then makes manifest mandatory

<AdrianHB> ... I acknowledge it could be about other things (not just security)

<AdrianHB> zkoch: I acknowledge that there may be use cases where manifests are not required (open payment methods) but I want to focus on current reality which is a number of origin-owners that want to use the manifest

<AdrianHB> ... I am inclined to say manifest should be required

1) Same origin policy for the web applies to payment systems

(IJ: let's use PR api to say that)

<AdrianHB> I worry that we are conflating the use of the URL as an identifier with it's use as an origin

2) There are multiple ways to declare other origins

a) PMM

b) W3C publishes a payment method spec

3) In the world of PMM's, we need to talk about error handling to fall back to same origin policly

4) If you want to make PMM's mandatory, do you say something in PMI?

scribe: but would want to allow multiple formats

<Zakim> AdrianHB, you wanted to ask about how to handle failure to fetch

adrianhb: Assuming we did want to make PMM's mandatory, then I think the statement about what to do without manifests should be in the PMM spec, and there should be a default behavior in that spec.

(e.g., what the default PMM is in the absence of one or failure to load)

scribe: what worries me as a payment method publisher
... knock on implications of failure seem heavy

zkoch: The idea of a default manifest or some fallback in case of failure seems worth exploring
... to the question of the upkeep of the manifest: deciding to engage in this ecosystem is a business decision
... just like offering code to put into a site
... these all come with burden of maintenance
... there is burden in all code; this is no different

AdrianHB: The challenge for me is the complexity of monitoring this
... I don't know if my page is being returned to browsers
... it's quite a burdensome thing to monitor from that perspective.
... I appreciate the point that this is a burden like others

<zkoch> I find that a very confusing statement :)

<AdrianHB> ian: the idea of a spec saying what to do when that spec is not implemented seems confusing

<AdrianHB> ... it's also possible there may be other formats

<AdrianHB> ... the "matching" process can be pulled out of the manifest spec

<Zakim> Ian, you wanted to ask about other PMM formats and why "absence" should be handled outside of it

<AdrianHB> ... there is a global statement about SOP that should be in PR spec

<AdrianHB> ... does it make sense for webappmanifest to also have payment related information

IJ: I was wondering if we could squat on PMI namespace to say something like www.bank.com/no-manifest

And that means "Open"

And user agents know not to go fetch the manifest

AHB: What are arguments against same origin statement in PR API?

IJ: "Don't touch the spec"

AHB: What is implemented?

https://w3c.github.io/payment-request/#security-considerations

<AdrianHB> Let's look at 12.5 in https://w3c.github.io/payment-request/#show()-method

IJ: We could say something in the security considerations.

<AdrianHB> ... the start of this was the motivation be able to delegate auth to serve their payment method from other apps

<AdrianHB> ... at a high level we need to say somewhere "don't serve apps from other origins unless you have information that says you can"

<AdrianHB> ... we should have some guidance (possibly non-normative) to say that

AdrianHB: On the question of security - not PMI, which has shrunk to simple definitions

IJ: I will do a pull request on PR API for discussion.

next meeting

24 Aug

AdrianHB: I am at risk for 24 Aug