Web Payments Working Group Teleconference

<ShaneM> regrets ShaneM

<scribe> scribe: Ian

<nicktr> agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160818

<zkoch> Sorry, I just got here

<zkoch> 1 min

<zkoch> looking for headphones

<nicktr> proposal-> https://github.com/w3c/webpayments/issues/170

hmm, I updated ... will try again

zkoch: The proposal addresses some key filtering scenarios.
... by putting in data field we are doing it the way other apps are doing it today (e.g., Android Pay and Apple Pay do this)
... proposal addresses credit/debit
... I have been going back and forth on this. I am not a fan of filtering attribute to the top-level
... this seems to be only for basic cards at this time.

(cf 170 https://github.com/w3c/webpayments/wiki/Agenda-20160818 )

scribe: so I do not support the proposal of 170. Prefer that this be in the "data" blob for now and we can revisit this as new use cases arise.
... I also am not inclined to address AND and OR more explicitly

<Zakim> AdrianHB, you wanted to say this forces the browser to process the data blob

AdrianHB: My only comment is that we want the data blob to be something that the browser doesn't have to parse and understand; this requires them to do so
... this feels short-sighted to me
... this proposal to leave in the data blob seems in contradiction to previous comments about security (not having unlimited lists, e.g.)

zkoch: This seems today like only a basic card thing. We make lots of weird exceptions for cards today which is appropriate and pragmatic.

<Roy> For what it's worth, while exploring tokenized cards, we need a similar feature most likely

<Zakim> manu, you wanted to note not a strong position, request more use cases, ask if we can start by generalizing and back off if implementers don't like it?

<dlongley> there's potentially an argument for new payment methods to add other mechanisms like this that payment mediators *MAY* use to make the experience better for the user, but it isn't required for them to filter?

Manu: I don't think we have a strong position on this; good points on either side. Regarding "use cases before we move out of data blog" resonates for me.

<dlongley> so mediators MAY look at the payment method data to provide a better experience, but it wouldn't be a requirement

Manu: but I also find compelling the "not having to parse" point

<zkoch> Agreed dlongley

Manu: I think we could easily go either way ... start general or start payment method specific

<AdrianHB> dlongley makes a good point, keen to explore more

Manu: I don't want to start in the data blob and then move outside

(IJ; But that is possible)

Manu: When we get to CR we should have a clear story...we should make a decision one way or the other
... we should be consistent (over time)

<Zakim> AdrianHB, you wanted to ask if we should allow 3rd party apps to process basic card (i.e. make it a VERY special case)

<zkoch> I think it’s Nick

<zkoch> neverminndd misread :)

AdrianHB: dlongley makes a good point - if we leave it in the data blob, browsers special case...I do worry about the relationship between browser vendors and people who are pushing different payment methods
... It feels like every time we talk about basic card to everything else we give ourselves headaches.
... part of the conversation around issue 11 is: doesn't it make sense for every payment app out their to say they support basic card to get in front of users?
... here's a controversial proposal - should we allow third party apps to return raw card details?

<zkoch> I want to punt this question for now and make it its own

<zkoch> Because it’s a great question, but it’s a big, complicated one

AdrianHB: so basic card is basically a replacement for form filling

<dlongley> -1000 to making it so payment apps can't play in the space

AdrianHB: if we said only browsers could return basic card, maybe it solves this problem...I realize that's controversial

<Zakim> nicktr, you wanted to wonder aloud about per method encryption

<jnormore> -1 to restricting basic card to only browsers. Limits flexibility for merchants.

nicktr: I want to wonder aloud about several things...we have spoken previously about signing blobs
... if we put the extra information in the blob, then the browser has to also implement that capability...I wanted to see whether that is relevant to this discussion.

<AdrianHB> If we limit basic card to only browsers we can define a better scheme for apps to return card details (like one where the card numbers are not returned via the API but rather POSTed to a URL defined by the merchant)... thinking out loud

