Web Payments Working Group Teleconference

12 May 2016


See also: IRC log


jnormore, zkoch, AdamR, nicktr, rouslan, Ian, dlongley, Marta, Adrian Bateman (partial),


<scribe> scribe: Ian

FTF meeting


AHB: Please register -> https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/
... thanks to Brian and Visa Europe for hosting us
... London, 7-8 July
... near Paddington Station
... chairs will start building agenda once we've addressed pressing issues on the issues list

Marta: If I have to choose between IG and WG, which should I do?

IJ: seem like if you want to go to the workshop, pick the IG meeting
... and if you want to focus on payment apps and payment request API, pick the WG

adrianHB: The IG will focus on "up and coming" whereas the WG will focus on specific deliverables

[Regarding hotels, see the meeting page and also Visa special rates]

to tpac?

TPAC 2016


Lisbon, Portugal19-23 September 2016

WG meets 19-20 Sept


[Please register for TPAC!]

dezell: adrianHB, however you want to schedule ILP at TPAC is fine by me

adrianhb: We'll pick up offline

Payment Method Identifiers

adrianhb: There's a pull request from Ade that is significant in terms of text change (narrowing doc to URLs)..but doesn't fundamentally change functionality


scribe: the PR requests the group consensus from last week to use Absolute URLs for PMIs
... any questions?

dlongley: My only comment was that there was more specific text for options to resolve PMIs
... there is still an issue marker in the text
... I'd like to see the section that was in there still in there.


<zkoch> +1 to deletion and keeping issue marker

IJ: I think the issue marker does the job

<zkoch> That seems fine to me

dlongley: Let's put the text in the issue marker...then I'm ok with moving it

if zach and dave happy, I'm happy

<AdrianHB> PROPOSAL: Accept PR 183 and move requirements bullets into issue marker


<AdrianHB> +1

<zkoch> +1

<dlongley> +1

<jnormore> +1


RESOLUTION: Accept PR 183 and move requirements bullets into issue marker

AdrianHB: We did not get consensus on 10 and 11 last week.
... there are elements of PMIs that we need to address.
... right now there are no concrete proposals to address them.
... there has been discussion (e.g., MattS+Ian, then MattS+Ian+AHB)

<adrianba> I believe using URLs addresses issue #11

AdrianHB: there are some ideas floating around, but not on the list yet

+1 that using URLs addresses 11

PROPOSED: Close 11 since we are using URLs

adrianba: Now that we are using URLs we get distributed extensibility
... we can deal with optimizations (short strings) as a separate issue

<zkoch> +1 to closing #11

adrianHB: I agree we can close 11 but there are still issues around dereferencing URLs
... I don't want to make an assertion around priorities

+1 to closing 11

<AdrianHB> +1 to closing #11

adrianba: I think dereference topic is something we should talk about (but separately)

<dlongley> +1 to close #11, we have #46 to talk about resolving URLs

AdrianHB: Any objections?


<scribe> (Done)

adrianHB: So this is an appeal to the group to look at the PMI spec after 183 merger and outstanding issues and fashion some proposals.

zkoch: I do think we have a number of proposals on the table....I think we don't have consensus yet.
... e.g., short strings, etc.
... all of these proposals have pros and cons
... I'm skeptical that there's a magical solution that will address all concerns
... so at some point I think we will just need a decision on a starting point.

AdrianHB: I am referring to pull requests.

zkoch: My point is not that we are missing concrete text, but rather we just don't have consensus yet.

AdrianHB: So the priority questions are:

* Short identifiers (and how would they work)?

* Grouping and subclassing?

* Dereferencing?

<zkoch> Clarification: They don’t necessarily have to be “short”. They just have to be standardized.

<AdrianHB> Grouping: https://github.com/w3c/browser-payment-api/issues/30

IJ: I believe that there is consensus that we do not require dereferencing. Therefore, that topic should be lower priority for now.

<Zakim> dlongley, you wanted to note that we had spec text in the options for how to do short identifiers

dlongley: We have seen spec text (in issues)
... just not as PR requests

What data should be sent to the payment app?

adrianhb: When a browser gets data, should it do anything before handing to the payment app?
... or just pass it on?
... Relates to some other issues

IJ: Topics:

* Shape of APIs

* What data is passed?

* What mechanisms used to pass it?

<zkoch> +1 to Ian

IJ: I think the priority issue is "what data does a payment app need"?
... then we figure out how.

dlongley: I agree with Ian's approach, but also important to try to make sure that we don't over specify any particular role
... it's really easy to overspeicfy the payment mediator role.

Proposal for what goes to the payment app:

* The PMIs supported by the payment app

* The transaction data

* Any payment method specific data

<adamR> +1

<Zakim> Ian, you wanted to make a concrete proposal!

IJ: I suggest we move that topic to the payment app spec.

adrianHB: The crux of issue 157 is, when you make a payment request from the merchant site, you provide PMIs and PM-specific data...when the browser passes it on, Ian is proposing handing off only the relevant PMI info
... Question is sharing too much info from payment app, v. verbosity, and related is signing payment info

dlongley: Some of this relates to the core messages spec.
... which specifies what does to the payment app
... the idea is to have some core message base independent of payment method
... regarding digital signature from the merchant....that's very important for push-type payments
... app needs to know that nothing was interfered with

