See also: IRC log
https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login
IJ: Registration goes up tomorrow
draft agenda -> https://github.com/w3c/webpayments/wiki/FTF-Sep2016
[We walk through agenda]
MaheshK: Please add Samsung demo to the implementation session
<scribe> ACTION: Ian to work with Rouslan to organize the implementation session [recorded in http://www.w3.org/2016/09/01-wpwg-minutes.html#action01]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0000.html
zkoch: Would like to get agreement on four points:
Absolute URLs will be used to identify proprietary payment methods
Strings will be used to identify open payment methods and will be maintained by the WG
Every payment method must have an associated payment-manifest file (or similar)
There must be some standard way to access that payment-manifest file (or similar)
zkoch: Some discussion of URNs on
the thread. Mostly cost is "burden for developers". Mostly
benefit is "all things are URLs" except that's not a big
benefit.
... so the current proposal is just short strings minted by w3c
and defined in a w3c spec
... My focus today is not on exactly what needs to be in the
manifest file. Initial proposal is to start conversation. And I
don't know that we need to nail down the right way to get the
data
... I think we need to resolve these issues to make
progress.
... The manifest file can be flexible enough to accommodate a
number of use cases.
... we don't need (yet) to know what the vocabulary is exactly;
we can work on that at TPAC
<Max> +1
<zkoch> PMI: https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md
<zkoch> Manifest: https://github.com/zkoch/zkoch.github.io/blob/master/payment-manifest.md
zkoch: The idea of the manifest
is data for a payment method.
... there's a proposal for how to identify the manifest (based
on the "root" payment method URL)
... and within the manifest file you can put information about
the method - default payment apps, for example
... this way, as implementers we can verify securely that the
"true" payment app has been installed. (cf the Alipay use
case)
... that's the summary
<Zakim> Ian, you wanted to talk about the MUST and to say that the division is not open/proprietary but w3c/non-w3c
IJ: can we express what these PMIs identify by definition rather than "MUST"
+1 to specifying what a PROCESSOR does when it finds or does not find a resource
<adamR> +1 to Ian’s point — I agree that the spec should spell out what happens rather than mandating things and not being clear about what happens if those aren’t met.
<ShaneM> +1 to specifying all behavior
IJ: I suggest the split be: W3C -
short string; other -> URL
... it's not about open v. proprietary
zkoch: I don't want to see proprietary methods done at W3C for short names.
<adrianba> seems fine to invent short strings anywhere
IJ: We could also establish a principle that w3c will not mint proprietary short strings
<adrianba> doesn't have to be at W3C
<adrianba> collisions are unlikely
<adamR> adrianba: That doesn’t end well.
zkoch: What you said is an implementation detail within manifest files....where we need consensus is that there are things minted by w3c (minimal set) and other things identified by URLs
adamR: I also have tweaks and
also support the general idea. I want to reinforce something
from AdrianHB. The headline is "defaults matter"
... the way that things are spelled out now, by default things
specified by URL are constrained to the domain in that
ULR.
... as long as we give people the means to constrain, then the
default should be "open"
... I think it will make a big difference in ecosystem.
zkoch: I think we'll probably
need a longer discussion at TPAC. I agree that defaults matter.
I would rather map to what is common in the marketplace
today.
... I have not seen may examples today.
... I agree it's possible (or should be possible) to
accommodate both cases via the manifest file, whatever default
we choose.
adamR: I think that there are
arguments for being explicit rather than implicit (about
origins)
... and you'll need some extraordinary syntax for
"everyone"
zkoch: I welcome direct proposals to the manifest; please use github. I think these are valid points.
Max: We had a similar proposal
(in payment app task force) with some slight differences. The
general direction is similar.
... perhaps we can discuss the details offline
... in general, we agree on the four points of Zach's points
(in particular the manifest idea)
... Correction: we agree with 1/3/4...not sure on point 2
yet
... Second point - the definitions of "open" and "proprietary"
methods
<ShaneM> I like 1/3/4... 2 feels weird. And I don't understand how 2 and 3 relate.
IJ: Can you propose revisions to the specs for definitions?
<pascal> W3 maintaining le payment identifier would help to verify/certify the security level of the method
IJ: how would you characterize the distinction?
zkoch: I will work on refining the definitions.
<adrianba> there should be no business relationship needed to implement open methods - they are defined as *open* standards
<scribe> ACTION: zkoch to work on the distinction between open and proprietary [recorded in http://www.w3.org/2016/09/01-wpwg-minutes.html#action02]
<trackbot> Created ACTION-30 - Work on the distinction between open and proprietary [on Zach Koch - due 2016-09-08].
<adrianba> and can be independently implemented
+1 to independent implementation without prior business agreement
<Zakim> ShaneM, you wanted to say that web apps indicate that there MUST be a manifest file... same thing and to ask if it makes sense to define a mechanism to permit broader use rather
shane: At its core, I feel like it is fine to say "there must be a manifest file" as long as we spell out behavior when there is and isn't.
(IJ recaps his distinction - I prefer to write specs for software than for people)
shane: Regarding "default" - my preference is that the default be "restricted"
<adrianba> I don't think we should be trying to enumerate every possible use case for the manifest file
shane: but I don't have a strong reason right now
<adrianba> of course specs will say how they specifically use the manifest file
<zkoch> ::cue elevator music::
IJ: Is the expectation that multiple specs / groups could define what goes in the manifest?
adrianba: Not saying that
exactly; just that more discussion is necessary (including
about scope)
... I am just trying to push back slightly on the idea that a
PMI URL has associated with it an algo on how to get to the
manifest file.
... of course there will be implications to that manifest file
existing or not in the system
... one example is that if you come across the file one type of
behavior is to ignore...there will be an implication for that
particular scenario
... we will not define every possible way it will be used and
preclude others
... there may be a number of different ways in which the
manifest file is used in some scenario (e.g,. native apps) but
are not defined by this group
<adrianba> hopefully we'll have an extensible format
<adrianba> because inevitable this group will want extensions even if we didn't consider proprietary extensions
IJ: yes, we should be explicit about the extension points
zkoch: I mostly was thinking about payment methods here...but I hope payment apps will also make use of the manifest
+1 to a few principles for how the manifest file can/should be used up front (e.g., on extensibility)
IJ: AHB's points here or by email?
zkoch: Email
[Straw poll]
<adamR> +1
<adrianba> +1
zkoch: I am hearing ok to use absolute URLs for proprietary and non-w3c payment methods
+1
<ShaneM> +1
[on manifests]
<adamR> +1
<adrianba> +1
<ShaneM> +1 - and +1 on working out the details
zkoch: I also hear consensus on a manifest file and we should move forward even though more details to work out
+1
[on short strings]
<adamR> +1 for short strings
<adrianba> +1 for short strings
zkoch: I propose we adopt short strings (not URNs)
+1
<adrianba> we might constrain the characters allowed
<ShaneM> +1 to not URNs... I feel weird about short strings still but I will get over it
<rouslan> +1
<Zakim> ShaneM, you wanted to ask something abotu short strings
<alyver> +1 on short strings
shane: One thing I don't quite understanding...what about manifest for short strings?
zkoch: Don't have the same needs for open (e.g., default) and payment method specs are there for other behavior
<adrianba> this needs to be clarified in the proposal because it is ambiguous
IJ: Zach do you have what you need?
zkoch: Yes, I think we are unblocked
<ShaneM> I reserve the right to lobby hard for JSON-LD
zkoch: we should go away and look ahead to use cases.
RESOLUTION: (1) manifest files (2) short strings for w3c payment methods (3) URLs for non-w3c and proprietary
IJ: Quick FYI on I18N issues that were raised
https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0002.html
https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0003.html
IJ: we will discuss CFC decision and also a payment apps topic