See also: IRC log
<AdrianHB> /me is running 2 mins late
<adamR> https://github.com/w3c/webpayments-method-identifiers/issues/11
---> https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0082.html
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md
IJ: Quick overview and where we are?
AdamR: This proposes something
that looks like a service worker (and is modeled after what is
done in WebRTC).
... process is spun up after selection by the user
... we have one message in one direction, and one message in
the other
... the application has opportunity to do what it wants with a
message (within its origin)...including the opportunity to open
a window for the user
... (two: one allows for a URL instead of a body)
... "data" is internal detail to the app (allows window to
communicate with worker)
... when everything is done, the application sends a message
back which the browser turns into a promise resolution
IJ: Feedback so far?
<alyver> I will need a bit more time to review the proposal.
AdamR: Tommy sent feedback and that's been incorporated
IJ: Proposed 2 reviewers then try
to integrate into the spec
... How would text need to change before going into doc?
AdamR: Will need expansion
<Zakim> AdrianHB, you wanted to ask if there has been feedback from other implementors?
<AdrianHB> Issue with audio
<AdrianHB> Will try call in again
IJ: (Has there been feedback from other implementors?)
AdrianHB: Aside from Tommy; no. What is spec'd here is similar to Tommy's polypill
<Max> +1
IJ: Volunteers to review?
Volunteers: AdrianHB, Max
AdrianHB: This proposal has
triggered some good discussion on the issues list.
... it would be valuable to get MS and Google input on payment
apps since it's increasingly becoming clear that we may have to
make decisions that impact both.
<scribe> ACTION: Max to review the registration proposal, due 24 August [recorded in http://www.w3.org/2016/08/17-apps-minutes.html#action01]
<scribe> ACTION: AdrianHB to review the registration proposal, due 24 August [recorded in http://www.w3.org/2016/08/17-apps-minutes.html#action02]
<Roy> I can take a look, but this is the first I heard of Adam's proposal, maybe someone can shoot me a pointer
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md
IJ: Anything else today?
AdamR: Feedback!
https://github.com/w3c/webpayments-payment-apps-api/issues/27
IJ: Would that be useful?
... what's the design consideration?
... What do we need to do to modify the spec?
AdamR: I don't necessarily object
up front but it does raise a privacy issue. Would it have
"surprising" properties for users? My first inclination is
"probably not"
... adding a field for all methods that has origin information
might make sense
... but it might also be payment-method specific and should
figure into the payment method spec.
... e.g., for basic not useful; for tokenized useful
... so figures into payment method good practice
(PAYMENT METHOD GOOD PRACTICE NOTE :)
scribe: I wish we had more payment method specs in development to determine
IJ: We have been talking about getting an EMV tokenization spec
Roy: Facebook is looking at a payment method specification involving tokenization
<jnormore> Yes EMV is network tokenization
(Discussion of gateway v. network tokens)
IJ: How do you deal with the privacy issue in the case where it's useful (e.g., payment method includes tokenization)
AdamR: I would like to run the question by the Privacy Interest Group
IJ: In today's payment methods, is origin information available to e.g., card networks?
AdrianHB: Concern is payment app distributor (who is not also the issuer)
jnormore: We have multiple payment gateways and multiple payment methods available, and even the concept of payment apps....we only pass information required to process the payment itself. In some cases we don't pass line item or customer information ... only when necessary to process the payment.
q
jnormore: Isn't it up to the merchant what they want to pass through?
Ian: The user might also care ("I don't want others knowing what ecommerce sites I'm visiting")
Ij: Any volunteers to write up something?
(No)
IJ: I will record in the issue the points on (1) privacy and (2) may depend on payment method
<scribe> ACTION: Ian to put notes on privacy and payment method potential dependency about origin info into the issues list [recorded in http://www.w3.org/2016/08/17-apps-minutes.html#action03]
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions
IJ: Adrian, status of your action?
AdrianHB: Not done.
<Max> +1
Max: I have read the table and
have some thoughts.
... one question has to do with whether explicit user consent
is required for registration
IJ: What is the scenario?
Max: E.g., site automatically registers payment app when user visits site
AdamR: I think we should provide some guidance here but don't think we should provide anything normative here. Different browsers will have different notions of user protection, and they can validly differentiate themselves.
Max: Ok
... from user experience, most users will be confused about
information
... From user experience we could "allow" the browser to
automatically register the payment app
... I am ok to provide guidance and leave to browser
implementation
https://w3c.github.io/webpayments-payment-apps-api/
https://w3c.github.io/webpayments-payment-apps-api/#registration-and-unregistration
"We expect registrations to happen at various times (e.g., outside and inside of checkout), and with differing levels of user consent to modify their configuration within the user agent. "
"Users visiting a Web site (e.g., merchant or bank) may wish to explicitly register payment apps, which would require explicit consent from the user."
We could add:
"User agents may distinguish themselves by the extent to which they enable users to automatically register payment apps without additional user interaction."
AdamR: That text seems unnecessary; what is under the bullet looks ok to me today
IJ: I think this is too strong: "which would require explicit consent from the user."
<AdrianHB> +1 on requiring consent
AdamR: I think in that scenario
(visiting a site) consent is the right thing.
... but I think that during checkout (first sub-bullet) is ok
... I want to avoid language that says "must happen without
user consent"
AdrianHB: I think we need to be more explicit in cases where things are happening on the web; less we say outside the web context the better
<AdrianHB> Note: https://github.com/w3c/webpayments-method-identifiers/issues/11
AdamR: I am concerned about malware scenario...don't want implicit registratino
Max: The reason why we should
allow browser to register payment apps automatically is because
most users will not quite understand the technical
details
... we want to improve the user experience
[Move to point 2]
Max: We have discussed a bit ... how do we ensure that a payment app is who it claims to be? How do we prevent fake payment apps?
Roy: Zach's PMI proposal
distinguishes open/proprietary methods
... the way you specify each one is different
... open payment methods involve (in the proposal) URNs.
... and proprietary methods are URLs which have origins.
... and browsers would compare origin of the payment app with
origin of the payment method to help determine whether it's the
right app
Max: We have some other ideas as well that we can write down.
<Zakim> AdrianHB, you wanted to ask about delegation
AdrianHB: What happens if a proprietary payment method owner wants to delegate authority to a third party proprietary payment app?
<Max> +1
AdrianHB: I think that we may
need metadata for this
... we need to define how this works and might be for both
proprietary and open payment methods
<adamR> +1 to AdrianHB’s point about origin binding being too restrictive — I was planning to put a comment on PMI issue 11 to this effect
<jnormore> +1 ^
AdrianHB: I don't like putting together "identification of payment method" with "getting data about payment method"
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md
<scribe> ACTION: Max to write up a new proposal (in the proposals directory) about managing authenticity of payment apps [recorded in http://www.w3.org/2016/08/17-apps-minutes.html#action04]
-> https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md
https://github.com/w3c/webpayments/blob/gh-pages/proposals/zach-pmi.md
[Back to user experience table]
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions
Max: Would be better for merchant
web site to take control of the display of the payment
app.
... and we can provide good practice to browsers of how to
display but in the end merchants have final control
<Roy> -1
<scribe> ACTION: Max to write up some thoughts on merchant-controlled display of payment apps for selection [recorded in http://www.w3.org/2016/08/17-apps-minutes.html#action05]
IJ: Anyone available to do payment app demos at TPAC?
Max: W3C staff in China is
chatting with us about demos.
... so we are thinking about that.
... we are looking into but can't confirm 100% yet we will have
a demo
<Roy> I'm in the same boat Ian
<Max> +1
IJ: Any regrets?
[Hearing none]
<JasonYANG> thanks