zkoch: Regarding encryption .... the data blob that is passed in right now is minimal and may not need encryption...there are other payment methods where encryption could be more useful, and I think that in many cases those would be proprietary

nicktr: The reason that it's front of mind for me today is that I've been reading the EBA draft standards on strong authentication
... they are making noise about keeping identifying information confidential
... and that raises the question about whether we need to encrypt on outbound

zkoch: filtering would not be personally identifying

nicktr: You can't encrypt the blob though .....

zkoch: There's nothing IMO to encrypt in the blob

nicktr: Regs came out this week...I am reading them...and they are still draft

zkoch: I have a request - please send email to the WG pointing us to the draft

<scribe> ACTION: nicktr to send link to new EBA regs to the WG [recorded in http://www.w3.org/2016/08/18-wpwg-minutes.html#action01]

<trackbot> Created ACTION-27 - Send link to new eba regs to the wg [on Nick Telford-Reed - due 2016-08-25].

<nicktr> RTS from EBA -> https://www.eba.europa.eu/documents/10180/1548183/Consultation+Paper+on+draft+RTS+on+SCA+and+CSC+%28EBA-CP-2016-11%29.pdf

<Zakim> manu, you wanted to ask if you'd want to filter SEPA methods?

manu: What would make this decision easy would be if we could come up with another use case.
... is SEPA another use case?
... I think that if we don't have other use cases, it probably means we are doing something prematurely (even if I'd love to generalize)

<dlongley> +1

<zkoch> SGTM

<zkoch> +1

AdrianHB: I am ok to close issue as postponed until we have more use cases

+1

<jnormore> +1

Issue 11

https://github.com/w3c/webpayments-method-identifiers/issues/11

zkoch: What I wanted to discuss earlier is that in the proposal we made 2 concrete proposals to change payment request API

<AdrianHB> https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md

zkoch: I want to be sure people are ok with the changes
... we would now allow N > 1 instances of a payment method identifier

(IJ: +1)

scribe: the second change is to modify payment details modifiers to enable per payment-method pricing
... matching algorithm is "first match"
... so most specific filters go first

IJ: +1

<adrianba> +1

<AdrianHB> +1 - but would like to see the spec text obviously

<maheshk> +1

<dlongley> if it works, sounds fine to me.

<manu> +1 - if it works, sounds like a good approach.

nicktr: I hear consensus; please push forward, Zach

payment method identifiers

https://github.com/w3c/webpayments/wiki/Agenda-20160818#pmi-notes

adrianhb: We don't have consensus yet on the proposal.
... the proposal distinguishes open v. proprietary
... question was "why use URLs"
... we are back to the question of "what the requirements are" (for PMIs)
... the proposal says that the requirements are different for open v. proprietary
... concerns of some respected voices on the github repo is URL-as-identifier is an anti-pattern
... zkoch has said he wants to point to resources, but we don't know what they are yet.

IJ: also w3c v. other

<manu> Ian: The open vs. proprietary is potentially a useful distinction. W3C controlled vs. other is a useful distinction.

<manu> Ian: Sometimes those axes overlap, but sometimes they don't, specifically there are some choices we may make because W3C is in a privileged position and can publish short strings. We may want to place other requirements to make sure other parties do something extra, whether the other parties are open or closed.

<manu> Ian: URLs for everyone but W3C - where are we optimizing, and are we doing so with the constituencies that we're identifying in mind, is W3C in a privileged position or not?

zkoch: Have been having discussions with lots of stakeholders.
... one useful thing to do is look at top 100 ecommerce sites and how they accept payments
... credit cards get us somewhere but there are other methods that other companies would like to see supported by payment request...so my comments are informed by those discussions.
... I agree with Tab Atkins that URLs as identifiers are problematic...but there are a number of things in payments that make URLs valuable despite the limitations.

<nicktr> this report is in the public domain and might be a helpful view on the distribution and usage of different payment methods -< http://www.worldpay.com/global/insight/articles/2016-07/global-payment-report

