See also: IRC log
<scribe> Scribe: Ian
<CarmenSpitz> what is the meeting password to join the webex?
zkoch: Lots of pull requests
happening.
... Adrian and Marcos met yesterday (I could not make it)
... I will sync up later today
... I think we are making steady progress on issues
Pull requests => https://github.com/w3c/browser-payment-api/pulls
AdrianHB: How close to CfC?
zkoch: Not yet there; there's an
issue that we are tracking related to things needed to do to
get to CR
... we are not done with core issues to get to CR
https://github.com/w3c/browser-payment-api/pull/523
^^^^
adrianHB: That's the pull request re: going to CR
https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0011.html
<AdrianHB> Ian: we sent email around looking for response by 11 May
PLEASE RESPOND to the proposal by 11 May 2017 (10am ET).
<AdrianHB> ... btw f2f and cfc the editors resolved some easy issues and put markers in for the open ones and some respec cleanup
<AdrianHB> ... not much substantive change since f2f
NickTR: Any questions?
(None)
AdrianHB: The question has come
up incidentally a few times.
... What does it mean to implement a short-string payment
method in the browser.
... I think that basic-card is special in that the browser
responds to the payment request
... but for other payment methods, what is the implementation
expectation?
NickTR: does this problem go away if we don't use short strings? Are they "treated" differently?
zkoch: We view URLs as completely
open. We don't do any (extra spec) validations
... but for short strings we are more intentional
... we do have an enum in chrome
... it's easily updatable but does require an update.
... this came up in the editor call 2 weeks ago
... firefox, edge, and FB were in agreement that user agents
should be thoughtful on implementation of these short
strings
... URLs don't require the same level of control because of
existing domain name system
... short strings may come from W3C but are not required to
<Zakim> AdrianHB, you wanted to ask about validation of data
zkoch: We don't do data validation
AdrianHB: Why are we defining it
as WebIDL instead of JSON?
... should we switch to something less rigid?
... or make a note that there is no validation of data.
IJ: Is the use of WEbIDL an assertion about browser validation of data? I was not aware of that.
AdrianHB: Maybe we need a cautionary statement that the browser does not validate the shape of the data
IJ: I suggest we don't spend more time here, but welcome a PR with a cautionary note.
AdrianHB: This WebIDL does not
represent anything in the DOM. Therefore doesn't seem like it
should be in WebIDL
... I will log an issue with some more detail on this.
See request from Marcos => https://github.com/w3c/webpayments-methods-card/issues/27#issuecomment-298289630
IJ: Going to Rec would trigger patent policy and exclusion period and min 150 days
adrianba: It was not the case
that my view was that these should be Notes. I think there was
discussion early on about what should be a Rec and what should
not. It seemed like there was consensus in the room in London
that we should plan to progress Basic Card as a Note.
... I thought that was a reasonable position
... I also would highlight what Ian said, though.
... a concern might be with some participants in the group,
whether someone could make an argument that in order to fully
support basic card end to end, that some IP would be implicated
as an essential requirements
... that people had not originally planned would be part of the
scope of the work of this group
... an assumption may have been that IP for processing cards
would not be in scope
... I am comfortable with the decision to go to Note. I don't
see a strong need to go to Rec
... I think we should think carefully before we make that
change.
<Zakim> AdrianHB, you wanted to explain my comment in the agenda
AdrianHB: I think I understand
Marcos' comments on the thread as saying "we will be generating
things from the IDL" and so this should be a Rec
... I think one way to deal with this is to say that the WebIDL
is only meant to describe the data
adrianba: I don't think there's
any part of the process that requires that WebIDL be in a
Recommendation rather than a Note.
... it is true that in general we create recs for things that
have binding IP commitments.
nick: I have been uncomfortable
with short strings
... is there another way to indicate that this is a bridging
technology?
... should short-string construct be removed from normative
context?
<Zakim> nicktr, you wanted to ask what the consequences would be to take short-strings out of the normative text
<nicktr> ack q?
<AdrianHB> ian: I think we're confalting the need to be rec track with the making shrot strings informative
<AdrianHB> ... -1 to making short strings informative
rouslan_: -1 to moving short strings to informative
NickTR: My concern is people will migrate toward that instead of URLs
rouslan_: I think it's important
that we keep short strings; not everyone can do URLs.
... apparently interledger cannot do URLs for some reason and
would prefer a short string
NickTR: Ian has thus counter-proposed that AdrianBa and Marcos discuss, so we won't close today
[AdrianBa agrees to that approach]
https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0001.html
IJ: Tokenization task force meets Tuesdays
<AdrianHB> ian: heads up. focus is on other work but don't want to lose focus on tokenization and credit transfer
<AdrianHB> ... some spec edits and some todos and nexts steps
<AdrianHB> ... thanks MattS for recent action
<AdrianHB> ... TF will come back to the WG with updates as available
Draft spec:
https://w3c.github.io/webpayments/proposals/interledger-payment-method.html
adrianhb: The reason we don't
want to use a URL - like the other specs, it's a payment
without an authority behind it.
... we have having a hackathon
https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0014.html
mattS: I have no issues with the
spec and your recommendation.
... I hear a difference of opinion about short strings being a
bridging mechanism and your position that they are for payment
methods with no authorities behind them.
AdrianHB: Fair point. I see the
short string as a tool available for people who have the issue
raised in Lisbon - "we can't host a payment method manifest
file"
... I would say that basic-card the payment method is a
bridging payment method
... but I would not consider the short string mechanism overall
to be for bridging
zkoch: I support short strings
are bridging mechanisms, but there is also value in short
strings. They map to openness. They are simple to implement (in
browsers)
... we accepted in the WG the burden to "deal with" these short
string proposals
... at first I pushed back on AdrianHB's proposal and suggested
a Url, but I also recognized AHB's point that there are
entities that don't have formal ownership by design. And so
short strings are nice to have in our toolbox
... I am not very concerned about this becoming a big problem
or thinking of this only as a bridging mechanism.
... I think that having them imply open by default will "weed
out" the majority of requests.
nicktr: My position on short
strings is well known.
... I will ask a different question...anyone else on the call
who is interested in implementing inter ledger and thinks we
should take up as a work item in the group?
IJ: I have not seen it yet and would like some time before responding to any question about taking up as a work item
NickTR: I propose that we send a separate note to the WG about the spec, and a time scale for considering it as a work item.
+1
<AdrianHB> +1
AdrianHB: It's useful to me to indicate some concerns about the short string process. Effectively being gatekeepers.
IJ: We are not global
gatekeepers. People can approach browser vendors outside of
W3C.
... we have consensus process to make decisions.
AdrianHB: Don't want evaluation criteria to be made up.
<nicktr> if some browsers implement some short strings, but not others, then a merchant implementer cannot know whether to use or not - we get back into the old world of "if IE then else if navigator then..."
<nicktr> Strong +1 that the short strings process and the payment method publication process to be documented
IJ: I think it's fine to get experience and then set expectations. But healthy debate, people signing up to do things, people implementing, and being in scope for our charter are all good signs
AdrianHB: I am happy to figure
out details as we go
... From what I've heard during today's call (from Zach) is
simple though intentional. It think that we should consider
"the amount of real work" of the WG as a consideration.
... if one consideration for taking up the spec is "writing the
spec" but another is "implementation by payment apps" that
latter might happen outside the wg
MattS: When we had discussion
about identifiers was to use URNs. Any reason not to use
those?
... please remind me why we chose not to do that?
AdrianHB: Short strings don't have registration burden.
MattS: URN has registration process; avoids web server requirement
IJ to browser vendors: Do you implement URNs or just URLs?
zkoch: We'd probably throw an exception
adrianhb: I note that short strings themselves could be URNs.
<adrianba> the pmi is being written to expect https as the scheme
zkoch: A lot of people in Chrome pushed back on URNs
adrianhb: I am happy to close here, but would like to document expectations for short strings for PMIs.
nicktr: Strong +1
AdrianHB: I think we need to be specific about what the WG's requirements are to take up a new payment method identifier spec
IJ: I suggest we just use Call for Consensus, with expectation setting at most
<MattS> my counter proposal would be that we should allow URNs (as part of the URL area) in addition to short-string, that would give a path away from browser registration of short-strings
<scribe> ACTION: AdrianHB to send email to group about the inter ledger spec and expectation of CfC in 2 weeks [recorded in http://www.w3.org/2017/05/04-wpwg-minutes.html#action01]
<trackbot> Created ACTION-56 - Send email to group about the inter ledger spec and expectation of cfc in 2 weeks [on Adrian Hope-Bailie - due 2017-05-11].
<zkoch> review this: https://github.com/w3c/payment-method-manifest
<zkoch> !
11 May
<zkoch> :)