<Zakim> dlongley, you wanted to talk about core messages relation to this

dlongley: my opinion is that we should not have the payment mediator filter the data
... I think there's a relationship between merchant and payment app

(IJ does not think, in general, there is relationship between merchant and payment app)

adamR: If all we do is throw data back and forth, we create potential of super cookie. I think that the mediator will need to play a role of policing that. So I think there will be some modification.

<zkoch> +1 to adamR

+1 to adamR

dlongley: As soon as we police data, we put constraints on extensibility.
... if the payment mediator decides what the app gets, we will have limitations to innovation.

nicktr: Feel free to spec out that proposal.


IJ: My point is that this issue is not about paymentRequest API
... it's about payment app spec.

adrianHB: I think people now understand the discussion points, and I think we should move discussion to the wiki or mailign list

User data

adrianHB: PR 174 was merged after discussion between MattS and editors
... I think MattS may log some issues separately
... looking for PRs
... Crux of concern is this: browser gets some user data that merchant (at different domain potentially than payment app) can view before completion

IJ: Seems like a same-origin issue.
... is the characterization that you are providing information to B and it gets to A?

AdamR: I don't think that's the issue, it's that data is available to the Web site even though it was sent without my knowledge.

<dlongley> the two scenarios: you enter information into merchant.com vs. you enter information into a special browser UI (and not merchant.com branded) and that information is sent to merchant.com whenever you make a selection even if you don't accept the payment, etc.

adrianHB: I think Adam has characterized it correctly ... I want to reemphasize what I said - when you call show() what is not the payment app but rather privileged browser UX. In that privileged browser UX that data is being captured...any time data is captured there, the site can tell
... this does not have to do with payment app yet

zkoch: I agree with Adam we need to be careful. This is browser UI at the end of the day.
... chrome tries to do things to show what is browser UI but it's not obvious that users know that
... I agree we need to figure out the consent issue...and need to leave the mediator the role of addressing it.
... there are subtle things going on...good that ew are having the conversation...but at the end of the day, I think it's the responsibility of the mediator to say what consent is.

<dlongley> seems like we could do the same thing with shipping address and provide a <shipping-address> component (or similar) as an alternative mechanism for collecting that info on the merchant site

IJ: Would "mediator needs to get user consent" be a requirement?

adamr: Perhaps not a requirement, but for example, some privacy preserving proof of concept as an example.
... but allow mediators to do things differently as well

<zkoch> adamR, is one of the PRs you mentioned taking a stab at this? I would be supportive of that language

<adamR> zkoch: It wasn’t, but I can give it a go. :)

API design issues

Issue 16 - Use navigator.payments singleton, factory method, or PaymentRequest constructor.

AdrianHB: This seems mostly like a question of taste.

Here's a concrete proposal from Manu:


scribe: goal is to leave room for new API calls

<adamR> zkoch: I think the big issue is that there are basically two ways to solve this; one is with the current API and carefully crafted UX. The other is by doing data collection in one phase, and payment submission in another. I think the second is safer, but likely more controversial.

<dlongley> +1 to the proposal.

adrianhB: This issue is like bikeshedding
... anyone opposed to using something akin to a factory method?

zkoch: I don't necessarily have a strong objection. It might be unnecessary (+0)
... before we decide this, I'd rather get some sense from Ade who had to leave the call

adrianHB: Let's postpone that one to when Ade is here

Issue 122 - Format of complete()


<zkoch> +1

IJ: +1 to approach of treating unrecognized as "empty string"

<adamR> +0

<dlongley> +1 to the PR, but I think using the "empty string" is weird.

[No objections]


Issue 2

Payment Request API only available in a top-level browsing context?

adrianHB: So, if an iframe attempts to call the API it won't work.
... but we know that merchants use an iframe that pulls content from a PSP
... we can imagine a PSP having the code to call the API
... we'd like to hear from PSPs on this topic
... how would you want this to be handled?

<dlongley> +1 to giving permission from the parent.

zkoch: I am now coming down on the side of allowing non-top-level (aka iframe) as long as we can find a way to give permission (parent to iframe) via the sandbox attribute
... I there may be some UX challenges, but can write up a proposal.

nicktr: I recognize the use case that adrianHB described. I recognize that iframes have issues as well.
... I would like to talk to my Worldpay colleagues to understand consequences of such an approach

adamR: I need, also, to consult with my security colleagues (e.g., about sandbox)

+1 to researching that!

adrianHB: I am hearing "top level unless parent has given consent"

(e.g., through sandbox approach)

<zkoch> sandbox=“allow-payment”. We would need an extension spec, too, probably

<Zakim> dlongley, you wanted to say it may also depend on the payment request itself in some way

dlongley: Another use case (future) is calling API outside of parent site (e.g., IOT)

nicktr: Thanks everyone, there was a lot on the agenda!

<zkoch> I’ll see you guys in June!

<zkoch> Thanks!

Next meeting

19 May

Summary of Action Items

Summary of Resolutions

  1. Accept PR 183 and move requirements bullets into issue marker
  2. Accept PR 191
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/12 17:06:04 $