See also: IRC log
<scribe> scribe: Ian
<AdrianHB> https://github.com/w3c/webpayments/wiki/Agenda-20160526
<scribe> scribe: Ian
Registration -> https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/
adrianHB: register and get your hotel quickly
candiate topics -> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29#candidate-topics
adrianhb: We are using
"milestones" in issues list
... if you want to know "what's coming up" then milestones is a
good place to start
... furthermore, "help wanted" label is a standard github
label...that means "we need a proposal"
... proposal can range from text in the thread to a pull
request
... "High priority" issues also helpful to look at. I am
managing that prioritization
AdrianHB: Motivation is reduced
verbosity in payment request input data
... the urgency for these goes up (perhaps) if we do grouping
semantics
manu: Aliases seem like they make
it easier for developer. I suggest no aliases in v1.
... People could create aliases in libraries that use the
payment request API
<dlongley> helper.paymentMethods('visa', 'mastercard', ...) => ["https://visa.com/basic-card/..., ...]
<adamR> dlongley: +1
adrianhb: Does anybody think there is a need for short names/aliases other than for reducing verbosity?
<dlongley> +1 to adamR
adamR: I don't see a need for them. People are copy and pasting
<manu> +1 to adamR
adrianba: Our original motivation
was not strictly about verbosity, it was more about short names
for common things
... And that having a short name (without a domain) would allow
us to bootstrap the mechanism
... I agree with Manu's proposal to not support short names in
v1
<manu> We can always re-open an issue if there is new information.
<manu> ahh, the good old "vote on it while the proposer is getting married" spec attack.
PROPOSED: No short names/aliases for PMIs in v1
MattS: What does that mean in practice for ubiquitous payment method identifiers?
<manu> Ian: Meanwhile, Matt Saxxon has a proposal - more generic URL for card payments in most payments even if we don't get card brands to publish those specs.
IJ: MattS has a proposal about generic card spec.
<manu> MattS: How do these new URLs get minted?
<manu> We could mint them as URNs *ducks*
MattS: But there has been pushback about using w3.org for URLs that we mint.
AdrianHB: I think this proposal is independent of those questions. We won't have "visa" as a short name, but we still need to address the question of well-understood identifiers.
MattS: Yes, that will push the concern to another issue.
<dlongley> +1
+1
<manu> +1
<AdrianHB> +1
<MattS> +1
<adamR> +1
<dlehn> +1
<Roy> +1
<brian_s> +1
<adrianba> +1
<ShaneM> +1
RESOLUTION: No short names/aliases for PMIs in v1
<apaliga> +1
https://github.com/w3c/webpayments/wiki/PMI_Notes
<alyver> also having difficulty.
<manu> Ian: We want people to be able to specify a high-levle matching mechanism - not URL matching - we want a subbrand to match a higher level brand.
<manu> Ian: Allow people to say "I accept any kind of debit card" - more abstract use cases.
<manu> Ian: I was at card not present expo talking this week - talking to merchants - they're quite keen on this functionality. It's a bit complex to implement, makes matching harder, URI equivalence testing becomes more difficult.
<manu> Ian: Matt came up with a first version of an idea - let's do it as URL paths - /brand/subbrand/ - but that turns out to be a bit brittle. It doesn't allow you to express the full graph semantics, but may be able to address a couple of use cases. You could do graph matching semantics by using query parameters.
<manu> Ian: We can catch the use case by saying "visa but not electron" via another way instead of URL semantics - where you say "I do not support this". If you have grouping, being able to exclude items from the group becomes important.
<manu> Ian: In the very early implementations of payment request API, people will demand this.
<Zakim> manu, you wanted to put forward a concrete proposal: Do not support grouping semantics in v1.
Manu: Concrete proposal is to not
support grouping semantics in v1. I think there is a better
solution to the problem via helper libraries. I'm not sure we
have a handle on what we want to do.
... Some ideas:
1) Have a URL reference a list of URLs
2) Have a js library that can expand a single URL into N URLs. This library can be expanded automatically.
-1 to requiring a library to use the system
<dlongley> helperLibrary.accept('X').exclude(['Y', 'Z']) => [...]
<dlongley> not *required*, just makes it easier.
Manu: You don't _have_ to use a
library...you can specify all the PMIs if you want to
... my concern is that we are trying to solve a problem we
don't aver a firm grasp on.
<adrianba> +1 - this doesn't seem like minimum viable functionality
adamR: I think Matt has made a
good case for going down this path.
... what about using regexps as input?
<manu> -1 to regexes - developers have a hard time w/ them, especially when they don't know the universe of text that's being searched.
<MattS> -1 to regexs
I also think regexps may be overkill
<Zakim> AdrianHB, you wanted to say we already kind of support grouping, just we do it badly
adrianhb: The way we are doing PMIs already today ... we kind of support grouping.
<ShaneM> https://xkcd.com/208/
adrianhb: The idea of my proposal
is to use a PMI as a "top level brand" and use query params for
subclasses
... as filters
... We want multiple URLs to be able to point to the same PM
spec, which is a kind of implicit groupings
brian_s: In Europe this is a hot
topic of conversation.
... regulation allows merchants to say "I except all these card
types EXCEPT these types"
... one question .. .if we say this capability may not be in
v1, what's the time scale for the next version?
adrianhb: Good points...there ARE
use cases here (e.g., from Europe)
... the second point is when is v2?
MattS: We are removing functionality and saying "it can be in v2" but we've not minted any URLs yet in our specs, so we don't know whether they
will meet our use cases.
<AdrianHB> ?
<ShaneM> I don't think we "mint" any URLs
MattS: I am +1 to the proposal
but I think we need to mint actual URLs to see if they meet our
needs.
... There's a clear use case in my region for distinguishing
debit and credit
AdrianHB: I am hearing mix of "push it down the road" and "there are clear use cases"
<adrianba> I think we should say we not support it in v1 (motivation is keep it simpler) but new information as MattS describes could re-open this
<manu> Ian: At a high-level, I think there is enough mixed views that I prefer that we not close this today.
<manu> Ian: More concretely, I'm wondering if there is a happy medium - first hypothesis is that this is only relevant for cards, not sure it's relevant, but will assume it is for this call.
<MattS> I don't think this is only relevant for cards. I am using that example because 1) it is our only spec today 2) the non cards ecosystem has not expanded sufficient to make it clear this is needed. I can give some clear examples of how we might see this expand in the future which needs the grouping
<manu> Ian: If you want to refer to a top-level brand, you always use the top URL plus something else - we don't specify what the other thing is, we let the payment apps figure it out. People could experiment w/ query parameters, recognize there is an issue, provide guidance. What this would mean in practice - use case #2 - merchant announces A, user announces B which is a subclass of A. It still doesn't catch the NOT case. I'm inclined to push for that for the time bein
<manu> g.
<manu> Ian: It may be an optional parameter in the API - much of the time people may not use it. But that would help you continue to do simple URL matching. More modest matching - want us to think more about it. Maybe there is a path forward that helps a modicum of standardization that lets us experiment.
adrianhb: I think we need pretty rigorous standardization here. The mediator behavior needs to be well-specified.
<MattS> +1 to Adrians point on needing this to be rigourous
<Zakim> manu, you wanted to say that the problem can be addressed in v1 w/ helper libraries.
manu: I'd like to push the group
to make a preliminary decision today.
... maybe we can hear from people on IRC.
<adamR> I think we’re not operating from the same set of information, though.
PROPOSED: Do not support grouping/subclassing in v1.
adamR: People have different ideas of what the set of identifiers for cards will look like. I propose that if we can find someone who is sufficiently familiar with payment types to put together what the entire list of PMIs might look like at this time, that might inform the decision
<MattS> there is no entire list, that is the problem, it is volatile
<manu> ... which is why I don't think we should create grouping semantics over a list that's volatile.
See also Zach's list -> https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html
AdrianHB: Granularity is changing (in EU)
<MattS> I am happy to put together a good set of example use cases though
AdrianHB: card payment landscape has changed in past few years
<MattS> I can also put together some non cards examples
AdrianHB: there are laws being introduced that are forcing the system to become more open and our API needs to be accepting of the granularity required.
PROPOSED: Do not support grouping/subclassing in v1.
-1
<alyver> MattS, I would be happy to help you with the use cases.
<AdrianHB> -1
<manu> +1
<dlongley> +1
<adamR> Ian: If the list we’re operating on is O(12) entries long, then I think enumerating is fine. If it’s O(100), then I think there’s a very different answer.
<brian_s> Matt: I can help from the Visa side (not next week though as i'm on holiday)
<adrianba> +1
<ShaneM_> +1
<MattS> +0, look after the use cases
<adamR> So I’m not + or - : I think it’s not the right time to call the question
<alyver> +1
<brian_s> -1
<manu> Thanks - that helps me see that we don't have consensus in the group yet.
total: -3, +5, 2x0
<Roy> -1
adrianhb: I suggest people make further proposals.
MattS: I can put together some
example use cases and bring back to the WG.
... that should help get us on the same page.
... I appreciate this is a complex problem domain
... I hear people saying "too complex" rather than "not
useful"
AdrianHB: See my proposal
https://github.com/w3c/browser-payment-api/issues/205
... there are some bits in there about matching (e.g., ignore
domain name)
... payment method may not be defined by the payment method URL
owner.
... I heard a lot of push-back on .well-known.
... but perhaps the most important part of the proposal is to
use query params
... proposal does not include a "not" operator
... could be added
... I will revise my proposal
<manu> Ian: I'd like to propose a set of edits on the PMI spec based on consensus views - I think we have pretty much agreed - we're not going to do aliases or dereference the URL that is used as a PMI. The spec can be clear that the primary purpose for using URLs are for identification. The spec doesn't define what happens when you derefernce the URLs. We're close on syntax.
<manu> Ian: As an editor, does that give you things you can do on the spec.
<manu> adrianba: I can change a few small things - like around aliases. Zack and I were talking about the structure of the URLs. So, we may not have consensus on that.
<manu> Ian: Maybe practices are their own thing, but I'm hearing you say that there isn't consensus yet - you think there is possibility of conformance that we dereference the URL and get something from there?
<manu> adrianba: We may end up dereferencing.
<manu> AdrianHB: We have consensus on not using aliases for now.
adrianhb: Payment Apps task force
(ad-hoc) has formed in the past 2 weeks.
... we met last week and Ian will coordinate moving forward
(among editors)
... we are preparing to bring a proposal to the group
... it's happening in the proposals folder on github
... Tommy has posted a few things to the list and is working on
a polyfill
... if you'd like to join the discussion, let Ian know
2 June