See also: IRC log
IJ: What state are you in and what should we expect by TPAC?
adamr: Turned proposal into spec
text
... I think the registration section is ready for review
... I'm working on the actual spec of the other part
... early feedback would be useful
... I've completed the section (I think) on returning info back
to the browser
... I've put everything in a "payment response" for now
... I'm not seeing any diff between payment app response data
and payment request API response data EXCEPT for data that is
optional (e.g., shipping address)
AdrianHB: I think we should still discuss whether payment apps should be able to provide some data back beyond the strict payment response
AdamR: For now payment app
response => payment request API response
... Regarding whether we can have spec text by Monday...I think
we can be code complete by end of this week
ian: Adam++
<AdrianHB> https://adamroach.github.io/webpayments-payment-apps-api/
AdrianHB: I looked it over; I
think it's great.
... today I had a meeting, got some questions, and it turns out
you answered them in the spec.
... so I sent the person I was speaking with a link to your
draft. :)
... I think we are heading in the right direction
IJ: We need to align PMIs with
the PMI proposal
... We also need to communicate clearly how it all fits
together:
- service workers
- manifests
- registration and updates
IJ: The spec used to say that you update data by calling register again. Is that still true?
Adam: Updates are handled per normal service worker updates; I will point to them.
IJ: What are the bounds of the payment app manifest?
AdamR: I'm not treating manifest
too much here. I cover what I have heard people want. It's not
a file; it's a structure.
... so the structure is in the spec (but data could come from
lots of places)
<Zakim> AdrianHB, you wanted to comment on manifest
AdrianHB: There's been some
discussion on github...and debate about whether app manifest
evolving for payments
... bottom line; I don't think there's anything we can use from
app manifest.
... I think for icons, etc. we need to spec it out
ourselves
... though App Manifest does some of these things, it's not
clear we can reuse it
<adamR> AdrianHB: to be clear, do you think your issue calls for any change to the spec text I’ve written so far?
IJ: Should we rely on app manifest spec for icons, etc?
Adrian: I think we should specify it ourselves, which is frustrating as I'd like to reuse app manifest
<AdrianHB> adamR: No
<adamR> AdrianHB: Thanks.
<adamR> https://adamroach.github.io/webpayments-payment-apps-api/#payment-app-manifest
AdamR: The draft spec aligns with Adrian's view
IJ: I would love to see section 6 expanded a tiny bit as an overview of "how we are using service workers"
AdamR: If I have time. I want to finish 10 first
IJ: even a single sentence in 6
like "we will expand this section with more overview of how
service workers will be used to handle updates, etc."
... I have invited Jake to the FTF meeting
... Any other people or groups we should find at TPAC to look
at this?
AdamR: TAG?
<scribe> ACTION: Ian to write to Dan Appelquist and Andrew inviting TAG (whoever wants) to the payment app discussion [recorded in http://www.w3.org/2016/09/14-apps-minutes.html#action01]
https://github.com/w3c/webpayments-payment-apps-api/issues
IJ: I may wish to close #34
... Is "where the data lives" an issue we need to address?
AdamR: I don't think it is
IJ: I am hearing that "origin" is more important for payment method manifest
AdrianHB: Even if we don't need to talk about a payment app manifest file, we still need identify payment apps
IJ: Identifier needs:
- You want to install an app? Go here!
AdrianHB: Service workers need to
be called in the context of a page..the page for getting info
about installing an app should not be required to be same as
page with service worker
... payment method data may include data like "URL of where to
get service worker"
... and when it executes it registers
-----
* You want to install an app? Go here!
* You want to ship some payment request data to an app for processing? Go here!
<adamR> Ian: To be clear, are you referring to the “https://www.example.com/bobpay/process” URL in the example at file:///Users/Adam/devel/webpayments-payment-apps-api/index.html#post-example ?
<adamR> Ugh, sorry, that’s my local copy URL. :)
IJ: what does "payment app identifier" mean?
AdrianHB: A string to identify a
payment app?
... and the proposal from Jake is that by being a URL, that
establishes a scope for the service worker
AdamR: The scope URL (except under some rare circumstances) will be the same thing passed into "register()"
<adamR> Ian / AdrianHB: This small section might help untangle the terminology: https://www.w3.org/TR/service-workers/#dfn-activate
AdrianHB: If I want to "get a payment app" there are 100 places I can get that.
<AdrianHB> https://www.w3.org/TR/service-workers/#dfn-scope-url
AdrianHB: Payment app identifier
is a URL (for scope) but is not to be dereferenced.
... "payment app identifiers" should be used in payment method
manifests to identify payment methods
IJ: I believe we need to define:
- payment app identifier
- statement that these identifiers are scope URLs for service worker and we do not expect them to be dereferenced
- these are typically going to be used in payment method manifests
jnormore: One of the main purposes of the identifier is to restrict which payment apps can use that method. How is there a restriction there?
AdrianHB: My understanding is you can't create the service worker at origin A and claim it works on origin B
<AdrianHB> https://github.com/w3c/webpayments-payment-apps-api/issues/35#issuecomment-246976419
<Zakim> maheshK, you wanted to comment on proprietary payment method vs payment app identifier
maheshK: I understand why the payment app identifier is useful...I assume there should not be any reason why the same identifier can't be used for both
(I agree)
<AdrianHB> open q: if a merchant wants to recommend a payment app and they use the payment app identifier the browser may not know where to go to actually install/use the app
<Zakim> adamR, you wanted to talk about ordinatlity of methods versus apps
IJ: I want to talk about methods/apps differently. I don't want to prevent people from using the same URI if they have a reason to do so.
TPAC TOPIC: Payment method id and payment app id usage
AdrianHB: Push payments...I also got feedback in my earlier today conversation
<jnormore> +1
AdrianHB: how to deal with failures (e.g., app dies and site doesn't know if payment completed)
<scribe> ACTION: Ian to walk through issues list with Adrian to prep for TPAC [recorded in http://www.w3.org/2016/09/14-apps-minutes.html#action02]
<AdrianHB> https://www.entersekt.com/
AdrianHB: I spoke with a company
that sells technology to banks.
... they mostly do authentication
... they are interested in writing a payment app
... that does auth using w3c web auth Api
... so they would be a great org to do a proof of concept