W3C

Web Payments Working Group Teleconference

23 Jun 2016

Agenda

See also: IRC log

Attendees

Present
Rouslan, Ian, Kepeng, Jason_Yang, BrianS, adamR, dlehn, AdrianHB, Nick, Mahesh, Manu, dezell, dlongley, alyver, ShaneM, nicktr
Regrets
Zach
Chair
Nick
Scribe
Ian

Contents


Kepeng: Can we change the meeting time to be 1 or 2 hours earlier?

Ian: The Chairs and Team contacts will discuss

<scribe> ACTION: AdrianHB to work on regular meeting times [recorded in http://www.w3.org/2016/06/23-wpwg-minutes.html#action01]

<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

<scribe> agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160623

<scribe> scribe: Ian

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

FTF meeting update

NickTR: Updated agenda of FTF meeting

https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29#agenda

scribe: moved some information around...time for payment request API, payment apps, payment method specs
... testing, security review
... and HTTP API work as well

<manu> Ian: Something we talked about in the Chairs meeting - Payment Request API to discuss implementation experience

IJ: Focus on implementer experience on day 1

Nick: We are keen to see demos...we have something to show from Worldpay

<Zakim> rouslan, you wanted to talk about demos

rouslan: Yes, I'd be happy to show a demo

Payment Architecture Summary

<manu> https://w3c.github.io/webpayments/proposals/wparch/

Manu: Purpose of the doc is not to lay out a formal spec or detailed architecture.
... more to give people an introductory summary about roles and communications
... goal is to try to reflect what we have today with a slight lean to the future.
... Rouslan, Katie, AHB, Ian reviewed the document
... there have been some request changes

[Manu walks through sections of the document]

<manu> Links to specifications that detail each aspect of the architecture in more detail are also provided for implementers.

<manu> https://w3c.github.io/webpayments/proposals/wparch/#roles-in-the-architecture

Manu: There is one item in here where I changed name from payment request to payment instruction
... that was at the request of the ISO 20022 RA colleagues
... and because we are going to be dealing with subscriptions at some point
... that can be taken out.
... also there is something that talks about payment app registration

<Zakim> AdrianHB, you wanted to provide some high level feedback and discuss next steps

adrianhb: Thanks, Manu.
... a great first stab at this
... this is probably a direction than a formal architecture document
... it feels like the group does not want a formal architecture document.
... so for next steps, I propose that we agree to what kind of document we want
... if this document looks like what we want, then we can adopt it and work on it.
... so I want to understand what we want first
... So the question is "do we want a summary doc"?
... I agree with Ian that the first draft needs to reflect what we have already done
... if we want to introduce a new concept like payment instruction, we should discuss further before introducing the new terms
... our process has been to lead with low-level documents.
... and then we are summarizing what we've done
... if we want to proceed in a different fashion, we should make a conscious decision to do otherwise.

<dlongley> +1 to AdrianHB, another option for things where we don't yet have consensus is to put them as issues in the spec

<AdrianHB> +1 to issue markers for discussion points

<dezell> +1 to both dlongley and AdrianHB on markers

<AdrianHB> +1 to ian - we should not prioritize this document yet

<AdrianHB> -1 to wiki first. I think this is mature enough

<adamR> +1 to Ian’s point also. This is useful information, but I don’t think we need to take it on as a formal document

<Zakim> manu, you wanted to note that W3C has NOTEs, and that it's difficult to prep discussions for face-to-face without some of these documents - like WP architecture summary.

Manu: It's ok for this to be in a document format.

<AdrianHB> +1 to publishing as a note

Manu: I don't think anyone is asking to prioritize the document without this sort of document.

<dlongley> +1 to manu

Manu: there is an issue that we want to talk about around payment instructions...it's earlier to make the architectural point though this doc.
... I'm saying let's get this in as a work item then refine it.
... the ask today is to bring it into the group and work on it as an ED ... it doesn't have to be high priority

Kepeng: I think it's useful to have this document for newcomers
... also I suggest we can take some content from the Payment App Notes wiki.
... some of that might be useful here.

https://github.com/w3c/webpayments/wiki/PaymentApp_Notes

nicktr: From my perspective it feels like this is a useful document.
... my position it that it would be better if it reflected what we have today
... and we could use issue markers
... I'm also conscious that this went to the mailing list Friday

<manu> +1 to reflect what we have today - I can make those edits quickly, and put in issue markers for future direction.

nicktr: I think it would be great to take this up as a WG item as a Note.
... let's give the group a week to do that and then bring this back to the agenda next week.
... make sure it is clear that this Note exists as an explainer text
... let's put the question to the group next week.
... people can request changes to Manu over the next week.

<manu> W3C MIT - but can publish it anyway

Nick: I"m keen to have this done before FTF, even if done by email

<ShaneM> +1 to CfC before F2F one way or another

Payment Method Identifiers

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

AdrianHB: Background - Ian, MattS, and myself have been looking at the problem of matching
... we don't think that simple URL equivalence will provide sufficient matching granularity.
... use case where people want to differentiate based on subbrand, or card type, or risk profile (e.g., platinum or gold).
... expressing these constraints becomes exponentially hard if you need to specify more and more PMIs
... so the proposal is that where people want to provide constraints, they still identify a payment method, but they can add constraints.

<manu> it feels like "constraints" to me, atm.

(We have not figured out syntax for expressing those constraints yet.)

More detail:

https://github.com/w3c/webpayments-method-identifiers/issues/5#issuecomment-225665121

adrianhb: There are two implementation examples: query string data or JSON
... the proposal today is to adopt "a system like this" but not a particular syntax.
... I think we need more experience before we decide on a serialization
... so the question for the group today is whether to include in v1 a simple constraint system that would be implemented as part of the browser matching algorithm
... note that the proposal is that there's a small amount the browser does (to do, for example, substring matching) but that the values and terms are payment method specific.

<manu> Ian: The biggest counter-proposal, other than don't do this, has been from Rouslan who had a simplified method for doing this.

<manu> Ian: I wasn't sure yet if we had worked that out.

AdrianHB: I think Rouslan's proposal oversimplifies and may not handle other scenarios we may see, or to handle multiple dimensions

[Rouslan proposes a tree; we have been thinking as a graph]

<Zakim> rouslan, you wanted to talk about my proposal

Rouslan: I think the financial industry participants should continue to discuss the requirements.
... but prefer that we not overcomplicate

dlongley: I also don't want to overcomplicate. We don't want payment response messages to be rejected by the merchant.
... it sounds to me like we are not matching on the right thing
... or payment methods may also need to encompass more information
... we might see more payment methods arise
... I feel like we are trying to save on bytes but don't understand the use cases.

<ShaneM> +1 to not quite understanding the problem we are trying to solve

<Zakim> manu, you wanted to support exploring constraining subtypes of a payment instrument, not as a hierarchy - do merchants want to have this granularity? Need data.

Manu: We might be trying to solve the problem at the wrong abstraction layer
... I don't know how many different types there are
... I don't know what granularity merchants want to specify
... e.g., how many say "I only want to take platinum"

<dlongley> it's not just about number of types either merchants may take all of them but change on prices or other factors

STORIES -> https://github.com/w3c/webpayments/wiki/PMI_Notes#stories

manu: I don't think we have enough data and use cases to say we've addressed the problem

nicktr: I can tell you first hand that some merchants ... larger merchants are very interested in accepting some payment methods and not others
... e.g., in EU Corporate cards are not regulated and credit/debit cards are
... so the cost differential between those card types is significant

<dlongley> sounds like they should actually be different "payment methods" then (IMO)

nicktr: I am aware of another merchant that wants to accept a lot of cards, but not some that come through a mobile wallet
... for the sophisticated merchant, these needs exist
... actually being able to identify subtypes is hard to do

<dlongley> where the boundary for "payment method" is whether or not you're actually compatible, not simply what the protocol/format is

nicktr: there was a comment on this thread about what to support in v1
... I think that is the most germaine question

<Zakim> nicktr, you wanted to respond to Manu

<Zakim> AdrianHB, you wanted to say grouping does more than just reduce the amount of data

adrianhb: I recognize the desire to keep things simple in v1
... I am hearing people say this is only about reducing bytes

<manu> +1 to defining it as a graph, because that's what it is.

adrianhb: that's not necessarily true...using a graph instead of a tree or simple set lets you express different relationships

<manu> or rather... a set of "views" (aka constraints") on a set of cards.

AdrianHB: I think we should go away and spec how it should work.

<dlongley> +1 to AdrianHB

<manu> +1 to spec out how it would work - with a large set of PMIs if possible - and various selection criteria.

<dlongley> +1 to seeing how it looks and compare (and make sure we're covering use caseS)

AdrianHB: I am not hearing anybody vehemently opposing. Seems like we need to do more work to see if it works

BrianS: To Manu's comment on use cases..for physical cards one use case that is very real today is that in EU there is regulation that every card needs to identify itself as credit/debit/prepaid/commercial
... the proposal enables that sort of thing to be implemented, and that would probably be welcome by participants in Europe.
... the schemes have a solution for this for physical cards
... on the web you use digits of BIN and that doesn't work for this API because it happens after the selection mechanism
... so the proposal maps quite well to the expression of support for categories

Nicktr: We might want to have a specific algorithm for dealing with cards

<manu> Ian: I'd like to get to some other items on the agenda.

<manu> Ian: Let's postpone further discussion on this, work it through Github issues, in practice - we don't want PMI spec from advancing, I wouldn't want to do that.

<manu> Ian: Let's not try to work it out on the call.

AdrianHB: Part of airing the proposal was to get support (which we don't have yet) or just test the temperature. I think we should record the temperature.
... I am wary of putting a lot more work into it for no reason

<rouslan> +1 seems right

<manu> +1 - this is worth thinking about, but reserves the right to -1 the specific implementation.

<alyver> +1

PROPOSAL: The WG should continue to study constraints and this is the right direction (without details known yet)

<manu> +1

<ShaneM> +1 - I dont mind, but I think we need market data

<brianS> +1

<dlongley> +1

+1

SO RESOLVED

Payment Request issues

185 https://github.com/w3c/browser-payment-api/issues/185

Adam_: The main goal is to represent currency information to the user usefully.
... we have established to use ISO 3-letter codes
... the question is how to give hints for non-standard currencies
... one idea is URLs
... the other idea is undefined strings and let people work it out

AdrianHB: Yes, I think Ian's proposal is "either 3-letter ISO code or undefined"

[Can we please hear from Browsers here what they could do for non-standard code rendering?]

AdrianHB: Another proposal is to deal with the display of non-standard currencies separately.

<Zakim> manu, you wanted to want stronger support for URLs... ISO + URLs for non-standard.

adamr: If we are formalizing I am hearing "3-letter codes that are ISO codes are to be interpreted as such; other ones are error conditions"

manu: I want to voice stronger support for URLs
... I think "ISO codes + the rest of undefined" doesn't tell people what to do for a non-standard currency
... my concern is that people will just start using strings which might create conflicts with ISO space

<AdrianHB> +1 for something more formal for non-standard (Bitcoin has already got disagreement over BTC or XBT)

manu: my lack of support for "+" syntax is that we may be perceived to be managing a registry

<AdrianHB> +1 for manu's proposal

Manu: My concrete proposal is ISO codes for standard currencies, and for any non-standard currency, use a URL and we can figure out how the display works in another issue

<Zakim> nicktr, you wanted to talk about loyalty/coupon/retailer specific value

nicktr: An additional use case that comes up frequently when I talk to merchants....loyalty and coupons come up
... retailers may wish to represent point space things like "Nick's Dollars"...and we need to avoid clashes between merchants
... I think URLs are the way to go to avoid name conflicts

<ShaneM> I don't mind URIs for non ISO currencies

<Zakim> rouslan, you wanted to talk about 3-letter codes that are not ISO codes

rouslan: I agree with the 3-letter ISO codes
... browser can convert those into single characters where appropriate
... however, if a browser thinks that a code is not an ISO code but is three letter, then it should be ok for the browser to display that code as-is
... the browser will likely use the OS library
... which converts ISO codes to human-readable characters
... if the library does not have a code, it's ok to just display the short code
... I don't think we should reject outright every 3-letter code that is not specifically defined in ISO
... ISO changes their set frequently
... as far as URLs go, it sounds ok from the API perspective...but it would be good to hear more about how the information would be displayed

<AdrianHB> rouslan - is your proposal to allow either URLs or 3-letter codes and let the browser decide hwo to display 3 letter codes?

rouslan: having the browser follow URLs to collect more information would seem network intensive
... I would not be in favor of requiring the browser to download information on the fly

<manu> +1 to not slowing down UI for URL-based display information... make it declarative (hopefully)?

Nick: I had not thought about the behavior about dereferencing

<rouslan> AdrianHB: yes

<ShaneM> URI could resolve to json that contained (at least) certain attributes

<ShaneM> ahby logged on ttypts/3 from host :pts/4:S.0 at 8:21AM.

adamR: In response to rouslan...my primary concern with squatting on unallocated codes, suppose ISO allocates different codes that conflict...we might see wrong information tomorrow

<manu> +1 on AdamR's point and concern.

<dlongley> +1

adamR: I want us really hard to say "We will not reuse three-letter codes allocated by ISO"

+1

<ShaneM> s/ahby logged on ttypts\/3 from host :pts\/4:S.0 at 8:21AM.//

<nicktr> +1 to AdamR's concern on squatting

<manu> oooh, interesting proposal from AdamR.

AdamR: The examples we have been given have been bound to specific payment methods. Maybe the payment method specs can specify something about currencies
... and so you could learn that "when you are using a given payment type, this payment type means this"

<AdrianHB> PROPOSAL: Allow either URIs or valid 3-letter ISO codes as currency identifiers. The group will define a way for the payee to specify how a non ISO currency should be displayed

+1 to the ISO 3-letter

+1 to not squatting that space

<manu> Ian: With respect to URLs, let's let people specify short strings - if you encounter +ABC, plus some unicode character, that means just display that.

<manu> Ian: The plus is to avoid ISO character overlap - we're just saying "here's a string you can use" - that's enough to cover that space for now.

<dlongley> +USD == dangerous?

<manu> Ian: I agree to not squat, I agree w/ Adam. For the rest, we don't have enough information, but we should allow experimentation.

<manu> Ian: I don't want to say anything other than ISO is an error. I am ok w/ "if you see a plus, use it as is." I don't want to point to hints that are not going to improve interoperability. If browsers aren't going to do anything with info, then doesn't help to specify.

<AdrianHB> PROPOSAL: Allow either URIs or valid 3-letter ISO codes as currency identifiers. The group will define a way for the payee to specify how a non ISO currency should be displayed

<Zakim> manu, you wanted to note I don't have a proposal - AdamR, AdrianHB, and some other folks have thought about that more!

IJ: If the browsers won't do anything with the info anyway, it is not valuable to point people to those hints

<manu> +1 to the proposal.

<ShaneM> unicode has code points for all the ISO currency codes as far as I know. So that's good guidance

<AdrianHB> PROPOSAL: Allow either URIs or valid 3-letter ISO codes as currency identifiers. The group may in future define a way for the payee to provide display hints to the browser for non-ISO currencies

IJ: I object to the group working on specifying display of nonstandard currencies.

AdrianHB: I disagree that it's out of scope

Nick: Let's bring a proposal next week

look for more consensus

<ShaneM> errr... i didn't think the staff contact got a vote?

(I think we COULD agree on "iso 3-letter codes are used as such")

Next meeting: 30 June

<manu> I agree w/ AdrianHB - if we're talking about icons, we can talk about how currencies are displayed.

Summary of Action Items

[NEW] ACTION: AdrianHB to work on regular meeting times [recorded in http://www.w3.org/2016/06/23-wpwg-minutes.html#action01]
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/06/23 22:05:29 $