See also: IRC log
<scribe> scribe: Ian
https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29
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?
https://www.w3.org/2016/09/TPAC/
Lisbon, Portugal19-23 September 2016
WG meets 19-20 Sept
https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login
[Please register for TPAC!]
dezell: adrianHB, however you want to schedule ILP at TPAC is fine by me
adrianhb: We'll pick up offline
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
https://github.com/w3c/browser-payment-api/pull/183
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.
https://github.com/w3c/webpayments/wiki/PMI_Notes
<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
+1
<AdrianHB> +1
<zkoch> +1
<dlongley> +1
<jnormore> +1
SO RESOLVED
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?
[None]
<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
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.
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes
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
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. :)
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:
https://github.com/w3c/browser-payment-api/issues/16#issuecomment-217269345
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
https://github.com/w3c/browser-payment-api/pull/191
<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]
RESOLUTION: Accept PR 191
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!
19 May