zkoch: in particular given the use cases of the people we are talking to.
... the benefits include:

(1) brands are very protective and also very busy....the web affords them what they need ... they have URLs, JS, IFrames...so they may ask "why is this new thing more useful"?

scribe: one thing I want to remove from the obstacle list is "no process is required"...people can use existing origin-based security model
... and we can, in addition, put things at the ends of URLs to improve the user experience
... right now the spec says that if you don't match throw a false.

<manu> +1 to use the identifier mechanism that the Web uses... which is the URL.

scribe: but you could imagine that the browser does something useful like getting data about a payment method
... that can improve the use experience.

<dlongley> +1 to what zkoch is saying about making it easier for people to do more decentralized innovation

scribe: we have postponing the discussion of "what they point to" but I am hearing people may not wish to decouple them

<Zakim> AdrianHB, you wanted to make another (controversial) proposal - related to #11

scribe: we would have to make a decision knowing the anti-pattern exists, but I think the benefits outweigh the costs

<dlongley> reminds me of the decision to allow URLs to fail (return 404) instead of forcing every link/document to be up to date in a centralized database

adrianhb: One thing based on what you said that I want to highlight....what the URLs point to depends largely on what payment apps look like.
... so I think this PMI discussion relates to payment apps and we can't make a decision about PMIs and what they point at until we have a better idea of what payment apps will look like.
... we can't decide on pointing at app or manifest or other until we have greater clarity about payment apps (and esp. how they are registered)
... I support using URLs but I think we need to prioritize what they point to.

<dlongley> +1 to figure this out by furthering the payment apps spec and direction

AdrianHB: My controversial proposal is that instead of differentiating proprietary v open...we could have URLs for ALL payment methods EXCEPT cards.
... we have a bootstrapping problem and perhaps we should make basic card a string
... and treat it as an exception...
... also regarding apps announcing support for card payments....and collecting card data...

<jnormore> +1 to URL pointing to a manifest to improve user experience, agree that it needs to be informed by payment app registration though.

<dlongley> +1 no, it's a bad idea

AdrianHB: the controversial piece of my proposal is that browsers determine who can do payments

<zkoch> Same thing as before, I think this is a good question that we should discuss, but it’s a bit orthogonal to how we identify them

AdrianHB: browsers are well-positioned to evaluate whether apps are doing bad things

<manu> I expect many formal objections if we say "only browsers can handle card payments"

<zkoch> So would vote to bring this up as topic next call or a github issue :)

<dlongley> if this group wants to specify good practices to help identify bad payment apps, that's another thing

AdrianHB: summary - payment methods identified by URLs...basic card an exception...browsers curate card-supporting payment apps

<Zakim> manu, you wanted to ask if we're saying that payment method information (name, description, how to install, partners, etc.) are at the end of those URLs? Isn't this the key

manu: I think it makes sense to identify payment apps...but if we make a decision that there is no metadata associated with a PMI, then it makes sense to have strings in a registry

<zkoch> Yes, +1

manu: is the main question whether we want machine-readable data?

<adrianba> the idea that we want something located at the URL was the most significant reason for me switching my preference to URL

<dlongley> +1 to adrianba

<AdrianHB> +1 - I believe the group is in consensus we should use URLs and define a machine-readable resource that is at the end

<AdrianHB> We must evaluate the cost of this though

IJ: What ;is the cost of parsing "small set of strings or URLs"

zkoch: Not a problem.
... ok to say simple strings for w3c-published identifiers

<dlongley> +1 to zkoch and AdrianHB

zkoch: and URLs for other things

<Zakim> Ian, you wanted to ask about parsing cost

<adrianba> I can live with using strings instead of URNs but it isn't my preference

adamR: The choice of URNs isn't just so that we can say "All URIs"...other orgs may want to use URN space

<zkoch> That’s a fair point

<dlongley> +1 to adamR

adamR: if they want an identifier they don't want dereferenced, they too could use URNs
... Regarding browser curation of card-enabled payment apps gives me heartache. Whitelisting by browsers is antithetical to the open web

