See also: IRC log
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
NickTR: Updated agenda of FTF meeting
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
<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
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
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.