23:41:12 RRSAgent has joined #wpwg 23:41:12 logging to http://www.w3.org/2015/10/29-wpwg-irc 23:41:15 Zakim has joined #wpwg 23:41:34 Present+ ShaneM 23:41:42 zakim, who is here? 23:41:42 Present: ShaneM 23:41:43 On IRC I see RRSAgent, zephyr, ShaneM, padler, Jiangtao, dezell, shepazu, MattSaxon, m4nu, sangjo_, slightlyoff, schuki, wseltzer, dwim_, Ian, adrianba 23:41:49 present+ zephyr, Ian 23:41:53 RRSAgent, this meeting goes past midnight 23:41:53 I'm logging. I don't understand 'this meeting goes past midnight', ShaneM. Try /msg RRSAgent help 23:41:54 present+ padler 23:41:55 rrsagent, this meeting spans midnight 23:42:04 zkoch has joined #wpwg 23:42:06 Regrets Katie 23:44:36 Rouslan has joined #wpwg 23:44:53 Present+ Rouslan Solomakhin 23:45:19 giuseppe has joined #wpwg 23:46:13 nick_s has joined #wpwg 23:46:44 wonsuk has joined #wpwg 23:47:58 sam has joined #wpwg 23:50:52 present+ Jiangtao 23:52:21 dveditz has joined #wpwg 23:53:51 jungkees has joined #wpwg 23:54:30 jmr has joined #wpwg 23:54:52 lbolstad has joined #wpwg 23:55:26 zkoch has joined #wpwg 00:00:55 kura has joined #wpwg 00:01:41 zkoch has joined #wpwg 00:04:47 zkoch has joined #wpwg 00:05:32 scribe: Ian 00:05:38 agenda: https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015 00:05:44 Meeting: Web Payments Working Group 00:06:24 rbarnes has joined #wpwg 00:06:29 nick_s has joined #wpwg 00:07:39 zkoch has joined #wpwg 00:07:50 nick_s has joined #wpwg 00:08:04 https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Oct2015#Friday.2C_30_October 00:08:10 barryleiba has joined #wpwg 00:08:13 m4nu has joined #wpwg 00:08:16 kiyoung has joined #wpwg 00:08:19 present+ BarryLeiba 00:08:24 present+ rbarnes 00:08:32 present+ Nick_TelfordReed 00:08:34 jheuer has joined #wpwg 00:08:44 present+ manu 00:08:52 scribe: manu 00:09:01 Topic: Agenda Bashing 00:09:05 CyrilV has joined #wpwg 00:09:07 mkwst has joined #wpwg 00:09:16 Present+ Cyril Vignet 00:09:22 Nick: Looking at revised agenda - look at registration, other changes towards end of day 00:09:35 Nick: Straw poll - who needs to leave before end of day 00:09:52 Only one person raises their hand - MATT 00:09:57 hwlee has joined #wpwg 00:10:08 wonsuk has left #wpwg 00:10:23 q+ 00:10:36 Nick: Move some things around at end of day, how we work, give ourselves some time - more flows work maybe, an hour where we can dive into other aspects - give ourselves a bit of space in the agenda, use last hour to try and close off initial plan of attack. 00:10:37 annbass has joined #wpwg 00:10:43 ack adr 00:11:28 q+ 00:11:31 +q 00:11:31 Adrian: I think it's a good outline for the day - a bit concerned about how we'll consume the time dedicated time for flows. I think that work we did yesterday was useful starting point to get people to try to represent flows, but I don't know if having this many people having to collaborate on whiteboard added a lot of value. 00:12:03 Adrian: if we try to do what we did yesterday, not the best use of our time. Flows are going to be very useful for our work. I want to talk about how we work on them moving forward, identify some people that will work on that. 00:12:17 Nick: Matt has already volunteered to do that work 00:12:34 Nick: It would be good to leave w/ as many names as possible volunteering at end of day 00:13:01 Nick: There was a proposal to split up, would rather not do that, may be hard to get all stuff back together again 00:13:24 Nick: We have other folks from W3C - that's just trying to get lessons learned, collective wisdom together. 00:13:27 topic: Security Considerations 00:13:28 q- 00:13:30 Nick: Moving on to security considerations 00:13:34 present+ MattSaxon 00:14:14 nicktr has joined #wpwg 00:14:18 bhill2 has joined #wpwg 00:14:19 q? 00:14:21 Zach: If we left here w/ a shared understanding of two proposals on table, look at flows, discover whether or not flows fit into proposals - far away from people understanding proposals on table - everyone is clear on what's proposed. We can apply flows to proposals. 00:14:22 - 00:14:23 present+ bhill2 00:14:28 present+ 00:14:31 q- matt 00:14:33 MattSaxon: Echoing what was said previously 00:14:40 jyrossi has joined #wpwg 00:15:05 present+ nicktr 00:15:23 kris has joined #wpwg 00:15:23 JimB has joined #wpwg 00:15:40 Brad: We are here to answer questions and free form discussion - we are not aware of specific proposals - share a few thoughts to start the discussion. You are brave in here - security veterans in security space - web payments has to tackle 3 of the most difficult things our group ends up trying to avoid / shutdown as necessary conditions of making your work successful. 00:15:41 present+ Adrian_Bateman 00:15:54 present+ jyrossi 00:16:09 (Brad Hill, Facebook (and formerly PayPal)) 00:16:14 Brad: Difficulty of doing browser-mediated crypto protocols, difficulty of trusted user interface, and difficulty of cross-origin persistent state and identifiers in a trustworthy manner, those seem central to your usecases. 00:16:22 Brad: Thinking about that, you have a lot of challenges ahead. 00:17:05 Brad: On browser-mediated crypto - keep it as small as possible - think about long tail of adoption - very large audience, update of browser cycles was slow. A year ago, browsers were fastest movers - chrome updates every week - hits 99% of users - browsers move fast. 00:18:13 Brad: Now that I'm at Facebook, I see that's only true for the wealthiest parts of the world. There are hundreds of millions that have old android phones, no appstore, no updates, no space to update. Telling those populations to upgrade is like asking them to buy a car to fix a bug in their control system. 00:19:08 brad: We can't rev quickly - emerging world, coming on to web - lots of advantages to OAuth - server-to-server, decentralized - economic conditions lead to natural oligopoligies - but when upgrades happen, migration can take a month. Counterparty has to fix it. 00:19:37 q+ to talk about the bottom quartile of net worth in the world and the Bill and Melinda Gates Foundation - they fit Brads conditions for "hard to upgrade" 00:19:43 Re: Brad's statement that everyone updates their browsers quickly ... this does not happen quickly in big enterprise. Example: Boeing often has to wait several years to update, because A) it's expensive to update ~150,000 machines; B) internal applications are dependent on BrowserX (in violation of internal standards) 00:19:58 MattPisut has joined #wpwg 00:20:05 q+ 00:20:18 Also, I -- as an average user -- am notoriously slow to update anything 00:20:20 brad: supporting and negotiating multiple protocols over a number of years is difficult, keep it as simple as possible, avoid upgrades, balance natural tendency to have perfectly decentralized world - maintenance costs are high for decentralized - some costs tend to favor some folks. 00:20:21 q+ to ask about security of polyfills 00:20:26 ack m4nu 00:20:26 m4nu, you wanted to talk about the bottom quartile of net worth in the world and the Bill and Melinda Gates Foundation - they fit Brads conditions for "hard to upgrade" 00:21:08 m4nu: Some of the work this group is doing could have dramatic impact on developing economies....payments through mobile phones are a big part of their lives 00:21:41 ...we've been chatting with Bill and Melinda Gates Foundation also; they have a payments initiative to improve ecosystem worldwide 00:21:44 dezell has joined #wpwg 00:22:25 ...there are a number of tensions which direction to go in. For example, I know we want to get things in browsers quickly...but we may want to polyfill or deploy more in the cloud and make the browser surface minimally 00:22:38 ...are there a set of API best practices from the security community that we could look at? 00:22:53 q? 00:23:03 bhill2: We don't have a security API best practices doc. 00:23:13 ...that would be a great thing to have if it could be produced and kept up-to-date 00:23:15 q? 00:23:17 q+ 00:23:27 brad: We don't have a security API best practices document, it would be a great thing to have - but it's a collection of folk wisdom and papers, things presented at conferences, no tidy summary that I can point someone to 00:24:33 ???: We don't have a document to point to - the core of what you were getting at was pretty simple, only enshrine in the browser the things you think are going to be constant for a while - we have many payment systems, don't make the details inherent in the browser. That frustrates attention, I think that's the central security tension. 00:24:43 q- 00:24:47 m4nu: me :) 00:24:53 ack shepazu 00:24:53 shepazu, you wanted to ask about security of polyfills 00:24:58 (richard barnes, mozilla) 00:25:28 Doug: Along the same lines, there was a suggestion of making sure that what we design is polyfillable - but then I heard tension around concern that polyfills expose users to security risks - is polyfilling web payment api a good or terrible idea? 00:25:49 s/???/rbarnes/ 00:25:54 Present+ Richard_Barnes 00:26:13 Present+ dezell 00:26:16 zakim who is here? 00:26:30 Present+ zkoch 00:26:44 present+ shepazu 00:26:54 present+ IanJacobs 00:26:55 AdrianHB has joined #wpwg 00:27:13 bhill2' 00:27:15 q+ to raise awareness on b2b use cases and security/trust mechanics 00:27:17 brad: SSL should show a lock - lots of history there - do we show URL bar at all, is it green, something as simple as information - secure connection, wildly controversial approaches - I think it boils down to some heart that you have to depend on in browser - crypto properties, sandboxing, what does browser mediate - keep them as small as possible, model them as properties that you depend on, 00:27:17 what they are and what they do. 00:27:30 bhill2: "focus on properties you depend on" 00:27:30 zakim, who is here? 00:27:30 Present: ShaneM, zephyr, Ian, padler, Rouslan, Solomakhin, Jiangtao, BarryLeiba, rbarnes, Nick_TelfordReed, manu, Cyril, Vignet, MattSaxon, bhill2, nicktr, Adrian_Bateman, jyrossi, 00:27:34 q+ to comment on relative security. 00:27:34 ... Richard_Barnes, dezell, zkoch, shepazu, IanJacobs 00:27:34 On IRC I see AdrianHB, dezell, MattPisut, JimB, kris, jyrossi, bhill2, nicktr, annbass, hwlee, mkwst, CyrilV, jheuer, kiyoung, m4nu, barryleiba, nick_s, zkoch, rbarnes, kura, 00:27:34 ... lbolstad, jmr, jungkees, dveditz, sam, giuseppe, Rouslan, Zakim, RRSAgent, zephyr, ShaneM, padler, Jiangtao, shepazu, MattSaxon, sangjo, slightlyoff, schuki, wseltzer, dwim_, 00:27:34 ... Ian, adrianba 00:27:43 rrsagent, set logs public 00:27:55 rrsagent, make minutes 00:27:55 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 00:27:58 brad: Polyfills can help you experiment, a strategy in FIDO - great that API design allowed me to design and play around w/ technology, then you can figure out what should be in the browser - you have an adoption curve 00:28:03 present- Richard_Barnes 00:28:37 q? 00:28:46 Doug: Are you suggesting polyfills for testing or deployment. 00:28:51 present+ wseltzer 00:29:01 brad: Difficult to answer concretely, it's a tradeoff 00:29:05 present+ giuseppe 00:29:11 ack padler 00:29:11 padler, you wanted to raise awareness on b2b use cases and security/trust mechanics 00:29:14 ack padler 00:29:21 pat: balance of trust mechanics are great, thank you for commenting on that. 00:29:29 present+ Ann Bassetti 00:29:46 present+ MattSaxon 00:30:31 pat: We are suggesting individuals operating web payments, but small businesses are also slow to adopt. At the US Fed, we're looking at B2B payments, they're offline checks, 3 day lag, getting trust mechanics right, getting updates to small businesses, business to business is important as well - we should emphasize business-to-business case. That's where people are losing money. 00:30:50 pat: Any thoughts with work going on at W3C - any B2B security aspects happening at W3C vs. consumer side focus that we have now. 00:30:57 kiyoung has joined #wpwg 00:31:58 brad: No particular thoughts on that - those patterns are less challenging. Small businesses have software, get most use of tech before upgrade, but you have less challenges there than the consumer space. Established body of work OAuth, OpenID Connect, other point-to-point protocols, easier to model w/ incentives. Unintentional interactions are harder w/ consumers. 00:32:18 q? 00:32:41 pat: How do we figure out a way to incent small businesses to update - it's not easy to upgrade them, we need something quick, robust, secure. 00:33:55 brad: Google Checkout in google shopping card was a great example - get users and merchants onboard as quickly as possible, but you want secure signed shopping cart that's harder to attack, you can build complicated protocol w/ lots of options - makes everything more brittle at low-end. So you build two protocols - unsigned protocol - simple... signed protocol is mroe complicated - we'll charge 00:33:56 10 basis to use one and 5 to use the other - we'll share risk differential w/ you for pricing structure. 00:34:12 brad: You can decide as a merchant to do what makes sense to you with the risk profile that makes sense to you. 00:34:16 q? 00:34:39 ack de 00:34:39 dezell, you wanted to comment on relative security. 00:34:41 s/card/cart 00:34:42 brad: Building multiple protocols is better than building one protocol w/ negotiation and options - different incentives is a more easy system to secure. 00:34:42 ack dezell 00:35:04 dezell: Thank you for coming and speaking to us about this. Difference in security between built-in and polyfill - in my daily work, PCI standards 00:35:24 Mek has joined #wpwg 00:35:36 q+ to ask about PCI 00:35:54 q- 00:35:56 dezell: requires a lot of human engineering, you have to enforce all of this stuff, etc - but compared to that, relative risk implied by a polyfill is pretty modest, but compared to PCI, they're almost the same. I think we're going to try to be as flexible as possible and careful as possible. Any exploit would be bad for us. 00:36:03 q? 00:36:31 nicktr: So, there are three things you wanted to talk about brad... 00:37:56 brad: One thing we're talking about is same-origin policy, sounds simple, but it's complex. Long history of problems on Web about that - poking holes in same-origin to persist identifiers and state changes can happen is something we like to avoid. We want to hold a hard line to same origin. To the extent that you can do tokenization and tailor individual transactions to each origin, great approach 00:37:56 to follow, we don't have good solutions for this stuff. 00:38:07 brad: Biggest tensions I've seen recently is that we're competing w/ the app platform. 00:39:15 brad: We're losing to apps - that narrative - there is a looser security model in apps - that's true, but web has its own strengths - we don't want to compete with every feature of app platforms. In an app world, you have discoverability, you have to find app, you have to install it, update cycle, it has to be approved, sometimes app store protects users, sometimes it keeps competitors out. 00:39:20 q+ to ask for thoughts on SOP with payment instruments 00:39:36 brad: Web has other strengths, immediate deploy, no permissions necessary to deploy, etc. 00:39:36 yaso has joined #wpwg 00:40:12 brad: The first principle of the Web is you can do most anything you want - people interact w/ many different security principles, no sense of reputable vs. unreputable sites. 00:40:19 q? 00:40:25 q+ 00:40:29 ack AdrianHB 00:40:29 AdrianHB, you wanted to ask for thoughts on SOP with payment instruments 00:40:57 AdrianHB: I have a question about same origin and multi site payment 00:41:04 q+ to talk ab out browser-mediation and SOP 00:41:07 q+ to talk about sop and a web server 00:41:22 AdrianHB: Do we have to disregard same origin? 00:42:17 s/principles/principals/ 00:42:33 brad: There are design patterns for this - get token from 3rd party, do one off transactions, reveal persistent identifiers - that's how paypal works today. Payment instrument - one off transactions across origins, principles, some are more difficult to work w/ offline. Third party can see everything you're doing, you have to trust them, you don't have to trust someone w/ payment instrument 00:42:33 information. Can you get away with that, maybe. 00:42:43 q? 00:42:49 brad: There are design patterns around this stuff - privacy preserving things. 00:43:06 AdrianHB: Is the same origin policy about privacy? not tracking? 00:43:25 AdrianHB: Or is same origin about trusting the payment instrument because there is some sort of origin? 00:43:59 hober has joined #wpwg 00:44:20 brad: it's about the fact that user is interacting w/ different origins - you ahve to protect user by making sure that ... in an app, everything in the app is created by app... on web, you have stuff coming from all different directions - it's not just about privacy, it's about maintaining integrity, security, privacy, etc. 00:44:42 brad: We are trying to ensure that every product on every shelf is not able to get data from you, for example. 00:44:53 q? 00:45:23 ack Ian 00:45:32 brad: Build multiple protocols, enable people to choose - don't build one size fits all protocol, if you want bitcoin protocol, build that, then build something else that works w/ centralized provider, don't build a swiss army knive, have a spoon, knife, and a fork. 00:45:59 Ian: If we make it easier to pay, we make it riskier for phising, an easier to pay world - what are the emerging ways to protect consumers from phishing. 00:46:20 Dan Veditz 00:47:00 JimB has joined #wpwg 00:47:12 DanVeditz: One of the ways we've worked w/ get user media, you can have iframe, you can turn on camera from iframe - we've tried saying "this site is trying to xyz". So when you create your APIs, make sure users understand who is doing it. 00:47:24 Ian: How about getting greater assurances of who you are dealing with. 00:47:26 http://news.yahoo.com/video/yahoo-trust-unconference-security-ux-161037378.html 00:48:04 q? 00:48:16 technically she’s a PM! yay PMs! :) 00:48:56 horace has joined #wpwg 00:48:58 q+ 00:49:34 q+ to say payment technologies often have their own ways to protect their processes - where is the responsibilty of browsers, wallets, etc? Abstractions wrapping other security domains 00:49:38 brad: That's hard - talk at yahoo trust unconference - permissions systems and how to ask for permission - one of the best things I've seen - what is it like to grant permissions - she has lots of good things to say on topic. On emerging technologies - big data systems, behavioral analysis, knock out spammers, prevent clickjacking, that's what payment providers do - analyze all patterns, payment 00:49:39 in sapporo, then payment in nairobi, that's probably not you. browsers building reputation based systems to grant permissions, maybe browsers keep track of site reputation, we might stop people from using camera on that sites. 00:49:53 q? 00:50:06 q+ on heuristics and non-deterministic systems vs user learning 00:50:11 zakim, close the queue 00:50:11 ok, Ian, the speaker queue is closed 00:50:29 brad: Or, if you are a heavy user of a site, allow it to have more storage than others. Thinking about how those kinds of things can be in the toolkit are interesting - how to crowdsource reputation, streamline permissions experience, streamline authentication experience w/ sites you use and trust a lot 00:50:36 ack m4nu 00:50:36 m4nu, you wanted to talk ab out browser-mediation and SOP 00:50:37 ack m4nu 00:50:53 m4nu: when it comes to SOP and browser mediation I think there's a lot of confusion and what it means for APIs. 00:51:21 ...that has resulted in people at least in the web payments group thinking that there's a big blocker that we can't do payments 00:51:35 ...but browser mediation is fine way to do payments 00:51:45 ..where do you think it's ok for the browser to mediate things like payments? 00:52:14 ...there seem to be two areas of concern: (1) privacy [linkability, trackability] and (2) security (not dealing with malicious sites 00:52:26 ...I think it's useful to discuss SOP in at least those two ways 00:52:37 ...I think payments not in conflict with SOP 00:52:52 ..when it comes to identity and traceability, I think that's more of an issue with payments since merchants want data 00:53:52 ...in general I'd like to hear your thoughts .... are there other areas that the group should be looking at using the SOP lens to figure out whether or not we are deviating from the basic SOP model 00:54:24 Q? 00:54:38 DanVeditz: I don't worry as much about same origin policy, send API out for review. 00:55:31 rbarnes: There is a degree of review around same origin policy - pool of resources that get handed out to any origin that's within a proper realm, there will be some cross-origin stuff - we need to make sure that there is consent around that. 00:56:02 there is inherent in what this group wants some new cross-origin stuff 00:56:12 ack dezell 00:56:12 dezell, you wanted to talk about sop and a web server 00:56:13 DanVeditz: There are ways for sites to violate same origin policy if they communicate - for a payemtn processor there will be ways to violate same origin - what are privacy considerations, you can't just fall back on SOP, you have to think through that. 00:56:13 q? 00:57:51 dezell: Part of my difficulty in SOP, it sounds like it's a one size fits all problems approach - five years ago, I built a browser system that was PCI approved - opera had ability to sign javascript, my responsibility to send that out - if I had something complicated, I could throw this out to a PHP site locally, doesn't take much squinting to view it as a Web Worker - that kind of layering 00:57:51 possible in security model - big worry is page w/ JS on it - idea that all JS used comes from that page. 00:58:01 rbarnes: "Labeled origin policy" 00:58:17 q? 00:58:26 rbarnes: SOP is a starting point - there are lots of creative usage on that - cross origin - what we care in this group - make clear identification on what comes from that origin. 00:58:55 ack me 00:58:58 DanVeditz: That's what you're building w/ an API - if that does stuff, as long as you defin that stuff, it's the trusted UA doing that, it can violate SOP all it wants as much as it makes sense to do so. 00:59:03 in other words: SOP is a misnomer 00:59:34 maybe they shouldn’t have been using the PANs for that in the first place ;) 00:59:45 nicktr: Yes, merchants want to be able to track people - schemes are tokenizing transactions - that's caused problems all over payments industry, payments industry can't track - so now payments instruments are providing payment account reference - so that's a tracking cookie. 01:00:23 nicktr: We should have PCI DSS requirements coming in here - worry at browser vendors PA DSS - I think we're getting very close to browsers getting into PCI scope. 01:00:34 q? 01:00:41 q+ 01:00:43 nicktr: Thank you Brad, would Facebook like to join 01:00:43 ack jheuer 01:00:43 jheuer, you wanted to say payment technologies often have their own ways to protect their processes - where is the responsibilty of browsers, wallets, etc? Abstractions wrapping 01:00:46 brad: no comment :) 01:00:47 ... other security domains 01:01:13 you sure wendy? 01:01:20 queue=nick_s 01:01:32 i’ll just do my best impression of you 01:02:09 jheuer: If we're making payment mechanism - broad approach to security - need to find a way to embrace some of this stuff - we want to be clear about SOP and API and limits. 01:02:13 ack wseltzer 01:02:13 wseltzer, you wanted to comment on heuristics and non-deterministic systems vs user learning 01:03:26 nick_s: Interesting session, thank you brad - lots of desire here to look at PCI and how it applies here - credit card not tokenized payments are big in some nations, but not in others. We may not want the concern spec w/ that, that seems to be a worry of payment instrument - PCI is very much a function of credit/debit - don't know if right approach is to write spec to specific security model - 01:03:26 we want something secure regardless of instrument. 01:03:31 rrsagent, make minutes 01:03:31 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 01:03:36 thanks wendy! 01:03:54 nick: We're out of time, break for 15 minutes, back at 20 past 10, thanks to webappsec for coming along. 01:03:58 any time 01:04:07 barryleiba has left #wpwg 01:04:56 rrsagent, draft minutes 01:04:56 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html m4nu 01:05:14 wonsuk has joined #wpwg 01:09:31 rbarnes has joined #wpwg 01:18:55 bhill2 has joined #wpwg 01:23:47 lbolstad has joined #wpwg 01:24:31 dhe has joined #wpwg 01:29:26 Ryladog has joined #wpwg 01:30:23 mnot has joined #wpwg 01:33:11 bhill2 has joined #wpwg 01:35:15 kiyoung_ has joined #wpwg 01:35:24 zkoch has joined #wpwg 01:35:27 AdrianHB has joined #wpwg 01:35:56 rbarnes has joined #wpwg 01:36:02 topic: Flows 01:36:08 scribe: Ian 01:36:18 Rouslan has joined #wpwg 01:36:34 MattS: I'd like to hear from people about the approach to diagramming the flows, who wants to be involved 01:36:52 Present+ Katie Haritos-Shea 01:37:04 nick_s has joined #wpwg 01:37:07 (Display of yesterday's flow now in UML) 01:38:00 (Display of google proposal with 3DS) 01:38:08 (display of the community group proposal) 01:38:09 padler has joined #wpwg 01:38:19 q? 01:38:33 MattS: Both proposals support 3DS flow 01:38:47 q? 01:38:51 ....that's my conclusion by working through the diagrams 01:38:52 Laurent has joined #wpwg 01:39:17 Diagrams done with PlantUML 01:39:42 ...very simple text-based tool...free...hosted in MS Word 01:40:31 ...there are web-based versions as well such as web sequence diagrams 01:40:44 ...there were some subtle changes between tools but only subtle 01:40:53 q+ to note that PlantUML generates SVG! 01:40:58 zakim, open the queue 01:40:58 ok, Ian, the speaker queue is open 01:41:02 q+ to note that PlantUML generates SVG! 01:41:06 AdrianHB: Can we check the text source into github? 01:41:09 ack ShaneM 01:41:09 ShaneM, you wanted to note that PlantUML generates SVG! 01:41:22 +1 for a UML tool that allows us to store our data as text in documents on GitHub 01:42:03 Volunteers: 01:42:05 * Pat 01:42:07 * Jean-Yves 01:42:08 * Laurent 01:42:11 * Manu 01:42:12 * Kris 01:42:19 q+ to define what our objectives are for this group 01:42:21 * Cyril 01:43:05 q+ to talk about how 01:43:09 ack AdrianHB 01:43:09 AdrianHB, you wanted to define what our objectives are for this group 01:43:26 AdrianHB: I propose that this set of people work together (E.g., as a task force) but that we clearly state what the goals are. 01:43:37 ...e.g., document real-world flows to test our proposals against. 01:43:55 q- 01:43:56 MattS: I would like to understand the prioritized list of flows we should be creating 01:44:43 ack adrianba 01:44:43 adrianba, you wanted to talk about how 01:44:43 ack Adrianba 01:44:59 adrianba: I caution against making something too formal at this point. E.g., not necessary to create task forces in any formal sense. 01:45:28 ...it's fine for us to give a group of volunteers an action to work together how they want to work together on putting together a set of flows that they believe capture a significant set of flows we care about, and bring them back to the WG for review. 01:45:50 ...I was happy to volunteer for this but I think many have volunteered already and efficiency might go done. 01:46:01 ...so I'm happy for them to figure out together how to do their work. 01:46:23 AdrianHB: I will also talk to Mountie as well 01:46:39 q? 01:46:48 ACTION: MattSaxon to lead discussion among volunteers about creating flows and diagrams 01:46:57 Topic: Registration 01:47:11 annbass has joined #wpwg 01:47:31 wonsuk has joined #wpwg 01:47:31 My website-based instrument registration thoughts: https://goo.gl/656sby 01:47:33 CyrilV_ has joined #wpwg 01:48:53 q+ to talk about the types of registration 01:49:03 q? 01:49:38 Rouslan: I am thinking there will be at least 2 types of payment instruments...some will be bound to the OS; some will be other web sites like paypal.com 01:50:01 ...for the Web sites, once you tell the browser that they are there, there are 2 ways to register; 01:50:07 ...javascript API or manifest 01:50:18 ...for the javascript API, paypal.com would call to register themselves. 01:50:36 q+ to say that we may not want to parameterize in that way - prefer payment method and options 01:51:03 q+ 01:51:08 ...data includes URL where user should navigate when they select the payment instrument 01:51:12 jyrossi has joined #wpwg 01:51:31 ...second approach is manifest (which resides on paypal.com) 01:52:05 ..manifest format (from w3c) is used to specify things like desktop shortcut or home screen launcher 01:52:11 q? 01:52:17 q+ to discuss preloaded PIs (Apple/Android Pay) 01:52:23 rbarnes: what is payment request handler URI? 01:53:20 Rouslan: When merchant calls payment request, the browser would overlay a modal window atop the merchant site ... the page would show the URL and use some API that we define here to do something like call navigator.getPaymentRequest 01:53:56 rbarnes: This URL is effectively a Web page that you would open in this overlay once payment instrument selected and communication would take place through something like a POST message. 01:54:08 Rouslan: POST message or javasript or series of events (but might be too much freedom) 01:54:19 ...some security folks have suggested we make it as small as possible 01:54:26 q+ 01:54:33 q? 01:54:39 ...and when vulnerability is found, sites can upgrade quicker than browser updates 01:55:01 q+ 01:55:11 ...you suggested WebRTC style of API where the user agent provides a pipe between sites 01:55:33 rbarnes: I think that's sort of what you are proposing here but the js of the payment service provider is in the page 01:55:43 ..it's not clear to me you will have UX 01:55:50 ...maybe starting with HTML 01:56:04 ...having HTML visible entry point may be overkill...we need to do some more flows to figure that out. 01:56:06 ack adrianba 01:56:06 adrianba, you wanted to talk about the types of registration 01:56:28 adrianba: I want to take a step back a second...the topic was "registration" but I heard yesterday several scenarios for registration that are not necessarily this. 01:56:39 q? 01:56:42 q+ to ask about calls to local apps or OS functionality? 01:56:55 ...one scenario I heard yesterday was "registration of a particular payment instrument service" 01:57:18 ...I heard another scenario which was "I log into my online bank site and my bank wants to provision my visa card with that bank into the wallet that is on my device" 01:58:00 ...I heard another scenario which was that some people may not want to tie the payment API to a browser-provided wallet, they want to have a cloud-hosted wallet (or some other service that provides access to payment instrument providers) 01:58:26 ...I don't know if there are other scenarios but I feel we need to enumerate them and as a WG we care about solving for, and whether there is relative clarity 01:58:43 nicktr: The use cases in the IG were about "how you pay" and not about "how you provision methods" 01:58:48 q+ 01:58:50 ...that's a gap that we should tackle as a WG 01:58:50 q+ 01:59:18 AdrianHB: Another scenario is "out of band" unrelated to browsing, e.g., I install an App as a payment instrument 01:59:22 +1 on the OOB registration from an app 01:59:31 q? 01:59:38 zakim, close the queue 01:59:38 ok, nicktr, the speaker queue is closed 01:59:43 rbarnes: there may be an information modeling thing to do here...what is the logical set of information the UA has when someone tries to make a payment 01:59:44 ack m4nu 01:59:44 m4nu, you wanted to say that we may not want to parameterize in that way - prefer payment method and options 01:59:57 m4nu: +1 to talking about the registration scenarios 02:00:16 m4nu: But on Rouslan's proposal: why have both an API and a manifest? 02:00:18 fwtnb has joined #wpwg 02:00:24 ...also, I would like to separate the data formats from the protocols 02:00:48 q- 02:00:59 ...also, the proposal is missing a lot of important information; would be good to have an extensible javascript format 02:01:06 +1 to having a JSON rather than parameters in APIs 02:01:16 ...I think what is shown is safe but it presumes that payment instruments will have this set of data and nothing more. 02:01:20 q- 02:01:27 +1 to modelling the instrument in a JSON object format 02:01:29 m4nu:I'd like to define the data a bit more formally. 02:01:30 q- 02:01:55 q+ to ask about registration/synchronization of collections of instruments 02:02:20 m4nu: Is this set of APIs same as Zach's? 02:02:31 Zach: I had not gone into that level of detail in the explainer 02:02:43 ack Ryladog 02:03:10 Ryladog: Whenever we do things that we are going to be showing over time, we want to make sure we include accessibility. 02:03:14 q- 02:03:21 ...I just want to keep in mind that as we go forward. 02:03:27 q? 02:03:33 ack MattSaxon 02:04:22 ack Rouslan 02:04:25 yamane_ has joined #wpwg 02:04:35 Rouslan: Your statement about a native app that might be a provider of instruments. 02:04:44 We should also consider whether registration should be singular cases only, or if we will be able to handle registration collections of instruments or synchronization of collections across user agents 02:04:51 ...given that it's native it would be platform specific in how it registers itself with the browser 02:04:57 Information modeling for registration data needs to be done - consider the 2 uses for this data. 1) Provide the browser with data to render a selection dialogue 2) Provide the browser with enough data to initialize the payment instrument (URL?) 02:05:14 padler: Care to expound? Not sure I understand fully 02:05:48 Rouslan: I'd like to hear your thoughts on accessibility 02:06:06 q+ 02:06:13 Rouslan: The short name in this proposal could be used for things like text-to-speech, or alt text 02:06:15 q? 02:06:28 topic: Accessibility considerations 02:06:49 Janina: I'm chair of the accessible platforms wg 02:07:05 JMR has joined #wpwg 02:07:13 http://www.w3.org/2015/10/apa-charter 02:07:20 Accessible 02:07:20 Platform Architectures Working Group charter 02:07:24 so if i have already registered a collection of instruments in, let's say Chrome, being able to as a user to synchronize those instruments to other user agents (devices) that I own... with appropriate security of course.. 02:07:42 present+ Janina_Sajka 02:07:47 present+ Michael_Cooper 02:07:53 present+ John_Foliot 02:08:01 present+ Leonie_Watson 02:08:24 janina: We're excited about payments and want to help ensure their accessibility 02:08:39 ...also Shane McCarron is going to help work on some accessibility requirements around payments 02:09:10 ...what we did with media is talk about disabilities and the impact on consuming media 02:09:15 ...we are thinking of a similar approach to payments 02:09:25 ...impact of different disabilities on requirements 02:09:39 q+ 02:09:43 zakim, open the queue 02:09:43 ok, Ian, the speaker queue is open 02:09:46 q+ 02:09:57 q+ 02:10:11 jamesn has joined #wpwg 02:10:15 ack Ian 02:10:44 joanie has joined #wpwg 02:10:54 LJWatson has joined #wpwg 02:11:05 q+ 02:11:07 q+ 02:11:19 q+ 02:11:26 IJ: We are not specifying UI...do you have guidance on API design? 02:11:35 q+ to say that it might be interesting to have someone navigate our polyfill prototypes w/ various accessibility tools with the designers sitting beside them. 02:11:38 janina: We don't know all the answers. But for examples, there are topics like "Timeouts" 02:11:39 q- 02:11:45 ..some people need more time. 02:12:06 ...we may also need to think about the flow overall and user interactions in doing payments 02:12:13 ...we need to do some of that to expose what the APIs will need 02:12:24 ...I have only one today...I think there will be others. 02:12:34 q+ to say that he is consistently surprised by how he completely misses some accessability requirements, so it's important to have steady review 02:13:02 Ryladog: I think we need to have some guidelines ... such as around the use of biometrics 02:13:25 ...I know that there are more than those two things ; we are just starting work on guidance for API designers 02:13:50 q? 02:13:58 ...there are other things to keep in mind as spec writers such as ensuring examples in specifications demonstrate accessibility 02:14:14 ack nick_s 02:14:17 q+ to talk about UI elements 02:14:40 nick_s: What are some of the challenges people face today when making payments? 02:14:51 janina: Most locking devices on mobile have big accessibility issues. 02:14:59 ...if you have not enabled NFC you cannot use it. 02:15:03 ...that may not be for w3c to solve. 02:15:21 q+ to discuss UI inputs (information modeling for payment instrument) and suggest a stand-alone guidance document to accompany our rec 02:15:27 ..we had several things like that in media where simply enumerated things to keep in mind. 02:15:38 q? 02:16:06 Janina: Another ecommerce scenario is something like hearing prices as I am standing in line. 02:16:09 q+ create an environment to ease integration of accessibility easier 02:16:17 ShaneM has joined #wpwg 02:16:25 ...in terms of online payments, there are questions like a trust service where you don't have to reenter credentials will be valuable. 02:16:33 q+ to ask about guidance on embedded payment windows 02:16:35 ...timeouts may be necessary to take into account for some users 02:16:36 q? 02:16:37 q+ to create an environment to ease integration of accessibility easier 02:16:40 ack LJWatson 02:16:41 ack LJWatson 02:17:18 LJWatson: When I gave some feedback on the IG's use cases, Manu and I exchanged some emails; one idea that came out of discussion is guidance to people writing user interfaces when using these APIs. 02:17:51 ...in terms of the API itself, Ian asked where does accessibility fits in...until we know more about the API it's difficult to be sure...but it occurs to me that there may be data to exchange in the course of a transaction that may be important to someone with a disability. 02:18:04 ..for example, there may be (as Janina said) a need to provide timeouts 02:18:12 q+ to talk about invisible payments and confirmation 02:18:26 ack Rouslan 02:18:28 Janina: if you need a timeout, you almost always need it so you shouldn't have to set it every time. 02:18:56 Rouslan: there was a question about how can APIs and accessibility work together given that API happens in the browser...it was always my understanding that payment would only proceed with user consent. 02:19:17 ...so this implies UI and the browser would have to ask permission regardless of the user's accessibility needs. 02:19:18 ack Rouslan 02:19:22 q- 02:19:23 ack m4nu 02:19:25 m4nu, you wanted to say that it might be interesting to have someone navigate our polyfill prototypes w/ various accessibility tools with the designers sitting beside them. and to 02:19:25 ... say that he is consistently surprised by how he completely misses some accessability requirements, so it's important to have steady review 02:19:28 ...so we definitely need to be considering accessibility around consent 02:19:59 m4nu: Thanks for coming today; consistent review through the entire spec development process will be valuable. 02:20:05 ...having Katie and Shane in the group will be helpful 02:20:20 ...Leonie's review was very helpful (and so we now have accessibility considerations throughout the use cases doc)( 02:20:22 q? 02:20:54 ..in addition to review, it would be good for many of the people in the room to show people via demos how assistive technologies work with the protocols that we come up with. 02:21:23 ...so those are two requests: (1) regular review (2) demonstrate use of assistive technology with prototypes 02:21:23 q? 02:21:28 ack AdrianHB 02:21:28 AdrianHB, you wanted to discuss UI inputs (information modeling for payment instrument) and suggest a stand-alone guidance document to accompany our rec 02:21:35 ack AdrianHB 02:21:37 +1 to accessibility demos 02:22:24 AdrianHB: Thanks again for coming. Rouslan covered a point I wanted to make - information design around "what a payment instrument it." There are two pieces of information there...assistance to the browser in rendering the "chooser" UI...ensuring sufficient information to ensure that the chooser UI is accessible 02:22:44 q+ 02:22:49 ...also because we are not specifying UI, we may wish to create a companion Note on accessibility guidance for implementers of the spec. 02:23:16 ack ShaneM 02:23:17 ShaneM, you wanted to ask about guidance on embedded payment windows 02:23:31 (IJ: I think we could consider a companion implementer guide but not limited to accessibility) 02:23:34 kris has joined #wpwg 02:24:25 q+ to talk about a Payments UI Community Group to talk about non-normative (informative) UI guidelines, including accessibility, security, privacy, and so on 02:24:25 ShaneM: Suppose I am on a site and have an interface for choosing to pay 02:25:06 +1 ian - implementer guide (with accessibility section) 02:25:26 janina: somebody might want a unique sound that can help me make out when there's a payment event 02:25:33 ...I need to then be able to switch focus 02:26:01 Shane: there are also security issues around permissions 02:26:03 q? 02:26:07 ack jheuer 02:26:07 jheuer, you wanted to create an environment to ease integration of accessibility easier 02:26:11 q+ to raise two other accessability issues that are interesting - user brings their own device to process payment, user is congnitively impaired 02:26:13 zakim, close the queue 02:26:13 ok, nicktr, the speaker queue is closed 02:26:25 q? 02:27:56 Janina: Is there an event requirement in the API (e.g., to trigger a sound) 02:28:46 jheuer: Options could be a key element 02:28:52 ..if today we only have PIM and that's a hurdle to some 02:28:58 ..but there's a device that also supports fingerprint 02:29:03 s/PIM/PIN 02:29:23 Q+ 02:29:48 ack nicktr 02:29:48 nicktr, you wanted to talk about invisible payments and confirmation 02:29:52 janina: I named one benefit - an itemized receipt that you can read is a big deal 02:30:02 nicktr: You raised an important point - an explicit confirmation. 02:30:22 ...I think that's spot-on from an accessibility perspective 02:30:35 ...but merchants are seeking to remove explicit interactions where they can 02:30:50 ...e.g., think of Uber...implicit when you order the taxi. 02:31:09 to be clear though, that model’s no different to many other pre-ordering scenarios 02:31:29 nicktr: There are also issues with cognitive impairments; understanding that an action will cause a payment to happen 02:31:54 ...mandated confirmation would be a barrier to adoption 02:32:00 ...by some merchants 02:32:35 q? 02:32:38 ack 02:32:39 janina: there are also usability ideas about "consistent styling of information" when types of events happen such as payments 02:32:41 ack shepazu 02:32:41 shepazu, you wanted to talk about a Payments UI Community Group to talk about non-normative (informative) UI guidelines, including accessibility, security, privacy, and so on 02:33:16 shepazu: Although UI is outside the scope of our charter, I've spoken with other groups where they want to have a UI component. .....maybe there is an opportunity for a CG to document UI considerations 02:33:27 q? 02:33:29 ..there could be a UI guideline around payments that, if we could get the payments people involved, could be great. 02:34:33 suggestion: implementer guide should recommend that UAs allow a user preference that forces user consent every time a website wishes to call the payment API 02:34:54 manu has the last word 02:34:56 (We should be sure to talk with browser folks about their thoughts on consent UI) 02:35:14 zakim, manu has the last word 02:35:14 ok, nicktr, the speaker queue is closed and cleared 02:35:19 m4nu: Nick asked an interesting question about examples where accessibility requirements come into play 02:35:41 ...time required is one issue as has been called out 02:35:58 ...another topic that is interesting is when a larger industry push ends up forcing better accessibility 02:36:10 ...in the retail space, for example, there's a push to use mobile devices to do checkout 02:36:16 q? 02:36:21 ...that can benefit accessibility..people can use their own devices to check out 02:36:35 q+ 02:36:38 ...if we could enable that scenario through our work, then we might increase accessibility overall 02:37:08 I just wondered if there are similar i18n considerations at this point? 02:37:25 ...one area in the API where we can pay attention is to allow rich markup in data that is exchanged in the API that might affect display 02:37:31 LJWatson: that's a good suggestion. I think this will manifest as data about the user (such as accessibiity reqs) being stored by the browser (wallet) and passed (with user consent) to the payment instrument for consideration. 02:37:47 ...are there other things we can annotate in data objects that are either requirements or that enable accessibility tools to build richer UI 02:37:49 Note that if any economic incentives are made available through a non-accessible interface, that is a legal liability for the provider. 02:38:30 That is the providers problem, but we must keep it in mind. 02:38:43 s/providers/provider's/ 02:38:51 zakim, open the queue 02:38:51 ok, nicktr, the speaker queue is open 02:39:14 Ryladog: There are other data topics like "don't turn data into images that are not accessible in transit" 02:39:14 AdrianHB Yes, very much I think. 02:39:26 q? 02:39:34 q+ 02:39:38 AdrianHB: qqQ+ 02:39:48 q+ 02:39:52 q+ about liability 02:39:53 ack 02:39:59 ack MattSaxon 02:40:08 q- about 02:40:12 q- liability 02:40:18 q+ 02:40:20 q+ to speak about liability 02:40:33 MattSaxon: there will be some bits of information that will be used in UI.... 02:40:58 q? 02:41:01 AdrianHB: We need to ensure that the API must include enough information so that the user agent's rendering can be made accessible. 02:41:34 ...I'd even say that the data format will be decisive in many ways to the interactions possible in the UI 02:41:41 MattSaxon: Can we mark up our data so that it's clearer what is for machines to consume and what is for people to consume? 02:41:53 shepazu: That would help somewhat but might miss some things like timing. 02:43:37 q+ 02:43:47 q- 02:43:50 ack LJWatson 02:44:13 LJWatson: With eBay where you have auction countdown...you can preset a final amount and let system do time-sensitive bidding 02:44:17 q+ to mention financial disabilities and if that's an accessibility concern. 02:44:51 LJWatson: In some of these APIs, I wonder whether there are mechanisms to declare viable authorization mechanisms 02:44:57 ..eg., not using a retinal scan. 02:45:40 AdrianHB: opportunity for browsers to store accessibility requirements and optionally pass them to the payment instrument with the payment request 02:45:45 ...there are of course privacy issues 02:46:05 I think this is a platform-level thing 02:46:11 Not something for payment specifically 02:46:17 ak me 02:46:18 q? 02:46:28 sangjo has joined #wpwg 02:46:28 nick_s has joined #wpwg 02:46:44 ack dezell 02:46:44 dezell, you wanted to speak about liability 02:46:52 Mek has left #wpwg 02:47:20 dezell: There are liability issues [in some jurisdictions for some types of site] 02:47:29 ..if site is not accessibility 02:47:40 ...like the idea of guidelines for implementers 02:47:45 ack Ian 02:50:51 zkoch: you're right. We do need to think about if the payment instrument's user interaction is ever going to be done in a context where the accessibility requirements aren't known... 02:51:07 q? 02:51:10 ack m4nu 02:51:10 m4nu, you wanted to mention financial disabilities and if that's an accessibility concern. 02:51:11 ack m4nu 02:52:10 m4nu: Gates foundation interested in payments work... 02:52:24 ...are projects like financial services for the poor to those who don't have means to get it. 02:52:27 ...is that an accessibility issue? 02:52:30 katie: It is by the US Fed 02:52:55 nick_s has joined #wpwg 02:53:08 ...study shows majority of unbanked also have large proportion of disabilities 02:53:16 ...mobile can help a lot 02:53:31 q? 02:53:35 gjaya has joined #wpwg 02:54:50 IJ: Got other spec guidelines for helping accessibility review? 02:55:04 janina: we have a charter requirement to do something like that 02:55:09 rrsagent, make minutes 02:55:09 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 02:55:12 rrsagent, set logs team 02:57:11 (Cf charter about UI accessibility in implementations) 02:59:45 topic: Incorporating 3rd-party services in client-side JS: lessons from WebRTC identity management 03:02:52 (Dom Hazael-Massieux) 03:03:01 DHM: we communicate with third parties for identity verification 03:03:07 ...might be an interesting model for some payments work 03:03:18 (Slides pending) 03:03:35 DHM: WebRTC has P2P identification for end-to-end encryption 03:03:48 ...each peer gets their id validate by a third party identity provider 03:04:02 ...in a traditional client-server world you use certificates but can't do that in a p2p world 03:04:17 ...want to ensure that the person you think you are communicating with is that person 03:04:43 ...the model is that the ID you claim to have is validated by a third party 03:04:45 q+ to say that Social Web WG might need identities, Web Annotations WG might need identities, Web Payments WG might need identities, so how many specific identity APIs should we have at W3C? 03:05:04 lbolstad has joined #wpwg 03:05:06 nick_s has joined #wpwg 03:05:18 q+ to ask who the id provider is 03:05:26 (Dom shows a communication graph on the screen) 03:05:38 q+ to be constructive in asking if the time has come for a common way to verify these sorts of identity/credential flows at W3C. 03:06:10 http://w3c.github.io/webrtc-pc/#sec.identity-proxy 03:06:14 9.1 Identity Provider Interaction 03:07:26 DHM: Suppose you are on w3c webrtc service and want to connect with Adrian on Skype. 03:07:46 ....w3c javascript will ask for verification of Adrian, and the verification will be done via JS that was gotten from skype.com 03:07:53 q- 03:07:57 ...will be executing code from two entities 03:08:04 ...the JS executes in a separate global context 03:08:12 ...it has the properties in terms of security and isolation 03:08:26 ..also has a lot of flexibility in terms of how the ID provider provides the service 03:08:35 Martin_Thompson: Looks like a Worker 03:08:57 ...browser asks questions like "please generate an identity assertion" 03:09:09 ...or "I have an identity assertion can you validate it and tell me who this assertion is for" 03:09:17 ...,and the response can be yes or no 03:09:29 ...you can hide arbitrarily complex interactions (e.g., checking back at the server) 03:09:33 ...done safely within a sandbox 03:09:36 kura has joined #wpwg 03:09:44 ...you are operating in your own origin; not running code in your own origin 03:09:53 ..the code you get from your identity provider is from a well-known URI 03:09:57 ..you get it from skype.com 03:10:01 ..for example 03:10:09 rbarnes: There is analogy to service workers 03:10:15 q+ 03:10:31 AdrianHB: Isolated execution environment with a well-known standard API into that environment from the browser. 03:10:38 Richard; We define that API in IDL 03:11:04 ..in most webidl we talk about the provider being the browser...in this case, the browser is the client of the Api and "an application" is the actual provider 03:11:21 DHM: How does it apply to payments? 03:11:33 ...in payments you will likely have identity management...so this might be useful to you 03:11:34 is this prez available? 03:11:39 (not yet) 03:11:47 ...more generally it's useful for third party integration 03:11:47 ok 03:11:50 (will be) 03:12:02 DHM: I thought the model was interesting enough that might inspire you for the payments APIs 03:12:03 q/ 03:12:06 q? 03:12:08 q? 03:12:08 m4nu 03:12:12 ack m4nu 03:12:12 m4nu, you wanted to say that Social Web WG might need identities, Web Annotations WG might need identities, Web Payments WG might need identities, so how many specific identity 03:12:16 ... APIs should we have at W3C? and to be constructive in asking if the time has come for a common way to verify these sorts of identity/credential flows at W3C. 03:12:17 q+ 03:12:26 dom has joined #wpwg 03:12:32 m4nu: We are talking about identity and identity integration and a number of payment use cases require strong identity. 03:12:37 ...open question in this group on how to do this 03:12:55 ...partly there's a question for the TAG - there are multiple Working Groups that have started ways to create identities and they are not aligned. 03:12:59 ...that's one question (for the TAG). 03:13:12 ...do you think that this group could just reuse the identity integration mechanism that you've built? 03:13:25 ...we do need to verify identities...do you think it could be fit or extended for payments on the web 03:13:38 Richard; I don't know what identities you intend to create and consume in this content. 03:13:51 ..there are a number of assumptions here that are bound to the context in which this work operators 03:13:59 q+ to suggest this model may be useful for "hosting" a payment instrument however it doesn't deal with UI 03:14:00 ...one necessary piece is that the assertion you make is bound to a "context" 03:14:19 ...the way this is constructured, the IDP sandbox doesn't need to know; the browser is responsible 03:14:34 ...the IDP only sees a string that they want someone to attest to 03:14:50 ack Laurent 03:14:51 ...the model is simple and might be useful (produce -> consume) but you might need to tweak it 03:14:54 q? 03:15:17 Laurent: I am interested in understanding the drivers behind the choice to have the IDP verify the credential rather than a verifiable credential outisde the IDP. 03:15:37 Martin: We did a survey of technologies early in this process and determined there was no commonality among these things. 03:15:45 ...we needed generation and verification of assertions 03:15:52 ...whether these technologies did that was uncertain 03:16:08 q? 03:16:11 q+ to ask about assertions/assumptions that IDP can make about ID consumer execution environments 03:16:20 ...our approach of "providing code" enabled the impedance mismatch 03:16:27 ...took away need to agree on algorithms etc. 03:16:40 ...boiled down to "please create an assertion" and "is this assertion valid" 03:17:04 rbarnes; If we want to support a lot of payment systems we will likely want to support something like this 03:17:17 rbarnes has joined #wpwg 03:17:30 s/rbarnes;/rbarnes:/ 03:17:39 DHM: I think at a high level people can adapt their systems to these 2 simple operations...it should also allow innovation due to flexibility 03:17:51 q? 03:17:52 ...if you support these two operations you can interop with webrtc 03:18:15 Martin: We discussed a proposal ... you can take the same interface to a sandbox and codify in an HTTP request..that's relatively straightforward 03:18:19 ack jheuer 03:18:24 ..the information that traverses that interface is relatively well-defined 03:18:37 jheuer: +1 to that kind of flexibility 03:19:08 jheuer: What did you not find specifically in openID connect or other solutions? 03:19:11 Martin: Commonality 03:19:11 s/credential rather than a verifiable/credential rather than defining a fully verifiable/ 03:19:25 Martin: You duck a large number of interop issues by doing it this way 03:19:31 q? 03:19:45 jheuer: So can you imagine a common credentialing / identity interface to use this context across different application fields? 03:19:59 ...webrtc is not the only one that requires bi-lateral interaction? 03:20:10 Martin: Yes, I think the pattern could apply to other domains. 03:20:28 ...but we'd need to try a few times rather than forecast universality of the approach 03:21:01 EKR: Sounds more like FIDO to me 03:21:04 q? 03:21:09 ack AdrianHB 03:21:09 AdrianHB, you wanted to suggest this model may be useful for "hosting" a payment instrument however it doesn't deal with UI 03:21:12 ack AdrianHB 03:21:23 q+ to ask if you have an example of what this looks like (code / specs / etc.) 03:21:29 AdrianHB: In a conversation with Richard this came up....part of this was applying this model as the way to get payment instruments 03:21:51 -> http://localhost/~dom/webrtc-pc/webrtc.html#identity-provider-interaction Identity Provider Interactions in WebRTC API 03:21:53 ...as opposed to downloading code from an origin, you fetch code that performs payment instrument operations 03:21:56 ...but no UI it seems 03:22:13 Richard: In our conversations, the conclusion was that sandbox would reject things since UI needs not met 03:22:38 ...the least well tested part of the API is sending user to another site for interactions with user. 03:23:00 Ian: that's martin you're quoting 03:23:11 s/Richard:/Martin: 03:23:12 -> http://w3c.github.io/webrtc-pc/webrtc.html#identity-provider-interaction Provider Interactions in WebRTC API 03:23:12 ...as opposed to downloading code from an origin, you fetch code that performs payment instrument operations 03:23:20 q? 03:23:23 AdrianHB: So the standard is how to fetch execution logic. 03:23:42 ...this may be a way to handle payment instruments in cases where there is no UI 03:23:51 ...could have a URI where user interactions are required 03:24:04 ..but where not, could specify something like a URI where you fetch code to execute 03:24:12 ack padler 03:24:12 padler, you wanted to ask about assertions/assumptions that IDP can make about ID consumer execution environments 03:24:12 Martin: That particular cat can be sliced a number of ways 03:24:15 q+ to ask if this is specific to WebRTC? 03:24:46 padler: Are there assertions or assumptions that Identity providers can make ...e..g., I need to enforce that both browers implement something in a particular way? 03:24:59 q+ to suggest this might also be a way for payment instruments to verify request data from the merchant/payee 03:25:00 ...also, as we are looking at browser interactions, there are some interesting use cases around P2P payments 03:25:05 zakim, close the queue 03:25:05 ok, Ian, the speaker queue is closed 03:25:06 q? 03:25:27 Martin: A lot of what this enables in WebRTC is effectively UA-to-UA communications 03:25:47 ..one use is to create isolated media...I can send you things without site involvement (they can't see or change the media) 03:26:11 ....exposing APIs to make information available within that context is relatively straightforward...you can add payment specific hooks if you need them 03:26:14 q? 03:26:36 padler: I can imagine there would be identity providers for certain use cases in the payment space, where the community is a restricted subset. 03:26:55 padler: the origin has available all the information it would have on a regular page 03:27:11 ...if you have users logged in you have all the context you would have...and that can be part of the sandbox when it's started up 03:27:20 ...that information can be put into the sandbox 03:27:32 ..that's where the next level of power comes from...you can't do this with declarative forms 03:27:38 ...we thought that was pretty powerful 03:27:43 ack m4nu 03:27:43 m4nu, you wanted to ask if you have an example of what this looks like (code / specs / etc.) and to ask if this is specific to WebRTC? 03:28:11 m4nu: One thing is the design pattern; another is the implementation in the WebRTC spec 03:28:19 Martin: It's more loosely coupled than you'd think 03:28:42 m4nu: If it's loosely coupled, many of the things you do there mirror many of the things we are doing in credentials CG and also the payment instruments we are talking about here. 03:28:55 ...I noted that other groups are also thinking of doing the same thing (TAG discussion as I mentioned) 03:28:58 wouldn't naming conventions matter? ie do they have a 'package' independent of webrtc? 03:28:58 q? 03:29:00 zakim, AdrianHB has the last word 03:29:00 ok, nicktr, the speaker queue is closed and cleared 03:29:01 AdrianHB, you wanted to suggest this might also be a way for payment instruments to verify request data from the merchant/payee 03:29:14 ack me 03:29:29 AdrianHB: The only other thing I want to point out for consideration is the potential for this to be a way for the payment instrument to verify data from the merchant 03:29:50 ...if there was a need you could pull down the verification mechanism from the merchant's web site and the payment request could be verified against it. 03:29:57 +1 to verifying the merchant 03:30:00 ERK: The question is what are the invariants from the paying side 03:30:14 q+ 03:30:18 ...in order to produce a payment, what do you need to know 03:30:32 CyrilV has joined #wpwg 03:30:33 q+ 03:30:34 s/ERK/EKR/ 03:30:45 q+ 03:30:46 AdrianHB: The way I see this working is you are on a merchant web site....payment request made ... 03:30:54 ERK: there is "bound" and there is "verified" and that's not the same thing 03:31:29 AdrianHB: Suppose Paypal got data...there's no guarantee that data wasn't changed en route...there's a way to pull down logic and get confirmation such as "verify this really is your merchant ID number" 03:31:41 ERK: Let's take something less straightforward than Merchant number 03:31:52 Q+ 03:32:16 q+ 03:32:27 zakim, reopen the queue 03:32:27 ok, nicktr, the speaker queue is open 03:32:32 q+ 03:32:43 ERK: Distinguish that which needs to be supplied to the payment instrument and .... 03:32:44 zakim, close the queue 03:32:44 ok, nicktr, the speaker queue is closed 03:32:57 rbarnes: the API that the identity provider sees is different from the API that the web page sees that is making the call 03:33:04 kris has joined #wpwg 03:33:08 ..the identity provider thinks in terms of signing and verifying assertions 03:33:14 ..the web page thinks in terms of identities. 03:33:22 q? 03:33:23 ...the browser's role is to take that identity and present it to the identity provider 03:33:37 ..the group needs to think about what the receiving might want to see and what the payment instrument would provide 03:33:43 ack Cy 03:34:02 CyrilV: Regarding the payment constraint, we should have in mind to respect the contractual links of payment systems 03:34:32 ...merchant has a contractual like with his service provider....and user with his/her service provider...crosschecking would be difficult and perhaps not useful 03:35:01 AdrianHB: I propose we consider this just in terms of verifying data 03:35:11 ..it doesn't have to be integral to the payment process itself 03:35:28 ..it's something we can look at as an option ... how we verify data being passed around 03:35:32 rrsagent, make minutes 03:35:32 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 03:35:36 rrsagent, set logs public 03:36:53 End of day discussion: we should review "things we agree on" 03:37:11 I suggest we use it to review hard questions and focus on not solving, but deciding how we will proceed about solving i.e. capture some actions with specific assignmed people 03:58:57 rbarnes has joined #wpwg 04:01:06 sam has joined #wpwg 04:05:56 mnot has joined #wpwg 04:10:04 rbarnes has joined #wpwg 04:16:07 joanie has left #wpwg 04:18:56 m4nu has joined #wpwg 04:20:36 yaso has joined #wpwg 04:22:13 AdrianHB has joined #wpwg 04:23:57 rbarnes has joined #wpwg 04:24:38 ShaneM has joined #wpwg 04:26:23 nick_s has joined #wpwg 04:27:22 09~ 04:27:23 o9()( 04:31:43 rbarnes has joined #wpwg 04:32:38 giuseppe has joined #wpwg 04:33:23 lbolstad has joined #wpwg 04:34:34 Ryladog has joined #wpwg 04:34:36 gsnedders has joined #wpwg 04:34:49 Topic: W3C Testing How-To 04:34:57 zkoch has joined #wpwg 04:35:17 http://w3c.github.io/testing-how-to/#(1) 04:35:40 dezell has joined #wpwg 04:36:01 Rouslan has joined #wpwg 04:36:15 zephyr has joined #wpwg 04:36:32 s/09~// 04:36:52 s/o9()(// 04:36:59 scribenick: nicktr 04:37:11 padler has joined #wpwg 04:37:18 jyrossi has joined #wpwg 04:37:39 Phillipe: presents testing at w3c 04:37:47 ...testing is complicated 04:38:05 ...starting point is "Test the web forward" 04:38:17 ...we don't care about the w3c process 04:38:33 ...but w3c can make use of the TTWF project 04:38:43 shepazu has joined #wpwg 04:39:34 ...Fixing the web is a lifetimes work 04:39:45 Jiangtao has joined #wpwg 04:40:15 ...The good news is that submitting stuff via TTWF automatically tests with some browsers 04:40:22 q+ to ask about HTTP APIs - can you test that stuff in TTWF? 04:40:30 zakim, open the queue 04:40:30 ok, nicktr, the speaker queue is open 04:40:32 http://w3c.github.io/testing-how-to/#(1) 04:40:35 q+ to ask about HTTP APIs - can you test that stuff in TTWF? 04:41:12 Phillipe: the testing infrastructure is all there 04:41:22 ...the science of browser testing is imperfect 04:42:22 ...API tests via test harness.js 04:42:41 (Phillipe demonstrates on screen) 04:42:58 s/test harness.js/testharness.js/ 04:43:37 Phillipe: testharness.js supports assertions, asynchronous testing 04:43:48 ...metadata is minimal 04:43:53 dhe has joined #wpwg 04:44:31 ...assessing coverage is problematic 04:45:00 (Phillipe treads on VGA lead, screen goes blank) 04:45:09 (Magic happens, screen reappears) 04:45:15 shoko has joined #wpwg 04:46:04 Phillipe: reftest not applicable (needed for screen display) 04:46:16 ...manual tests are sad tests 04:47:12 q+ to ask if there are WebDriver suites that you can put /somewhere/? 04:47:28 ...describes visibility change example 04:48:16 ...Web IDL tests will make you cry becuase browser implementations are imperfect 04:48:26 q+ to ask about autogen tests 04:48:38 s/becuase/because/ 04:49:28 rrsagent, draft minutes 04:49:28 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html nicktr 04:50:08 Phillipe: client-server tests we have two examples: xmlhttprequest and web sockets 04:50:43 ...we don't expect people to use web platform test server 04:51:16 rbarnes has joined #wpwg 04:51:17 ... if the server is up you can use it 04:51:24 ...but the preference is to do a local install 04:51:35 ack m4nu 04:51:35 m4nu, you wanted to ask about HTTP APIs - can you test that stuff in TTWF? and to ask if there are WebDriver suites that you can put /somewhere/? 04:52:13 manu: we are going to have 3 types of testing: browser apis, serverside http api, web driver 04:52:30 ...the last is not supported by ttwf 04:52:43 aji has joined #wpwg 04:52:57 ...if we were to write web driver tests, are there requirements to ensure future compatibility 04:53:22 @@: one of our goals is to allow you to do the testing from one html file 04:53:59 @@: if you write a test today, it feels like in 6 months time you should be able to use that 04:54:30 @@: prompt dialogues aren't supported but you can think about extending web driver for that sort of thing 04:54:58 @@: for example we are looking at bluetooth but the pattern isn't there yet 04:55:08 ack shepazu 04:55:08 shepazu, you wanted to ask about autogen tests 04:55:20 wonsuk has joined #wpwg 04:55:25 doug: do you have a pattern for json-ld? 04:55:40 JimB has joined #wpwg 04:55:40 (manu: whispers it's not needed) 04:56:19 q+ to ask about server 04:56:41 q+ to ask if the IDL tests just check to make sure the interfaces are well formed. 04:57:05 ShaneM: is it providing datafactories? 04:57:10 phillipe: no 04:57:13 q- 04:57:49 ShaneM: your not exercising the methods, just checking that they exisit 04:57:56 Phillipe: correct 04:58:03 ack dezell 04:58:03 dezell, you wanted to ask about server 04:58:21 dezell: client-server: do you write your own server? 04:58:36 phillipe: no, we have code to do that 04:59:10 ... we don't need to know ip or local name, we have meta-syntax to let those tests auto-generate 04:59:22 ...we have IDNs (?) as well 04:59:26 s/@@/jgraham/g 04:59:53 shaneM: I brought up the env't on a virutal server in 20 minutes. well played. 05:00:22 mnot has joined #wpwg 05:00:27 Phillipe: as a WG you need to convince the Director - one of the ways is to prove you have the test suites 05:01:11 ...results. Stick them in the w3c/test-results repo is one approach 05:01:32 kura has joined #wpwg 05:01:35 Phillipe: we'd ideally like the results directly form the browser vendors 05:02:15 ...There are two kinds of licenses. WG doesn't have to worry. All sorted. 05:02:34 ...Strategies: don't wait until the last minute 05:02:36 sam has joined #wpwg 05:02:45 ...No mods without tests 05:02:46 q? 05:03:13 ...find a leader who can understand w3c/web-platform-tests and get them to guide the group 05:03:21 ...there are no w3c dedicated resources 05:04:06 q+ to clarify process 05:04:08 ...but the docs are pretty good 05:04:25 ...and there is an irc channel: #testing 05:04:30 q? 05:04:33 ack AdrianHB 05:04:33 AdrianHB, you wanted to clarify process 05:05:06 adrianHB: to clarify. the WG will write as we go locally but submit to TTWF repo ? 05:05:15 Phillipe: Correct 05:06:02 ...Submitting early heads off mistakes 05:06:22 AdrianHB: we are hoping to be iterating on tests and recommendations rapidly 05:06:24 q+ 05:06:49 ack Ian 05:07:03 http://www.w3.org/TR/qaframe-spec/ 05:07:06 QA Framework: Specification Guidelines 05:07:21 Ian: a long time ago (2005) there was a QA Framwork Spec guidelines was published 05:07:42 ...do the test folks have more up to date guidelines for TTWF style tests 05:09:29 jgraham: be careful with respec 05:10:08 ShaneM: don't do what RDFA did with regard to algorithms 05:10:12 q? 05:10:13 q? 05:10:55 adrianba: can you tag things in respec to mark things for testing? 05:11:04 phillipe: there's no tool for that 05:11:12 s/adrianba/adrianhb 05:11:46 jgraham: there _are_ tools but there is not usually a mapping between must statements and tests 05:12:19 phillipe: (shows directory listing of web-platform-tests repo) 05:12:51 ...web socket server running inside each server, supports TLS 05:14:04 ShaneM: is there a driver to run over collection of tests 05:14:43 Phillipe: We have a little test runner 05:15:05 ...(shows runner) 05:15:18 ...takes a directory as an argument 05:15:31 ...only runs js tests 05:16:10 ...Better way is to you WPTrunner 05:16:35 ...runs on Firefox and chrome. Working on Edge. No safari 05:17:13 Phillipe: advantage of the latter is that can run reftests 05:17:41 ...and makes it more tolerant of browser crashes 05:17:54 ShaneM: does Earl still exist? 05:18:08 Everyone: nope. move along. nothing to see here. 05:18:26 Phillipe: we don't want anyone to run manual tests 05:18:28 http://www.w3.org/TR/EARL10-Schema/ 05:18:30 NO 05:18:34 JimB has joined #wpwg 05:19:38 rrsagent, make minutes 05:19:38 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 05:19:39 schepers explains the role of test lead. Test wrangling is the principal role 05:19:52 (Shane volunteers to lead the test work) 05:19:54 ShaneM volunteers magnifiently 05:20:27 Other people who will be interested in writing tests: m4nu 05:20:27 AdrianHB: any volunteers for testing writing. 05:20:38 Manu: we will be writing tests 05:21:00 Schepers: anyone writing product will be writing tests 05:21:12 scribe: AdrianHB 05:22:03 topic: How we will work 05:22:06 wonsuk has left #wpwg 05:22:15 sub-topic: tooling 05:22:22 +1 to github 05:22:27 CVS!Q 05:22:30 No, RCS! 05:22:34 Github ALL THE THINGS 05:22:35 nicktr: I suspect that there is consensus on using GitHub as our primary collab tool 05:22:50 https://github.com/w3c/webpayments 05:23:07 (chair notes no objections) 05:23:33 nicktr: to clarify; will we use the wiki functions of GitHub 05:24:00 manu: limitations on GitHub ito history 05:24:23 ian: there is a commitment to persist work product and also to use nuetral tools 05:24:43 ... we don't need to be rigid if everyone can access the tool 05:25:00 ... begs the question, what will we use the mailing list for 05:25:04 q+ to talk about the purpose of the mailing list 05:25:09 q+ to mention github tracker vs. being able to track stuff against spec + mailing list 05:25:18 nicktr: GitHub has a notification framework should this be wired to the mailing list 05:25:23 ack ShaneM 05:25:23 ShaneM, you wanted to talk about the purpose of the mailing list 05:25:28 ? 05:25:39 adrianba: it's possible, is it desirable 05:26:00 shanem: mailing list will be used for agenda's and other discussion 05:26:13 ... it makes sense to be able to archive what goes on in GitHub 05:26:25 (There are also discussions of archiving github repos on w3.org...another topic for another day) 05:26:48 ... we could wire event hooks from GitHub to services at W3C so they are persisted 05:27:12 shepazu: there are tools to do this 05:27:23 ... everything is being archived 05:27:42 nicktr: is w3c archiving everything on GitHub 05:28:07 q+ 05:28:19 shepazu: there is an automated publishing framework that lets us push drafts from GutHub to the site 05:28:53 ack m4nu 05:28:53 m4nu, you wanted to mention github tracker vs. being able to track stuff against spec + mailing list 05:29:01 shepazu: to clarify, we have talked about taking snapshots of the GitHub content but are not doing that now 05:29:29 s/GutHub/GitHub 05:29:32 manu: let's just use GitHub issue tracker as this helps with our responsibility for tracking comments 05:30:12 q? 05:30:17 m4nu: how do issues mentioned in the mailing list get into the issue tracker? 05:30:26 q+ to ask about bugzilla or successor 05:30:46 ACTION: Shepazu to look into connectivity in both directions between a mailing list and github repo in both directions 05:30:53 ian: there appears to be an action to investigate how to do this? 05:31:03 q- 05:31:19 q+ 05:32:45 ack adrianba 05:32:47 adrianba: Microsoft opinion is we should no longer use mailing lists for technical discussions because using something like GutHub allows the discussion to be threaded, tagged, closed and explicitly re-opened. Mailing lists are open to abuse of the status of an issue 05:33:03 GitHub allows you to subscribe to issues if thats what you want 05:33:26 q+ 05:33:47 ... Some groups have configured GitHub to send mails to the mailing list but my preference would be to use an alternative mailing list if we do this. 05:34:00 ... The mailing list does have value for meta discussion 05:34:43 q- 05:35:00 shepazu: Minutes are not filed but often issues are raised in meetings. Suggestions for addressing this? 05:35:30 adrianba: The practice that os encouraged is that if issues are raised in the call they are filed at the time and referenced 05:35:34 q+ to ask if we're going to have problems w/ issue engagement w/ people that are not familiar with Github - tends to be a techie audience. 05:35:35 +1 05:35:38 ... same applied on the mailing list 05:35:40 +1 05:35:41 q+ 05:36:08 shepazu: does anyone have a problem with using GitHub 05:36:11 NickTR: I can't get to github from my corporate account 05:36:17 q? 05:36:44 nicktr: But this isn't an issue for me. Are there others with similar issues? 05:36:54 cyril: not sure 05:36:55 q- 05:37:11 kris: we don't have access but I can work around this 05:37:40 ack Ryladog 05:37:40 shepazu: I believe it is possible to mail responses back to GitHub 05:37:52 q+ 05:37:55 q- 05:38:01 Ryladog: Do we have experience with using GitHub for the WG functions 05:38:52 ian: most WGs are doing this. we have some learnings. the chairs will need to monitor this and ensure we are not missing any of our obligations and learning from other groups. 05:39:01 ack m4nu 05:39:01 m4nu, you wanted to ask if we're going to have problems w/ issue engagement w/ people that are not familiar with Github - tends to be a techie audience. 05:39:07 adrianba: there is a rec that was created using GitHub 05:39:38 m4nu: +1000 to using GitHub but I worry about excluding non-technical or other stakeholders 05:40:00 q? 05:40:34 ... we will exclude people but I think we still want to use GitHub 05:41:00 ian: to clarify the only thing they can't do is make submissions? 05:41:29 IJ: I don't want to limit interaction; people who can't use the tools should have other routes including email and we should support their interactions 05:41:32 nicktr: I am prepared to make sure that if there are things we want to share more widely that they are in an easily accessible format and place 05:41:38 q+ 05:42:16 ack matt 05:42:33 MattSaxon: The flows collaborators are all potentially being excluded 05:43:07 nicktr: MattSaxon will look at solving this 05:43:34 Laurent: Can we migrate any prior work to our new repo 05:44:17 shepazu: if they are specs then they should be at the W3C root repo other stuff 05:44:29 ... at the group repo 05:44:57 just to correct myself: i do have github access (joehoe!) 05:45:08 q? 05:45:44 Cyril: Can we get an email that summarizes this 05:46:19 sub-topic: meeting cadence 05:46:40 nicktr: there is a request that we accommodate our participants in the East 05:47:33 proposal is to run weekly meetings and alternate the time to be morning (UTC) and afternoon (UTC). 05:48:12 +1 to the alternating schedule 05:48:18 mattsaxon: is the expectation that people will attend them all 05:48:24 q+ to set expectations 05:48:41 q+ 05:48:58 sceptical manu is sceptical 05:49:11 nicktr: no, but people will attend the late/early one if they feel they need so 05:49:32 manu: (observes that most WGs start like this but change if participation drops) 05:50:02 q+ to ask when we start calls? 05:50:09 q- 05:50:14 q- 05:50:22 shepazu: let's start this way but I agree that often the participation drops off let's handle this when it happens 05:50:38 sub-topic: face to face 05:51:03 nicktr: do we want 2 or 3 f2f meetings next year 05:51:20 manu: there is a lot of other payements stuff going on, 2 is enough 05:51:24 q+ 05:51:47 nicktr: proposal then to do 1 near end Feb in USA (West Coast) backing the IG f2f and one other 05:51:52 q? 05:52:02 q+ 05:52:09 padler: when will we start calls? 05:52:36 nicktr: propose we start calls week after next but will figure out a good time in the interim 05:52:38 ack padler 05:52:38 padler, you wanted to ask when we start calls? 05:52:43 ack zkoch 05:53:09 ACTION: nicktr to set up questionnaire to find best day for weekly meetings 05:53:21 q? 05:53:28 zkoch: I like the idea of meeting more often than every 6 months (i.e. more than twice) as I think we'll need it 05:53:37 +1 to meeting between feb and tpac 05:53:55 +1 to meeting between feb and tpac 05:54:01 shepazu: perhaps we should try to meet at a time and place that members are already getting together 05:54:04 ... and then also TPAC 05:54:30 ack dezell 05:54:40 nicktr: feels like there is a desire for a mid-year meeting but let's put off planning that for now 05:54:56 q+ 05:55:00 dezell: if we don't plan the Feb meeting now we might not 05:55:32 ... we also need to make a list of events that makes sense for us to all attend (this was a task the IG planned to undertake) 05:55:36 q? 05:55:42 ack shepazu 05:56:21 shepazu: TAg suggest that W3C WGs try to engage with the public more. I recommend that next time we meet we have a public event (dev meetup)? 05:56:31 rrsagent, make minutes 05:56:31 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 05:56:35 rrsagent, set logs team 05:58:44 LJWatson has joined #wpwg 05:58:57 padler has joined #wpwg 05:59:29 padler has joined #wpwg 06:00:06 gsnedders has left #wpwg 06:00:26 padler has joined #wpwg 06:07:42 bhill2 has joined #wpwg 06:11:28 yaso has joined #wpwg 06:25:11 nick_s has joined #wpwg 06:30:10 lbolstad has joined #wpwg 06:31:50 Rouslan has joined #wpwg 06:34:48 AdrianHB has joined #wpwg 06:37:29 rbarnes has joined #wpwg 06:38:26 shepazu has joined #wpwg 06:41:30 padler has joined #wpwg 06:42:57 kura has joined #wpwg 06:44:02 ShaneM has joined #wpwg 06:46:15 actions? 06:47:11 trackbot has joined #wpwg 06:47:35 rrsagent, set logs team 06:47:38 rrsagent, set logs public 06:48:16 scribe: Ian 06:48:18 zkoch has joined #wpwg 06:48:26 Topic: Next steps 06:48:38 Captain who? 06:48:53 q+ 06:50:26 IJ: IG relationship - future reviews, chairs can decide to meet from time to time; joint meeting end of February 06:51:06 Dezell: IG meeting weekly 10am ET Monday...planning to continue that for now 06:51:48 NickTR: Any other comments/concerns about running the group? 06:52:04 jheuer: I can't join the group officially for now; I hope the IG remains a place where we can connect 06:52:24 Feb 25, 26, 27? 06:52:33 Are those the dates? 06:52:46 Things are looking good to host 06:52:55 (Could be those dates or any time that week 06:52:55 I just need to submit a finalized request, which I’ll do today or tomorrow 06:52:58 k 06:52:59 Okay 06:53:38 ACTION: nicktr to write up the group operations in a wiki (re email, issues, etc.) 06:53:38 Created ACTION-1 - Write up the group operations in a wiki (re email, issues, etc.) [on Nick Telford-Reed - due 2015-11-06]. 06:53:56 q+ 06:54:06 q- 06:54:24 ack adrian 06:54:40 adrianba: Against my better judgment I'm volunteering to help NickTR with the work mode document 06:54:47 http://bit.ly/1NEkkz8 06:55:48 Things we agree on 06:55:49 Github as principal tooling 06:55:49 Nick to create “signposts” 06:55:49 Doug investigating integration to mailing lists and wiki 06:55:49 Weekly meetings with alternating times to support US and AP 06:55:50 Flows being documented led by Matt 06:55:51 Both candidate specs being worked on, not yet to be merged 06:55:53 Face to face with WPIG in late Feb, on West Coast of US 06:55:55 Face to face at TPAC in Lisbon, Portugal in September 06:55:57 We might need another F2F - to be decided at next F2F 06:56:46 Nick: Timelines? 06:57:09 q+ 06:57:20 ack adr 06:57:25 https://docs.google.com/document/d/1yJEba_BCUK0Q1nCaD2sGM4h6HxxxEcT15ruRlvowr7o/edit?usp=sharing 06:57:27 Manu: 1 month? 06:57:46 adrianba: I've learned a bunch of lessons from the discussion and that inform the feedback on the proposal. 06:57:58 ...my goal is that we take those lessons and incorporate them as soon as we can. 06:58:14 ...I don't think I could predict a good time frame for making a decision on the future of the alternate proposals. 06:58:32 ...but if we weren't having substantive discussions comparing the proposals in November then I think we would be failing the group 06:58:46 AdrianHB: So we need a milestone for "feedback has been incorporated" 06:59:15 m4nu: There are big issues we need to resolve like "does linked data play a role?" or "is remote storage in scope?" 06:59:23 ...by having those discussions I think they reflect what's actually in the proposals. 06:59:37 ...I don't think the specs need a full rev before we start discussion of the stickier issues 06:59:44 ...we can rev the specs quickly while we are having the discussions 06:59:55 AdrianHB: How do we feel about documenting issues in github 07:00:08 ..i mean the high-level discussions 07:00:12 q? 07:00:56 q+ 07:01:09 AdrianHB: I there will be issues in the web platform github repo, as well as issues that are more general in the Payments WG github repo 07:01:14 ack adrianba 07:01:41 adrianba: I like what I just heard. It would be good if we could start to capture those general issues in the general repo and use them to generate agenda items for the calls 07:01:47 ...it's incumbent upon us to make a start on that. 07:02:23 shepazu has joined #wpwg 07:02:34 ian: let's allow anyone to also submit issues 07:02:38 wonsuk has joined #wpwg 07:02:55 ACTION: AdrianHB to start documenting general issues and inform WG of initial pass so they can add to the list or add comments 07:02:55 Error finding 'AdrianHB'. You can review and register nicknames at . 07:03:14 adrianHB: Then we can prioritize them based on the ones that are getting the most discussion 07:04:30 Ryladog has joined #wpwg 07:04:57 AdrianHB: I think we have a good todo list. 07:05:23 q? 07:06:34 IJ: I think a good way to use meetings is for people to work on proposals, for us to review proposals before meetings, and use meeting time to review comments 07:06:58 LJWatson has joined #wpwg 07:07:52 Adrianba: I think there is agreement we should discuss the various kinds of registration. 07:07:54 jyrossi has joined #wpwg 07:08:01 ...but I don't agree we've decided in which forms there should be 07:09:23 AdrianHB: Anybody want to step up to lead discussion on registration scenarios? 07:09:27 disagree 07:09:32 kittens are awesome 07:09:41 ponies 07:09:47 +1 for ponies 07:09:56 ACTION: adrianba to write up list of registration scenarios he he mentioned in more detail 07:09:56 Created ACTION-2 - Write up list of registration scenarios he he mentioned in more detail [on Adrian Bateman - due 2015-11-06]. 07:10:56 Laurent: I think we also agreed to define a payment request data format. 07:11:03 AdrianHB; Registration request as well 07:18:03 RESOLVED that we agree upon the following summary 07:18:04 ==== 07:18:05 Things we agree on 07:18:05 Github as principal tooling 07:18:05 Nick to create “signposts” 07:18:05 Doug investigating integration to mailing lists and wiki 07:18:06 Weekly meetings with alternating times to support US and AP 07:18:07 Flows being documented led by Matt 07:18:11 Both candidate specs being worked on, not yet to be merged 07:18:13 Face to face with WPIG in late Feb, on West Coast of US 07:18:15 Face to face at TPAC in Lisbon, Portugal in September 07:18:17 We might need another F2F - to be decided at next F2F 07:18:19 We need to enumerate the registration flows - Adrian B will write down and then look for willing victims to edit 07:18:22 Browser API 07:18:24 Should be promise-based 07:18:26 Should be polyfill-able for basic functionality 07:18:28 Should have tests associated in Test The Web Forward 07:18:30 Should consider accessibility data in the data that is used w/ the API 07:18:32 ===== 07:18:46 rrsagent, make minutes 07:18:46 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 07:22:16 zkoch has joined #wpwg 07:22:18 https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality 07:23:10 Another agreement point: 07:23:18 * Everything is HTTPS (rather than HTTP) 07:24:37 ShaneM has joined #wpwg 07:26:52 q? 07:27:27 for context: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ 07:28:07 rrsagent, make minutes 07:28:07 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 07:28:11 rrsagent, set logs public 07:28:18 Topic: Closing 07:28:25 NickTR: Thank you to all! I hope you will continue to participate 07:28:35 ...do your actions 07:28:47 ...we will only be successful if we move things forward 07:28:57 ...I look forward to meeting you on IRC, WebEx (and of course github) 07:29:02 rrsagent, make minutes 07:29:02 I have made the request to generate http://www.w3.org/2015/10/29-wpwg-minutes.html Ian 07:29:07 q? 07:29:11 rrsagent, bye 07:29:11 I see 6 open action items saved in http://www.w3.org/2015/10/30-wpwg-actions.rdf : 07:29:11 ACTION: MattSaxon to lead discussion among volunteers about creating flows and diagrams [1] 07:29:11 recorded in http://www.w3.org/2015/10/29-wpwg-irc#T01-46-48 07:29:11 ACTION: Shepazu to look into connectivity in both directions between a mailing list and github repo in both directions [2] 07:29:11 recorded in http://www.w3.org/2015/10/29-wpwg-irc#T05-30-46 07:29:11 ACTION: nicktr to set up questionnaire to find best day for weekly meetings [3] 07:29:11 recorded in http://www.w3.org/2015/10/29-wpwg-irc#T05-53-09 07:29:11 ACTION: nicktr to write up the group operations in a wiki (re email, issues, etc.) [4] 07:29:11 recorded in http://www.w3.org/2015/10/29-wpwg-irc#T06-53-38 07:29:11 ACTION: AdrianHB to start documenting general issues and inform WG of initial pass so they can add to the list or add comments [5] 07:29:11 recorded in http://www.w3.org/2015/10/29-wpwg-irc#T07-02-55 07:29:11 ACTION: adrianba to write up list of registration scenarios he he mentioned in more detail [6] 07:29:11 recorded in http://www.w3.org/2015/10/29-wpwg-irc#T07-09-56 07:29:16 zakiim, close the queue 07:29:22 zakim, bye 07:29:22 leaving. As of this point the attendees have been ShaneM, zephyr, Ian, padler, Rouslan, Solomakhin, Jiangtao, BarryLeiba, rbarnes, Nick_TelfordReed, manu, Cyril, Vignet, 07:29:22 Zakim has left #wpwg 07:29:25 ... MattSaxon, bhill2, nicktr, Adrian_Bateman, jyrossi, Richard_Barnes, dezell, zkoch, shepazu, IanJacobs, wseltzer, giuseppe, Ann, Bassetti, Katie, Haritos-Shea, Janina_Sajka, 07:29:25 ... Michael_Cooper, John_Foliot, Leonie_Watson