<manu> Note that we have browsers curating lists of malware providers, I'd expect this to be the same.

nicktr: I am also pretty uncomfortable making browsers more privileged than they need to be

zkoch: I largely agree with Manu's characterization of the problem...whether something machine readable will live at the end of the URL
... one thing that I propose is that there is not a dependency on the payment app spec

<dlongley> +1 to manu, but i don't want to see a situation where open payment methods are somehow a fundamentally worse experience for users than proprietary ones

zkoch: I think we can write a proposal that both payment request and payment apps depend on
... we define what lives at the end of this URL

<dlongley> which could arise depending on how app policing occurs.

zkoch: could be used by registration spec and by browsers as well

<manu> +1 to define the manifest

<adrianba> +1

<nicktr> what's in the manifest?

IJ: Payment app spec talks about identifying payment apps....

<manu> NickTR, name, description, image - we'll have to decide that.

<dlongley> identify by URL and fetch URL to get machine readable data is a well known pattern, may work in a variety of places.

<nicktr> manu, metadata for the payment method or the app?

<dezell> Several related/unrelated points (not taking airtime):

<dezell> 1) most in-app applications merchants create that I've seen use ACH, not cards.

<dezell> 2) I have heard criticism of the Payment Method Identifiers not reusing the codes used in ISO20022. So if URI are always followable, an easy (provable) translation to/from ISO would be a big help is assuaging concerns, and if that method doesn't require following (i.e. "machine readable") that might have lower overhead.

<dezell> 3) We (NACS) are not in favor of trading contractor lock-in (for merchants) for browser lock-in.

<manu> nicktr - why can't it be both?

<adrianba> +1 on not blocking - if the payment apps proposal has requirements of PMIs then they should be explicitly stated, which was the feedback I gave at the F2F

zkoch: I think we can separate this out
... I still stand by the proposal to distinguish proprietary from open...and app and payment method.

<zkoch> Not always a 1:1 mapping, just most of the time

IJ: I believe that blurring payment method and payment app will be a source of problem

AdrianHB: I agree that is a point of contention
... and may have pragmatic consequences like using origin for security / etc.

zkoch: Happy to have the conversation separately
... and understand the exceptions (in the real world)

adrianhb: I suggest we have the discussion in the payment app task force

zkoch: Meanwhile, let's see if we can independently define "what's at the end of the URL"

<Zakim> manu, you wanted to note that he's hearing consensus - use URLs, define a manifest... then we can come back and see if we've made a horrible mistake... we're not in CR, we can try

manu: I am hearing consensus to use URLs
... the only thing we need to see is the proposal for what is at the end

<dlongley> +1 manu

<Zakim> AdrianHB, you wanted to propose we resolve what the payment method identifier will not be to make progress

<ShaneM> +1 to developing a spec for what is at the end of a payment URL

adrianhb: +1 .... we need to resolve what will be at the end.
... I think that's impacted by the payment apps work

PROPOSAL: W3C can mind short strings for some payment methods, otherwise URLs (which includes URNs)

<manu> -1 vague

<adrianba> -1

<dlongley> a URN isn't a URL :)

AdrianHB: URNs provide context outside of the browser

<manu> Note that my -1 was that I don't have a strong opinion of URN vs. short string UNLESS we take AdamR's comments into account (other organizations may want to use URNs)

IJ: We could also do short strings now and then mint URNs separately if we want

<ShaneM> dlongley: wow - them's fightin' words

<manu> I also note that this whole debate is only because serving up HTTP URLs don't scale for smaller organizations. This whole issue would be taken care of if we were using something like IPFS :P

<manu> and we wouldn't be having this discussion... we'd be using URLs for everything.

<manu> (IPFS URLs)

TPAC Agenda

nicktr: Send us in your items

CFC extension

nicktr: Now 25 August based on Manu input

<nicktr> Manu's blog -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0077.html

<ShaneM> And please vote (editor's hat)