See also: IRC log
adamr: We are moving forward internally but don't have updates for you yet
<Zakim> rouslan, you wanted to talk about payment app status
rouslan: Payment App API status
in Chrome - we are attacking both native apps and
service-worker based apps
... for native, partially implemented behind AndroidPaymentApps
flag
... if you use that you should be able to write an android app
that talks to PR API
... next steps would be to download the manifest file
... I think there's a patch from Samsung that will pre-query
apps to see if they are ready to pay
... meanwhile on Service-worker based apps, Opera and Samsung
are implementing changes.
... it's currently behind a flag
... in there, service workers can register as payment apps and,
I believe that the app names can be displayed (but not yet the
options)
... working on how to invoke the payment apps
<Zakim> adamR, you wanted to ask Rouslan about the native interface
adamR: Last time we looked into this it wasn't possible for another browser to hook into the native app api.
Rouslan: I received feedback that
my spec was not specific enough. I started to add more WebIDL
type information to the spec
... I also plan to add more algorithms, which would make it
easier for other browsers to implement the spec without looking
at Chrome code
... the spec is still changing...we noticed some issues from
developers where we should really be following more of a
service-worker based approach
... so the spec is available but is changing based on that
feedback
[Spec URL from Rouslan]
<rouslan> https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/fsslHD1Gf88/K2KpikS6BwAJ
Conor: I tested Tommy's
implementation of the service-worker based payment apps into
Chromium. It worked well. I was able to host my own payment app
and use alongside Tommy's and use either to make a
payment
... so that was cool (even though still early)
... is the work that Tommy has released the same work that
Rouslan mentioned here?
Rouslan: Same
... his work will end up at some point in Chromium source
code
Conor: It would be great to have one build of Chromium that supports both the native and service-worker bits
Rouslan: It will be available in an upcoming Chrome canary release
Conor: For native android apps,
what if I wanted to launch a native windows or MacOS app
... do you foresee support for that at some point?
... if not, could it be triggered through a scheme host?
... could you launch a native app in a native app in mac and
have a service worker communicate with it (e.g., via
localhost)?
... the native app could do the work and the service worker
could do the communication
adamR: Is it possible to install
web extensions? They could act as service workers and call out
to native apps
... that's the writeup that I threw together in london
rouslan: We haven't looked
explicitly into extensions as payment apps
... I think that the service worker approach is not as hacky as
you think...it's flexible and powerful
... because service workers can show a page in the browser AND
talk to server (which can reach out to devices or apps on
devices)
... I think the solution that you have described is not only
reasonable, but I think I would prefer this approach
Conor: Ok, I'll look into this further and perhaps share a proof of concept
adamR: If you have things that you want to do that you can't accomplish with the web platform, it's probably best to raise those as gaps in a W3C context
Ian: +1
{rouslan has to leave}
Conor: other app developer
stories?
... My other question (for Google) is about a web payment app
developed by google shared on a google+ page
<rouslan> https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/fsslHD1Gf88/K2KpikS6BwAJ
<rouslan> https://drive.google.com/drive/u/0/folders/0B9_TYWUgXNVFS093UmZXUlEwcVE ?
<rouslan> doc is evolving
<rouslan> https://polykart-credential-payment.appspot.com/ ?
Pascal: I am working on a third party payment app using our SDK for banks
<Zakim> AdrianHB, you wanted to mention app we'd like to develop for FTF to demo Interledger via PaymentRequest
AdrianHB: Our team at Ripple
would like to connect inter ledger work with payment apps
... we are hoping to put together either a web app or android
app or both
... to show at the FTF meeting
IJ: I can easily see Evan and Stefan at the FTF. :)
<Zakim> mathp, you wanted to comment on web payment apps
mathp: I have a question about
web payment apps
... has the group considered a repo where we can share
information about payment app implementations?
<pascal_bazin> good idea
conorhwp: I have discussed this
internally. We plan to release some source code for payment
apps that we're working on
... we will likely release both a web-based and native
app
... client side code would be released
... would be on github
Experimentation part of our wiki:
https://github.com/w3c/webpayments/wiki#experimentation-and-implementation
Mathieu: Yes, that's what I was looking for.
<scribe> ACTION: Ian to write to the web payments WG and suggest that people list their projects there (when they can) [recorded in http://www.w3.org/2017/01/12-apps-minutes.html#action01]
Frank: We are still playing
around with Tommy's work
... we are trying to get our proper payment app in there....no
feedback yet
Conor: Seems like there is some good implementation experience (both native and web)
https://github.com/w3c/webpayments-payment-apps-api/issues
https://github.com/w3c/webpayments-payment-apps-api/issues/73
IJ: Any experimentation around opening windows?
Mathp: We'll look into this
IJ: Any experimentation around the use of HTTP Link headers to get from payment method URL to manifest file
https://github.com/w3c/webpayments-payment-apps-api/issues/14
Is anybody implementing "Launch when there is only one match"
AdamR: Regarding the feature, we
have some problematic privacy issues. I am ok as long as the
user opts into the behavior
... note that calling payment request API does not itself
require user interaction.
... can be done "on load"
Mathp: I think we should leave to browsers to figure it out.
<AdrianHB> +1 to leave to browsers
IJ: I was not suggesting a requirement, only asking if people are experimenting around this
https://w3c.github.io/webpayments-payment-apps-api/#selection
AdamR: We should not encourage inherently unsafe behavior
IJ: I need to fix this: "If the
user selects an unregistered recommended payment app, the user
agent SHOULD offer the user an opportunity to register
it."
... that is now how it works.
... Should we say anything in 9.2?
Mathp: Where the spec could bring
value is around security (e.g., origin information)
... if we encourage implementers to display origin or security
status, it mitigates the issue around selecting and
facilitating selection of payment apps
https://w3c.github.io/webpayments-payment-apps-api/#selectable-app-information-display
IJ: Is the requirement to display origin information about each payment app?
Mathp: Maybe the requirement is not during *selection* but rather when the app is running
https://w3c.github.io/webpayments-payment-apps-api/#payment-app-authenticity
IJ: I could see advice there that payment apps should show users their origins when running
Mathp: +1
<scribe> ACTION: Ian to write up a proposal for a security consideration on payment app origin [recorded in http://www.w3.org/2017/01/12-apps-minutes.html#action02]
/me missed the question
Roy: For tokenized spec (and
possibly other payment methods), app implementers don't have
merchant information
... these are requests from "the internet at large"
... have we thought about providing origin information to the
payment app
https://w3c.github.io/webpayments-payment-apps-api/#dfn-app-request-data
10.1 Payment App Request Data
IJ: Origin information of merchant is available to payment app
Proposed: Close issue 14 with no change
https://github.com/w3c/webpayments-payment-apps-api/issues/14
AdrianHB: The security risk is that users accidentally set defaults to pay
IJ: The flow I hear that is harmful is:
- merchant calls PR API without user interaction
- app is launched automatically since one matching app only
- app automatically returns card information since configured to do so for that origin without further user interaction
AdrianHB: I think we need to say something about user agents taking into account both origin and payment method when the user sets up a default payment app
<AdrianHB> +1 I don't think we should PREVENT anything but provide some guidance on security issues to watch for
IJ: Feels to me that the whole flow from pr API to payment response data has to have SOME user interaction
AdamR: But buttons can be mislabeled
Mathp: I am hearing for PR API that there needs to be explicit confirmation from the user to pay (e.g., "You are about to pay with Amex. Is that ok?"
conorhwp: I need to go....thanks all!
<AdrianHB> Have to go too I'm afraid
<mathp> Ian: Explicit or Implicit confirmation -> user sees the pre-selected payment app
IJ: Does someone want to raise the PR API issue?
https://github.com/w3c/browser-payment-api/issues
IJ: Should I register an issue?
Mathp: I can have a look at the spec and raise and issue if needed
<scribe> ACTION: Mathieu to review PR API to see if required user confirmation is there, otherwise raise and issue [recorded in http://www.w3.org/2017/01/12-apps-minutes.html#action03]
IJ: Then Payment App API spec can say "If the app is configured to return response data automatically, user agent needs to take into account confirmation per PR API."
AdamR: We explicitly want to
enable 1-click scenarios.
... the model I have in my head is camera access
... the way it works today is "for this origin, don't ask me,
just do it."
... I am proposing we can give the user a stateful config but
absent that there needs to be confirmation
Mathp: So I am hearing a combination of a payee origin + payment app origin is sufficient for automation
AdamR: If the user says "yes, for
this origin always grant access to this payment app"
... automatic payment is analogous to a merchant with card on
file using it to get paid without further interaction from
me.
<Roy> I need to roll out, see you all next thursday