IRC log of wpwg on 2016-08-18

Timestamps are in UTC.

13:56:01 [RRSAgent]
RRSAgent has joined #wpwg
13:56:01 [RRSAgent]
logging to http://www.w3.org/2016/08/18-wpwg-irc
13:56:03 [trackbot]
RRSAgent, make logs public
13:56:03 [Zakim]
Zakim has joined #wpwg
13:56:05 [trackbot]
Zakim, this will be
13:56:05 [Zakim]
I don't understand 'this will be', trackbot
13:56:06 [trackbot]
Meeting: Web Payments Working Group Teleconference
13:56:06 [trackbot]
Date: 18 August 2016
13:56:31 [Ian]
agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160818
13:59:56 [dlongley]
present+ dlongley
14:00:06 [ShaneM]
regrets ShaneM
14:00:12 [manu]
present+ Manu
14:00:27 [manu]
Regrets: ShaneM
14:00:35 [Ian]
present+ Ian
14:00:41 [Max]
Max has joined #wpwg
14:00:44 [Ian]
scribe: Ian
14:01:46 [Dongwoo]
Present+ Dongwoo
14:03:51 [AdrianHB]
present+ AdrianHB
14:04:03 [AdrianHB]
agenda?
14:04:09 [jnormore]
jnormore has joined #wpwg
14:04:26 [nicktr]
present+ nicktr
14:04:31 [adamR]
Present+ adamR
14:04:44 [rouslan]
rouslan has joined #wpwg
14:04:45 [jnormore]
present+ jnormore
14:04:58 [rouslan]
present+ rouslan
14:05:12 [zkoch]
zkoch has joined #wpwg
14:05:15 [nicktr]
agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160818
14:05:35 [Roy]
Roy has joined #wpwg
14:05:38 [zkoch]
present+ zkoch
14:05:43 [zkoch]
Sorry, I just got here
14:05:44 [zkoch]
1 min
14:06:00 [zkoch]
looking for headphones
14:06:15 [nicktr]
proposal-> https://github.com/w3c/webpayments/issues/170
14:06:48 [Ian]
hmm, I updated ... will try again
14:07:30 [MikeSmith]
MikeSmith has joined #wpwg
14:07:45 [Ian]
zkoch: The proposal addresses some key filtering scenarios.
14:08:04 [Ian]
...by putting in data field we are doing it the way other apps are doing it today (e.g., Android Pay and Apple Pay do this)
14:08:22 [Ian]
...proposal addresses credit/debit
14:09:00 [Ian]
zkoch: I have been going back and forth on this. I am not a fan of filtering attribute to the top-level
14:09:07 [Ian]
...this seems to be only for basic cards at this time.
14:09:24 [Ian]
(cf 170 https://github.com/w3c/webpayments/wiki/Agenda-20160818 )
14:09:40 [MikeSmith]
RRSAgent, make minutes
14:09:40 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/08/18-wpwg-minutes.html MikeSmith
14:09:48 [Ian]
..so I do not support the proposal of 170. Prefer that this be in the "data" blob for now and we can revisit this as new use cases arise.
14:09:49 [MikeSmith]
RRSAgent, make logs public
14:09:57 [AdrianHB]
q+ to say this forces the browser to process the data blob
14:10:00 [Ian]
...I also am not inclined to address AND and OR more explicitly
14:10:10 [nicktr]
q?
14:10:11 [Ian]
q?
14:10:14 [Ian]
ack AdrianHB
14:10:14 [Zakim]
AdrianHB, you wanted to say this forces the browser to process the data blob
14:10:20 [nicktr]
ack AdrianHB
14:10:37 [Ian]
AdrianHB: My only comment is that we want the data blob to be something that the browser doesn't have to parse and understand; this requires them to do so
14:10:45 [Ian]
...this feels short-sighted to me
14:10:52 [manu]
q+ to note not a strong position, request more use cases, ask if we can start by generalizing and back off if implementers don't like it?
14:11:22 [nicktr]
q?
14:11:24 [Ian]
AdrianHB: this proposal to leave in the data blob seems in contradiction to previous comments about security (not having unlimited lists, e.g.)
14:11:54 [Ian]
zkoch: This seems today like only a basic card thing. We make lots of weird exceptions for cards today which is appropriate and pragmatic.
14:11:57 [Roy]
For what it's worth, while exploring tokenized cards, we need a similar feature most likely
14:11:59 [nicktr]
ack manu
14:11:59 [Zakim]
manu, you wanted to note not a strong position, request more use cases, ask if we can start by generalizing and back off if implementers don't like it?
14:12:00 [dlongley]
there's potentially an argument for new payment methods to add other mechanisms like this that payment mediators *MAY* use to make the experience better for the user, but it isn't required for them to filter?
14:12:10 [AdrianHB]
q+ to ask if we should allow 3rd party apps to process basic card (i.e. make it a VERY special case)
14:12:24 [Ian]
Manu: I don't think we have a strong position on this; good points on either side. Regarding "use cases before we move out of data blog" resonates for me.
14:12:31 [dezell]
Present+ dezell
14:12:31 [nicktr]
q+ to wonder aloud about per method encryption
14:12:32 [dlongley]
so mediators MAY look at the payment method data to provide a better experience, but it wouldn't be a requirement
14:12:43 [Ian]
...but I also find compelling the "not having to parse" point
14:12:53 [zkoch]
Agreed dlongley
14:13:04 [Ian]
..I think we could easily go either way ... start general or start payment method specific
14:13:21 [AdrianHB]
dlongley makes a good point, keen to explore more
14:13:23 [Ian]
...I don't want to start in the data blob and then move outside
14:13:27 [Ian]
(IJ; But that is possible)
14:13:39 [AdrianHB]
q?
14:14:00 [Ian]
Manu: When we get to CR we should have a clear story...we should make a decision one way or the other
14:14:06 [Ian]
...we should be consistent (over time)
14:14:12 [Ian]
ack AdrianHB
14:14:12 [Zakim]
AdrianHB, you wanted to ask if we should allow 3rd party apps to process basic card (i.e. make it a VERY special case)
14:14:14 [zkoch]
I think it’s Nick
14:14:22 [zkoch]
neverminndd misread :)
14:15:09 [zkoch]
q+
14:15:19 [Ian]
AdrianHB: dlongley makes a good point - if we leave it in the data blob, browsers special case...I do worry about the relationship between browser vendors and people who are pushing different payment methods
14:15:25 [manu]
q+ to ask if you'd want to filter SEPA methods?
14:15:31 [nicktr]
q?
14:15:54 [Ian]
AdrianHB: It feels like every time we talk about basic card to everything else we give ourselves headaches.
14:16:19 [Ian]
...part of the conversation around issue 11 is: doesn't it make sense for every payment app out their to say they support basic card to get in front of users?
14:16:33 [Ian]
...here's a controversial proposal - should we allow third party apps to return raw card details?
14:16:34 [zkoch]
I want to punt this question for now and make it its own
14:16:37 [adamR]
q+
14:16:43 [zkoch]
Because it’s a great question, but it’s a big, complicated one
14:16:50 [Ian]
...so basic card is basically a replacement for form filling
14:17:22 [dlongley]
-1000 to making it so payment apps can't play in the space
14:17:26 [Ian]
...if we said only browsers could return basic card, maybe it solves this problem...I realize that's controversial
14:17:28 [Ian]
ack nicktr
14:17:29 [Zakim]
nicktr, you wanted to wonder aloud about per method encryption
14:17:37 [jnormore]
-1 to restricting basic card to only browsers. Limits flexibility for merchants.
14:17:52 [Ian]
nicktr: I want to wonder aloud about several things...we have spoken previously about signing blobs
14:18:22 [Ian]
...if we put the extra information in the blob, then the browser has to also implement that capability...I wanted to see whether that is relevant to this discussion.
14:18:24 [nicktr]
q?
14:18:24 [Ian]
ack zkoch
14:18:44 [adamR]
q-
14:19:08 [AdrianHB]
If we limit basic card to only browsers we can define a better scheme for apps to return card details (like one where the card numbers are not returned via the API but rather POSTed to a URL defined by the merchant)... thinking out loud
14:19:17 [Ian]
zkoch: Regarding encryption .... the data blob that is passed in right now is minimal and may not need encryption...there are other payment methods where encryption could be more useful, and I think that in many cases those would be proprietary
14:19:31 [Ian]
nicktr: The reason that it's front of mind for me today is that I've been reading the EBA draft standards on strong authentication
14:19:42 [Ian]
...they are making noise about keeping identifying information confidential
14:19:57 [Ian]
..and that raises the question about whether we need to encrypt on outbound
14:20:08 [Ian]
zkoch: filtering would not be personally identifying
14:20:19 [Ian]
nicktr: You can't encrypt the blob though .....
14:20:27 [Ian]
zkoch: There's nothing IMO to encrypt in the blob
14:20:41 [Ian]
nicktr: Regs came out this week...I am reading them...and they are still draft
14:20:52 [Ian]
zkoch: I have a request - please send email to the WG pointing us to the draft
14:21:04 [Ian]
ACTION: nicktr to send link to new EBA regs to the WG
14:21:09 [trackbot]
Created ACTION-27 - Send link to new eba regs to the wg [on Nick Telford-Reed - due 2016-08-25].
14:21:14 [nicktr]
RTS from EBA -> https://www.eba.europa.eu/documents/10180/1548183/Consultation+Paper+on+draft+RTS+on+SCA+and+CSC+%28EBA-CP-2016-11%29.pdf
14:21:16 [AdrianHB]
q?
14:21:18 [nicktr]
q?
14:21:23 [Ian]
ack manu
14:21:23 [Zakim]
manu, you wanted to ask if you'd want to filter SEPA methods?
14:21:41 [Ian]
manu: What would make this decision easy would be if we could come up with another use case.
14:21:48 [Ian]
..is SEPA another use case?
14:22:03 [nicktr]
q?
14:22:52 [Ian]
Manu: I think that if we don't have other use cases, it probably means we are doing something prematurely (even if I'd love to generalize)
14:22:58 [dlongley]
+1
14:22:59 [zkoch]
SGTM
14:23:01 [zkoch]
+1
14:23:01 [Ian]
AdrianHB: I am ok to close issue as postponed until we have more use cases
14:23:02 [Ian]
+1
14:23:03 [jnormore]
+1
14:23:12 [Ian]
Issue 11
14:23:13 [Ian]
https://github.com/w3c/webpayments-method-identifiers/issues/11
14:23:46 [Ian]
zkoch: What I wanted to discuss earlier is that in the proposal we made 2 concrete proposals to change payment request API
14:24:04 [AdrianHB]
https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md
14:24:17 [Ian]
zkoch: I want to be sure people are ok with the changes
14:24:37 [Ian]
...we would now allow N > 1 instances of a payment method identifier
14:24:39 [Ian]
(IJ: +1)
14:24:54 [Ian]
...the second change is to modify payment details modifiers to enable per payment-method pricing
14:25:36 [Ian]
...matching algorithm is "first match"
14:25:43 [Ian]
..so most specific filters go first
14:25:47 [Ian]
IJ: +1
14:25:49 [nicktr]
q?
14:25:51 [adrianba]
+1
14:26:01 [AdrianHB]
+1 - but would like to see the spec text obviously
14:26:12 [maheshk]
+1
14:26:20 [dlongley]
if it works, sounds fine to me.
14:26:33 [nicktr]
q?
14:26:35 [manu]
+1 - if it works, sounds like a good approach.
14:26:36 [Ian]
nicktr: I hear consensus; please push forward, Zach
14:26:51 [Ian]
topic: payment method identifiers
14:27:06 [Ian]
https://github.com/w3c/webpayments/wiki/Agenda-20160818#pmi-notes
14:27:23 [Ian]
adrianhb: We don't have consensus yet on the proposal.
14:27:31 [Ian]
..the proposal distinguishes open v. proprietary
14:27:33 [Ian]
q+
14:27:38 [Ian]
...question was "why use URLs"
14:27:58 [Ian]
...we are back to the question of "what the requirements are" (for PMIs)
14:28:13 [Ian]
...the proposal says that the requirements are different for open v. proprietary
14:28:36 [Ian]
...concerns of some respected voices on the github repo is URL-as-identifier is an anti-pattern
14:29:15 [Ian]
...zkoch has said he wants to point to resources, but we don't know what they are yet.
14:29:16 [nicktr]
q?
14:29:18 [Ian]
ack me
14:29:36 [AdrianHB]
q = zkoch
14:29:41 [Ian]
IJ: also w3c v. other
14:29:43 [manu]
Ian: The open vs. proprietary is potentially a useful distinction. W3C controlled vs. other is a useful distinction.
14:29:44 [nicktr]
q?
14:30:32 [AdrianHB]
q+ zkoch
14:30:33 [manu]
Ian: Sometimes those axes overlap, but sometimes they don't, specifically there are some choices we may make because W3C is in a privileged position and can publish short strings. We may want to place other requirements to make sure other parties do something extra, whether the other parties are open or closed.
14:30:41 [AdrianHB]
q+ to make another (controversial) proposal - related to #11
14:31:02 [manu]
Ian: URLs for everyone but W3C - where are we optimizing, and are we doing so with the constituencies that we're identifying in mind, is W3C in a privileged position or not?
14:31:03 [nicktr]
q?
14:31:07 [nicktr]
ack zkoch
14:31:30 [Ian]
zkoch: Have been having discussions with lots of stakeholders.
14:31:45 [Ian]
...one useful thing to do is look at top 100 ecommerce sites and how they accept payments
14:32:19 [Ian]
...credit cards get us somewhere but there are other methods that other companies would like to see supported by payment request...so my comments are informed by those discussions.
14:32:43 [Ian]
...I agree with Tab Atkins that URLs as identifiers are problematic...but there are a number of things in payments that make URLs valuable despite the limitations.
14:32:52 [nicktr]
this report is in the public domain and might be a helpful view on the distribution and usage of different payment methods -< http://www.worldpay.com/global/insight/articles/2016-07/global-payment-report
14:32:53 [Ian]
...in particular given the use cases of the people we are talking to.
14:32:57 [Ian]
...the benefits include:
14:33:24 [manu]
q+ to ask if we're saying that payment method information (name, description, how to install, partners, etc.) are at the end of those URLs? Isn't this the key question?
14:33:28 [Ian]
(1) brands are very protective and also very busy....the web affords them what they need ... they have URLs, JS, IFrames...so they may ask "why is this new thing more useful"?
14:33:52 [Ian]
...one thing I want to remove from the obstacle list is "no process is required"...people can use existing origin-based security model
14:34:03 [Ian]
...and we can, in addition, put things at the ends of URLs to improve the user experience
14:34:18 [Ian]
...right now the spec says that if you don't match throw a false.
14:34:21 [manu]
+1 to use the identifier mechanism that the Web uses... which is the URL.
14:34:37 [Ian]
..but you could imagine that the browser does something useful like getting data about a payment method
14:34:42 [Ian]
...that can improve the use experience.
14:35:04 [dlongley]
+1 to what zkoch is saying about making it easier for people to do more decentralized innovation
14:35:10 [Ian]
...we have postponing the discussion of "what they point to" but I am hearing people may not wish to decouple them
14:35:28 [nicktr]
q?
14:35:33 [nicktr]
ack AdrianHB
14:35:33 [Zakim]
AdrianHB, you wanted to make another (controversial) proposal - related to #11
14:35:37 [Ian]
...we would have to make a decision knowing the anti-pattern exists, but I think the benefits outweigh the costs
14:35:41 [dlongley]
reminds me of the decision to allow URLs to fail (return 404) instead of forcing every link/document to be up to date in a centralized database
14:36:00 [Ian]
adrianhb: One thing based on what you said that I want to highlight....what the URLs point to depends largely on what payment apps look like.
14:36:28 [Ian]
...so I think this PMI discussion relates to payment apps and we can't make a decision about PMIs and what they point at until we have a better idea of what payment apps will look like.
14:36:50 [Ian]
...we can't decide on pointing at app or manifest or other until we have greater clarity about payment apps (and esp. how they are registered)
14:37:04 [Ian]
...I support using URLs but I think we need to prioritize what they point to.
14:37:22 [dlongley]
+1 to figure this out by furthering the payment apps spec and direction
14:37:35 [Ian]
AdrianHB: My controversial proposal is that instead of differentiating proprietary v open...we could have URLs for ALL payment methods EXCEPT cards.
14:37:51 [Ian]
...we have a bootstrapping problem and perhaps we should make basic card a string
14:37:54 [Ian]
q+ to ask about parsing cost
14:38:05 [Ian]
...and treat it as an exception...
14:38:50 [Ian]
...also regarding apps announcing support for card payments....and collecting card data...
14:39:07 [jnormore]
+1 to URL pointing to a manifest to improve user experience, agree that it needs to be informed by payment app registration though.
14:39:29 [dlongley]
+1 no, it's a bad idea
14:39:33 [Ian]
...the controversial piece of my proposal is that browsers determine who can do payments
14:39:44 [zkoch]
Same thing as before, I think this is a good question that we should discuss, but it’s a bit orthogonal to how we identify them
14:39:49 [Ian]
...browsers are well-positioned to evaluate whether apps are doing bad things
14:39:51 [manu]
I expect many formal objections if we say "only browsers can handle card payments"
14:40:02 [zkoch]
So would vote to bring this up as topic next call or a github issue :)
14:40:15 [dlongley]
if this group wants to specify good practices to help identify bad payment apps, that's another thing
14:40:19 [adamR]
q+
14:40:20 [nicktr]
q?
14:40:24 [Ian]
...summary - payment methods identified by URLs...basic card an exception...browsers curate card-supporting payment apps
14:40:24 [nicktr]
ack manu
14:40:24 [Zakim]
manu, you wanted to ask if we're saying that payment method information (name, description, how to install, partners, etc.) are at the end of those URLs? Isn't this the key
14:40:28 [Zakim]
... question?
14:40:38 [zkoch]
q+
14:41:26 [Ian]
manu: I think it makes sense to identify payment apps...but if we make a decision that there is no metadata associated with a PMI, then it makes sense to have strings in a registry
14:41:49 [nicktr]
q?
14:41:49 [zkoch]
Yes, +1
14:42:04 [Ian]
...is the main question whether we want machine-readable data?
14:43:02 [adrianba]
the idea that we want something located at the URL was the most significant reason for me switching my preference to URL
14:43:11 [AdrianHB]
q?
14:43:27 [dlongley]
+1 to adrianba
14:44:10 [AdrianHB]
+1 - I believe the group is in consensus we should use URLs and define a machine-readable resource that is at the end
14:44:20 [AdrianHB]
We must evaluate the cost of this though
14:44:20 [Ian]
IJ: What ;is the cost of parsing "small set of strings or URLs"
14:44:30 [Ian]
zkoch: Not a problem.
14:44:44 [Ian]
...ok to say simple strings for w3c-published identifiers
14:44:47 [dlongley]
+1 to zkoch and AdrianHB
14:44:47 [Ian]
..and URLs for other things
14:44:48 [Ian]
q?
14:44:50 [Ian]
ack me
14:44:50 [Zakim]
Ian, you wanted to ask about parsing cost
14:44:51 [nicktr]
q?
14:44:52 [adrianba]
I can live with that but it isn't my preference
14:45:21 [adrianba]
s/that/using strings instead of URNs/
14:45:25 [Ian]
adamR: The choice of URNs isn't just so that we can say "All URIs"...other orgs may want to use URN space
14:45:31 [zkoch]
That’s a fair points
14:45:36 [zkoch]
s/points/point
14:45:40 [dlongley]
+1 to adamR
14:45:41 [Ian]
...if they want an identifier they don't want dereferenced, they too could use URNs
14:46:06 [Ian]
AdamR: Regarding browser curation of card-enabled payment apps gives me heartache. Whitelisting by browsers is antithetical to the open web
14:46:10 [Ian]
q?
14:46:11 [manu]
Note that we have browsers curating lists of malware providers, I'd expect this to be the same.
14:46:12 [Ian]
ack ad
14:46:31 [Ian]
nicktr: I am also pretty uncomfortable making browsers more privileged than they need to be
14:46:31 [nicktr]
ack zkoch
14:46:51 [Ian]
zkoch: I largely agree with Manu's characterization of the problem...whether something machine readable will live at the end of the URL
14:47:03 [Ian]
...one thing that I propose is that there is not a dependency on the payment app spec
14:47:11 [dlongley]
+1 to manu, but i don't want to see a situation where open payment methods are somehow a fundamentally worse experience for users than proprietary ones
14:47:19 [Ian]
...I think we can write a proposal that both payment request and payment apps depend on
14:47:23 [Ian]
...we define what lives at the end of this URL
14:47:28 [dlongley]
which could arise depending on how app policing occurs.
14:47:31 [Ian]
...could be used by registration spec and by browsers as well
14:47:32 [manu]
+1 to define the manifest
14:47:51 [nicktr]
q?
14:47:52 [Ian]
q+
14:47:54 [adrianba]
+1
14:48:46 [manu]
q+ to note that he's hearing consensus - use URLs, define a manifest... then we can come back and see if we've made a horrible mistake... we're not in CR, we can try this out.
14:49:15 [nicktr]
what's in the manifest?
14:49:26 [AdrianHB]
q?
14:49:52 [Ian]
IJ: Payment app spec talks about identifying payment apps....
14:49:57 [manu]
NickTR, name, description, image - we'll have to decide that.
14:50:07 [dlongley]
identify by URL and fetch URL to get machine readable data is a well known pattern, may work in a variety of places.
14:50:10 [AdrianHB]
q+ to propose we resolve what the payment method identifier will not be to make progress
14:50:12 [Ian]
ack me
14:50:18 [nicktr]
manu, metadate for the payment method or the app?
14:50:29 [nicktr]
s/metadate/metadata/
14:50:38 [dezell]
Several related/unrelated points (not taking airtime):
14:50:38 [dezell]
1) most in-app applications merchants create that I've seen use ACH, not cards.
14:50:38 [dezell]
2) I have heard criticism of the Payment Method Identifiers not reusing the codes used in ISO20022. So if URI are always followable, an easy (provable) translation to/from ISO would be a big help is assuaging concerns, and if that method doesn't require following (i.e. "machine readable") that might have lower overhead.
14:50:38 [dezell]
3) We (NACS) are not in favor of trading contractor lock-in (for merchants) for browser lock-in.
14:50:41 [manu]
nicktr - why can't it be both?
14:50:42 [nicktr]
q?
14:50:44 [adrianba]
+1 on not blocking - if the payment apps proposal has requirements of PMIs then they should be explicitly stated, which was the feedback I gave at the F2F
14:50:57 [Ian]
zkoch: I think we can separate this out
14:51:43 [Ian]
zkoch: I still stand by the proposal to distinguish proprietary from open...and app and payment method.
14:52:49 [nicktr]
q?
14:53:02 [zkoch]
Not always a 1:1 mapping, just most of the time
14:53:03 [Ian]
IJ: I believe that blurring payment method and payment app will be a source of problem
14:53:24 [Ian]
AdrianHB: I agree that is a point of contention
14:54:19 [Ian]
...and may have pragmatic consequences like using origin for security / etc.
14:54:26 [ShaneM]
present+ ShaneM
14:54:26 [Ian]
zkoch: Happy to have the conversation separately
14:54:39 [Ian]
..and understand the exceptions (in the real world)
14:55:06 [nicktr]
q?
14:55:23 [Ian]
adrianhb:I suggest we have the discussion in the payment app task force
14:55:34 [Ian]
zkoch: Meanwhile, let's see if we can independently define "what's at the end of the URL"
14:55:35 [Ian]
q+
14:55:59 [manu]
ack manu
14:55:59 [Zakim]
manu, you wanted to note that he's hearing consensus - use URLs, define a manifest... then we can come back and see if we've made a horrible mistake... we're not in CR, we can try
14:56:00 [Ian]
zakim, close the queue
14:56:02 [Zakim]
... this out.
14:56:02 [Zakim]
ok, Ian, the speaker queue is closed
14:56:08 [Ian]
manu: I am hearing consensus to use URLs
14:56:23 [Ian]
...the only thing we need to see is the proposal for what is at the end
14:56:35 [dlongley]
+1 manu
14:56:37 [Ian]
ack AdrianHB
14:56:37 [Zakim]
AdrianHB, you wanted to propose we resolve what the payment method identifier will not be to make progress
14:56:40 [ShaneM]
+1 to developing a spec for what is at the end of a payment URL
14:56:50 [Ian]
adrianhb: +1 .... we need to resolve what will be at the end.
14:57:00 [Ian]
...I think that's impacted by the payment apps work
14:57:39 [Ian]
PROPOSAL: W3C can mind short strings for some payment methods, otherwise URLs (which includes URNs)
14:57:47 [manu]
-1 vague
14:57:48 [adrianba]
-1
14:57:51 [dlongley]
a URN isn't a URL :)
14:57:57 [Ian]
AdrianHB: URNs provide context outside of the browser
14:58:56 [manu]
Note that my -1 was that I don't have a strong opinion of URN vs. short string UNLESS we take AdamR's comments into account (other organizations may want to use URNs)
14:59:27 [Ian]
IJ: We could also do short strings now and then mint URNs separately if we want
14:59:37 [ShaneM]
dlongley: wow - them's fightin' words
14:59:42 [manu]
I also note that this whole debate is only because serving up HTTP URLs don't scale for smaller organizations. This whole issue would be taken care of if we were using something like IPFS :P
14:59:56 [manu]
and we wouldn't be having this discussion... we'd be using URLs for everything.
15:00:04 [manu]
(IPFS URLs)
15:00:12 [Ian]
Topic: TPAC Agenda
15:00:20 [Ian]
nicktr: Send us in your items
15:00:25 [Ian]
Topic: CFC extension
15:00:38 [Ian]
nicktr: Now 25 August based on Manu input
15:00:41 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/08/18-wpwg-minutes.html Ian
15:00:51 [nicktr]
Manu's blog -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0077.html
15:00:55 [ShaneM]
And please vote (editor's hat)
15:06:06 [Max]
Max has joined #wpwg
15:07:26 [ShaneM]
rrsagent, make minutes
15:07:26 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/08/18-wpwg-minutes.html ShaneM
17:26:05 [Zakim]
Zakim has left #wpwg
18:33:58 [zkoch]
zkoch has joined #wpwg
19:17:05 [sam]
sam has joined #wpwg
19:30:13 [zkoch]
zkoch has joined #wpwg
20:06:50 [adamlake]
adamlake has joined #wpwg
21:02:40 [zkoch]
zkoch has joined #wpwg
21:37:46 [adamlake]
adamlake has joined #wpwg
22:36:29 [sam]
sam has joined #wpwg
23:03:51 [zkoch]
zkoch has joined #wpwg
23:23:04 [MikeSmith]
MikeSmith has left #wpwg