See also: IRC log
doh
sorry on the wrong room
arriving
https://www.money2020.com/sessions/part-2-one-click-buying-new-w3c-standards-for-web-payments
<adamR> Is Ian talking?
<adamR> I’ll have to reconnect
<pascal_bazin> Sorry I cannot join. Technical issues with audio.
<zkoch> Oh, interesting. I also hear nothing
<zkoch> hah
<zkoch> Reconnecting..
https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md
Zach, let me know when you are back
<adamR> rouslan: Can you hear Ian?
<rouslan> adamR: I can't hear anyone except beeps
<adamR> Okay, it looks like the VoIP stuff is flat out not working
<zkoch> No one can hear anyone
<adamR> I bet pascal_bazin can’t hear either
<pascal_bazin> no I can't
<zkoch> just hear dyou
<zkoch> i hear rouslan
<adamR> well, it looks like we effecitvely have two bridges
<adamR> One for everyone on voiip
<pascal_bazin> I hear rouslan
<adamR> and one for everyone on the phones
weird
<adamR> And they’re not connected to each other
Let me kill the webex and start again
sorry
<pascal_bazin> I hear Ian from time to time
<zkoch> ::hears things::
https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md
<scribe> scribe: Ian
zkoch: There are different use
cases....
... I only want to call PR API if there is ANY form of payment
available
... up to "I want to know all the payment methods that are
supported"
... for privacy reasons, we don't want to leak information. We
don't have information about merchants which could be a form of
trust relationship.
Proposal is for canMakeActivePayment()
scribe: to avoid privacy issues, it is available once per origin in a window of time
adamR: Regarding time-bound --- per origin across all windows/tabs?
zkoch: Yes, generally.
AdamR: Minor suggestion - allow
it to be called with exactly the same payment types as quickly
as possible
... if people are doing multiple transactions in multiple tabs,
allow them to call for exactly the same payment methods
... I think the devil in the detail here will be what the time
period is.
... it might have to be on the order of 10s of minutes or hours
to be effective as anti-fingerprinting
zkoch: +1
IJ: Please clarify - can you specify individual payment methods?
zkoch: Yes, via the instantiated payment request object
MaheshK: I agree with the
background and requirements...we discussed a bit last
week
... on this specific proposal I have a question - PR API can be
called from an iframe
... so this new proposed API can be called from an iframe
... so a limit of one-per origin might not work...if multiple
iframes are created and deleted
... if merchants really want to, say, show two buttons but
prioritize them and call the API twice, what would be the
biggest issue
zkoch: This proposal is that
there is no definitive way to know for sure whether the user
has a particular payment method instantiated.
... I don't think it makes sense to throw in the towel too
quickly
... I recognize that there are some immediate needs..but I
don't see the value for PR API of making it easy to provide
multiple "buy with" buttons on sites
... regarding the multiple iframe risk, I think that is
complex...and we can also look at limiting the API to the
parent origin
<adamR> +1 on associating with the top-level origin
alyver: I think this is a huge
step in the right direction. I see one problem from a Shopify
perspective - lots of merchants come from the same origin
... so problem if a shopper is shopping on multiple shopify
sites
rouslan: In this case, is there an iframe in the site?
alyver: No, the user is redirected
rouslan: I think the answer lies
in a cookie regarding availability of PR API
... the time boxing is per user
alyver; but if the user is at multiple Shopify stores....
rouslan: Just check the cookie
zkoch: I will think more about this...cookies is one idea
alyver: We do have merchants that use their own domains, but others still using the same domain
<Zakim> rouslan, you wanted to talk about shopify usecase
zkoch: I am hearing "positive direction"
MaheshK: Let's discuss further offline
<scribe> ACTION: zkoch to flesh out the proposal additionally, with more info about iframes, time window, Shopify use case [recorded in http://www.w3.org/2016/10/27-wpwg-minutes.html#action01]
<trackbot> Created ACTION-39 - Flesh out the proposal additionally, with more info about iframes, time window, shopify use case [on Zach Koch - due 2016-11-03].
IJ: Mahesh, are you happy with the direction?
Maheshk: Yes, if I can talk with Zach and see if we can consolidate the proposals
IJ: Put on agenda for next week's call?
zach: Yes, maybe not PR ready yet
<MaheshK> Forgot to ask one last question, zkoch: this proposal targeting spec 1.0?
<zkoch> Yes
zkoch: Yes, I think this has come up a lot
(No Roy)
https://github.com/w3c/browser-payment-api/pull/292/commits/af2d188ee7df21e9a8f35e57a73f828dc96d7923
zkoch: Editors discussed this
week
... some of what AdrianB and I expressed (which we will also do
via github)
... I recognize the use case.
... I am concerned about who is going to use the URL
... not clear who uses the URL
... seems also more request on the backend...unlike the payment
request that comes back through the mediator, we don't have any
control over the data that is sent back to the end point
designated by the URL
... you don't have the benefit of payment request
normalization
... also, AdrianB thought that the mediator should not create
the transaction ID...rather pass it in from the merchant
<ShaneM> yes... my original concept was that the merchant would generate an ID that meant something to them
adamR: What is the perceived advantage of merchant-generated?
https://www.w3.org/2016/10/18-wpwg-push-minutes.html
<Zakim> MaheshK, you wanted to point out may be an adv. of merchant-generated
adamR: My argument against merchant-generated was that merchants would have to do more
MaheshK: There is an advantage to
merchant-generated...e.g., merchant has integrated PayPal
India
... the server understands the ID...when the button is
integrated to the web site...merchant calls API from paypal and
sends ID...
... so having the browser generate the ID means paypal india
has to make changes
alyver: I think Ian is
remembering an Andre/Ian conversation
... when is the ID returned by browser to the merchant...if
returned "later" then there could be failure that causes
merchant to not get it
... my initial preference was for the merchant to generate the
ID...I think that many merchants are used to doing that
... e.g., Shopify creates IDs for merchants
... but other merchants almost always have to send a merchant
transaction ID
MattS: I agree with what has been
said today. Some additional considerations:
... possibility for optionality..how can you guarantee that
merchant scope does not interfere with another merchant's
scope
... it's often useful to map IDs to a transaction. E.g., SEPA
has concluded you may need multiple transaction IDs.
... so that would favor BOTH: optional merchant and mandatory
browser-generated
(IJ thinks you could scope ID by origin)
MattS: You could argue that the
merchant generated ID (optional) is method specific, which is
how it's modeled for SEPA
... I like having a browser generated standard, but not
everyone will be able to use it (or need to)
adamR: +1 to MattS
====
Summary:
- There are use cases for merchant-generated IDs
- Merchants often generate IDs already today
- If they generate, then there's a scope issue on the server side (e.g., might be managed through origin information)
IJ: If people do this all the
time and scoping is possible, then is there a remaining big
value to user agent generated
... Server could append origin information
... Are your concerns assuaged?
MattS: I haven't thought through
all the use cases..
... my gut thinks it is still useful to have both
... but I agree an ID is needed
<scribe> ACTION: Ian to point Roy and the editors at the discussion [recorded in http://www.w3.org/2016/10/27-wpwg-minutes.html#action02]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
MattS: As part of SEPA / Credit
Transfer spec work, we have aligned work with the SEPA
standard...we've also done some work to map those terms back to
ISO 20022 terms (which are less Web-friendly)
... we have not yet updated the Credit Transfer
specification
... we also were wondering whether to do that mapping for Basic
Card
... Kris is going to take the lead on this
... this may change nothing as far as implementation, but small
changes might be possible to make life easier.
... one example....CVC is called "Card Security Code" in the
specification
... my suggestion is that we align the terms...we've not done
that yet but it's the plan
<adamR> +1 to consistency :)
3 Nov - TIME CHANGE
Europeans heads-up!
IJ: No progress on my action to write up a proposal
- PR API issues
scribe: query by merchant
<scribe> ...pending updates to PMI
- Push payments
scribe: we have a concrete proposal
- Payment apps
scribe: awaiting reviews from Max
and Zach
... spec is evolving
- Test suite
- Basic Car
scribe: alignment on terms
IJ: Any other topics on people's minds I forgot?