Web Payments Working Group
30 Oct 2015


See also: 29 October minutes and today's IRC log


Adrian_Bateman, BarryLeiba, Cyril, Ian, Jiangtao, MattSaxon, Nick_TelfordReed, Rouslan, ShaneM, Solomakhin, Vignet, bhill2, jyrossi, manu, nicktr, padler, rbarnes, zephyr, wseltzer, giuseppe, Ann, Bassetti, Katie, Haritos-Shea, Janina_Sajka, Michael_Cooper, John_Foliot, Leonie_Watson, Katie Haritos-Shea
Nick Telford-Reed
Ian, manu, AdrianHB


Agenda Bashing

<m4nu> Nick: Looking at revised agenda - look at registration, other changes towards end of day. Straw poll - who needs to leave before end of day

<m4nu> (Only one person raises their hand - MATT)

<m4nu> 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.

<m4nu> 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. 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.

<m4nu> Nick: Matt has already volunteered to do that work. It would be good to leave w/ as many names as possible volunteering at end of day. There was a proposal to split up, would rather not do that, may be hard to get all stuff back together again. We have other folks from W3C - that's just trying to get lessons learned, collective wisdom together.

Security Considerations

(Brad Hill, Dan Veditz join the meeting)

<m4nu> Nick: Moving on to security considerations

<m4nu> 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.

<m4nu> MattSaxon: Echoing what was said previously

<m4nu> 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. 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. Thinking about that, you have a lot of challenges ahead. 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. 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. 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.

<annbass> 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). Also, I -- as an average user -- am notoriously slow to update anything

<m4nu> 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.

<Zakim> 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"

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
... we've been chatting with Bill and Melinda Gates Foundation also; they have a payments initiative to improve ecosystem worldwide
... 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
... are there a set of API best practices from the security community that we could look at?

<m4nu> 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

<m4nu> rbarnes: 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.

<rbarnes> m4nu: me :) (richard barnes, mozilla)

<m4nu> 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?

<m4nu> 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,

<m4nu> what they are and what they do.

bhill2: (Ian notes valuable phrase uttered: "focus on properties you depend on")

<m4nu> 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

<m4nu> Doug: Are you suggesting polyfills for testing or deployment.

<m4nu> brad: Difficult to answer concretely, it's a tradeoff

<m4nu> pat: balance of trust mechanics are great, thank you for commenting on that. 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. Any thoughts with work going on at W3C - any B2B security aspects happening at W3C vs. consumer side focus that we have now.

<m4nu> 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.

<m4nu> pat: How do we figure out a way to create incentives for small businesses to update - it's not easy to upgrade them, we need something quick, robust, secure.

<m4nu> brad: Google Checkout in google shopping cart 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 more complicated - we'll charge

<m4nu> 10 basis to use one and 5 to use the other - we'll share risk differential w/ you for pricing structure.

<m4nu> brad: You can decide as a merchant to do what makes sense to you with the risk profile that makes sense to you. Building multiple protocols is better than building one protocol w/ negotiation and options - different incentives is a more easy system to secure.

<m4nu> 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. 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.

<m4nu> nicktr: So, there are three things you wanted to talk about brad...

<m4nu> 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

<m4nu> to follow, we don't have good solutions for this stuff.

<m4nu> brad: Biggest tensions I've seen recently is that we're competing w/ the app platform. 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. Web has other strengths, immediate deploy, no permissions necessary to deploy, etc. The first principle of the Web is you can do most anything you want - people interact w/ many different security principals, no sense of reputable vs. disreputable sites.

<m4nu> AdrianHB: Do we have to disregard same origin?

<m4nu> 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

<m4nu> information. Can you get away with that, maybe.

<m4nu> brad: There are design patterns around this stuff - privacy preserving things.

<m4nu> AdrianHB: Is the same origin policy about privacy? not tracking? Or is same origin about trusting the payment instrument because there is some sort of origin?

<m4nu> brad: it's about the fact that user is interacting w/ different origins - you have 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. We are trying to ensure that every product on every shelf is not able to get data from you, for example. 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 knife, have a spoon, knife, and a fork.

<m4nu> Ian: If we make it easier to pay, we make it riskier for phishing, an easier to pay world - what are the emerging ways to protect consumers from phishing.

<m4nu> 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.

<m4nu> Ian: How about getting greater assurances of who you are dealing with.

<bhill2> http://news.yahoo.com/video/yahoo-trust-unconference-security-ux-161037378.html

<zkoch> technically she’s a PM! yay PMs! :)

<m4nu> 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.

<m4nu> 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.

<m4nu> 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

m4nu: when it comes to SOP and browser mediation I think there's a lot of confusion and what it means for APIs.
... 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
... but browser mediation is fine way to do payments
... where do you think it's ok for the browser to mediate things like payments?
... there seem to be two areas of concern: (1) privacy [linkability, trackability] and (2) security (not dealing with malicious sites
... I think it's useful to discuss SOP in at least those two ways
... I think payments not in conflict with SOP
... when it comes to identity and traceability, I think that's more of an issue with payments since merchants want data
... 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

<m4nu> DanVeditz: I don't worry as much about same origin policy, send API out for review.

<m4nu> 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.

<rbarnes> there is inherent in what this group wants some new cross-origin stuff

<m4nu> DanVeditz: There are ways for sites to violate same origin policy if they communicate - for a payment 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.

<m4nu> 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

<m4nu> possible in security model - big worry is page w/ JS on it - idea that all JS used comes from that page.

rbarnes: "Labeled origin policy"

<m4nu> 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.

<m4nu> DanVeditz: That's what you're building w/ an API - if that does stuff, as long as you define 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.

<rbarnes> in other words: SOP is a misnomer

<nick_s> maybe they shouldn’t have been using the PANs for that in the first place ;)

<m4nu> 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. 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. Thank you Brad, would Facebook like to join

<Zakim> jheuer, you wanted to say payment technologies often have their own ways to protect their processes - where is the responsibility of browsers, wallets, etc? Abstractions wrapping

<m4nu> brad: no comment :)

<nick_s> you sure wendy? I’ll just do my best impression of you

<m4nu> 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.

<Zakim> wseltzer, you wanted to comment on heuristics and non-deterministic systems vs user learning

<m4nu> 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 -

<m4nu> we want something secure regardless of instrument.

<nick_s> thanks wendy!

<wseltzer> any time

<m4nu> nick: We're out of time, break for 15 minutes, back at 20 past 10, thanks to webappsec for coming along.


MattS: I'd like to hear from people about the approach to diagramming the flows, who wants to be involved

(Display of yesterday's flow now in UML)

(Display of google proposal with 3DS)

(display of the community group proposal)

MattS: Both proposals support 3DS flow
... that's my conclusion by working through the diagrams

Diagrams done with PlantUML

scribe: very simple text-based tool...free...hosted in MS Word
... there are web-based versions as well such as web sequence diagrams
... there were some subtle changes between tools but only subtle

AdrianHB: Can we check the text source into github?

<Zakim> ShaneM, you wanted to note that PlantUML generates SVG!

<AdrianHB> +1 for a UML tool that allows us to store our data as text in documents on GitHub


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.
... e.g., document real-world flows to test our proposals against.

MattS: I would like to understand the prioritized list of flows we should be creating

adrianba: I caution against making something too formal at this point. E.g., not necessary to create task forces in any formal sense.
... 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.
... I was happy to volunteer for this but I think many have volunteered already and efficiency might go done.
... so I'm happy for them to figure out together how to do their work.

AdrianHB: I will also talk to Mountie as well

<scribe> ACTION: MattSaxon to lead discussion among volunteers about creating flows and diagrams [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action01]


<Rouslan> My website-based instrument registration thoughts: https://goo.gl/656sby

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
... for the Web sites, once you tell the browser that they are there, there are 2 ways to register;
... javascript API or manifest
... for the javascript API, paypal.com would call to register themselves. Data includes URL where user should navigate when they select the payment instrument
... second approach is manifest (which resides on paypal.com)
... manifest format (from w3c) is used to specify things like desktop shortcut or home screen launcher

rbarnes: what is payment request handler URI?

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

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.

Rouslan: POST message or javascript or series of events (but might be too much freedom)
... some security folks have suggested we make it as small as possible
... and when vulnerability is found, sites can upgrade quicker than browser updates
... you suggested WebRTC style of API where the user agent provides a pipe between sites

rbarnes: I think that's sort of what you are proposing here but the js of the payment service provider is in the page
... it's not clear to me you will have UX
... maybe starting with HTML
... having HTML visible entry point may be overkill...we need to do some more flows to figure that out.

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.
... one scenario I heard yesterday was "registration of a particular payment instrument service"
... 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"
... 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)
... 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

nicktr: The use cases in the IG were about "how you pay" and not about "how you provision methods"
... that's a gap that we should tackle as a WG

AdrianHB: Another scenario is "out of band" unrelated to browsing, e.g., I install an App as a payment instrument

<Laurent> +1 on the OOB registration from an app

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

<Zakim> m4nu, you wanted to say that we may not want to parameterize in that way - prefer payment method and options

m4nu: +1 to talking about the registration scenarios
... But on Rouslan's proposal: why have both an API and a manifest?
... also, I would like to separate the data formats from the protocols
... also, the proposal is missing a lot of important information; would be good to have an extensible javascript format

<Laurent> +1 to having a JSON rather than parameters in APIs

m4nu: I think what is shown is safe but it presumes that payment instruments will have this set of data and nothing more.

<jheuer> +1 to modeling the instrument in a JSON object format

m4nu: I'd like to define the data a bit more formally.
... Is this set of APIs same as Zach's?

Zach: I had not gone into that level of detail in the explainer

Ryladog: Whenever we do things that we are going to be showing over time, we want to make sure we include accessibility.
... I just want to keep in mind that as we go forward.

Rouslan: Your statement about a native app that might be a provider of instruments.

<padler> 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

Rouslan: given that it's native it would be platform specific in how it registers itself with the browser

<AdrianHB> 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?)

<zkoch> padler: Care to expound? Not sure I understand fully

Rouslan: I'd like to hear your thoughts on accessibility
... The short name in this proposal could be used for things like text-to-speech, or alt text

<padler> 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.

Accessibility considerations

Janina: I'm chair of the accessible platforms wg (charter). We're excited about payments and want to help ensure their accessibility
... also Shane McCarron is going to help work on some accessibility requirements around payments
... what we did with media is talk about disabilities and the impact on consuming media
... we are thinking of a similar approach to payments
... impact of different disabilities on requirements

IJ: We are not specifying UI...do you have guidance on API design?

janina: We don't know all the answers. But for examples, there are topics like "Timeouts"
... some people need more time.
... we may also need to think about the flow overall and user interactions in doing payments
... we need to do some of that to expose what the APIs will need
... I have only one today...I think there will be others.

Ryladog: I think we need to have some guidelines ... such as around the use of biometrics
... I know that there are more than those two things ; we are just starting work on guidance for API designers
... there are other things to keep in mind as spec writers such as ensuring examples in specifications demonstrate accessibility

nick_s: What are some of the challenges people face today when making payments?

janina: Most locking devices on mobile have big accessibility issues.
... if you have not enabled NFC you cannot use it.
... that may not be for w3c to solve.
... we had several things like that in media where simply enumerated things to keep in mind.
... Another ecommerce scenario is something like hearing prices as I am standing in line.
... in terms of online payments, there are questions like a trust service where you don't have to re-enter credentials will be valuable.
... timeouts may be necessary to take into account for some users

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.
... 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.
... for example, there may be (as Janina said) a need to provide timeouts

Janina: if you need a timeout, you almost always need it so you shouldn't have to set it every time.

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.
... so this implies UI and the browser would have to ask permission regardless of the user's accessibility needs.

Rouslan: so we definitely need to be considering accessibility around consent

<Zakim> 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

m4nu: Thanks for coming today; consistent review through the entire spec development process will be valuable.
... having Katie and Shane in the group will be helpful
... Leonie's review was very helpful (and so we now have accessibility considerations throughout the use cases doc)
... 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.
... so those are two requests: (1) regular review (2) demonstrate use of assistive technology with prototypes

<Rouslan> +1 to accessibility demos

<Zakim> AdrianHB, you wanted to discuss UI inputs (information modeling for payment instrument) and suggest a stand-alone guidance document to accompany our rec

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
... also because we are not specifying UI, we may wish to create a companion Note on accessibility guidance for implementers of the spec.

<Zakim> ShaneM, you wanted to ask about guidance on embedded payment windows

(IJ: I think we could consider a companion implementer guide but not limited to accessibility)

<AdrianHB> +1 ian - implementer guide (with accessibility section)

ShaneM: Suppose I am on a site and have an interface for choosing to pay

janina: somebody might want a unique sound that can help me make out when there's a payment event
... I need to then be able to switch focus

Shane: there are also security issues around permissions

Janina: Is there an event requirement in the API (e.g., to trigger a sound)

<Zakim> jheuer, you wanted to create an environment to ease integration of accessibility easier

jheuer: Options could be a key element
... if today we only have PIN and that's a hurdle to some
... but there's a device that also supports fingerprint

janina: I named one benefit - an itemized receipt that you can read is a big deal

<Zakim> nicktr, you wanted to talk about invisible payments and confirmation

nicktr: You raised an important point - an explicit confirmation.
... I think that's spot-on from an accessibility perspective
... but merchants are seeking to remove explicit interactions where they can
... e.g., think of Uber...implicit when you order the taxi.

<nick_s> to be clear though, that model’s no different to many other pre-ordering scenarios

nicktr: There are also issues with cognitive impairments; understanding that an action will cause a payment to happen
... mandated confirmation would be a barrier to adoption
... by some merchants

janina: there are also usability ideas about "consistent styling of information" when types of events happen such as payments

<Zakim> 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

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
... there could be a UI guideline around payments that, if we could get the payments people involved, could be great.

<AdrianHB> 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

<nicktr> manu has the last word

(We should be sure to talk with browser folks about their thoughts on consent UI)

m4nu: Nick asked an interesting question about examples where accessibility requirements come into play
... time required is one issue as has been called out
... another topic that is interesting is when a larger industry push ends up forcing better accessibility
... in the retail space, for example, there's a push to use mobile devices to do checkout
... that can benefit accessibility..people can use their own devices to check out
... if we could enable that scenario through our work, then we might increase accessibility overall

<annbass> I just wondered if there are similar i18n considerations at this point?

m4nu: 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

<AdrianHB> LJWatson: that's a good suggestion. I think this will manifest as data about the user (such as accessibility reqs) being stored by the browser (wallet) and passed (with user consent) to the payment instrument for consideration.

m4nu: are there other things we can annotate in data objects that are either requirements or that enable accessibility tools to build richer UI

<dezell> Note that if any economic incentives are made available through a non-accessible interface, that is a legal liability for the provider.

<dezell> That is the provider's problem, but we must keep it in mind.

Ryladog: There are other data topics like "don't turn data into images that are not accessible in transit"

<LJWatson> AdrianHB Yes, very much I think.

MattSaxon: there will be some bits of information that will be used in UI....

AdrianHB: We need to ensure that the API must include enough information so that the user agent's rendering can be made accessible.

<jheuer> ...I'd even say that the data format will be decisive in many ways to the interactions possible in the UI

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?

shepazu: That would help somewhat but might miss some things like timing.

LJWatson: With eBay where you have auction countdown...you can preset a final amount and let system do time-sensitive bidding
... In some of these APIs, I wonder whether there are mechanisms to declare viable authorization mechanisms
... eg., not using a retinal scan.

AdrianHB: opportunity for browsers to store accessibility requirements and optionally pass them to the payment instrument with the payment request
... there are of course privacy issues

<zkoch> I think this is a platform-level thing

<zkoch> Not something for payment specifically

dezell: There are liability issues [in some jurisdictions for some types of site]
... if site is not accessibility
... like the idea of guidelines for implementers

<AdrianHB> 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...

m4nu: Gates foundation interested in payments work...
... are projects like financial services for the poor to those who don't have means to get it.
... is that an accessibility issue?

katie: It is by the US Fed
... study shows majority of unbanked also have large proportion of disabilities
... mobile can help a lot

IJ: Got other spec guidelines for helping accessibility review?

janina: we have a charter requirement to do something like that

(Cf charter about UI accessibility in implementations)

Incorporating 3rd-party services in client-side JS: lessons from WebRTC identity management

(Dom Hazael-Massieux (DHM), Martin Thompson, Eric Rescorla (ERK) join the meeting)

DHM: we communicate with third parties for identity verification
... might be an interesting model for some payments work. WebRTC has P2P identification for end-to-end encryption (see 9.1 Identity Provider Interaction)
... each peer gets their id validate by a third party identity provider
... in a traditional client-server world you use certificates but can't do that in a p2p world
... want to ensure that the person you think you are communicating with is that person
... the model is that the ID you claim to have is validated by a third party

(Dom shows a communication graph on the screen)

DHM: Suppose you are on w3c webrtc service and want to connect with Adrian on Skype.
... w3c javascript will ask for verification of Adrian, and the verification will be done via JS that was gotten from skype.com
... will be executing code from two entities
... the JS executes in a separate global context
... it has the properties in terms of security and isolation
... also has a lot of flexibility in terms of how the ID provider provides the service

Martin_Thompson: Looks like a Worker
... browser asks questions like "please generate an identity assertion"
... or "I have an identity assertion can you validate it and tell me who this assertion is for"
... ,and the response can be yes or no
... you can hide arbitrarily complex interactions (e.g., checking back at the server). Done safely within a sandbox

UNKNOWN_SPEAKER: you are operating in your own origin; not running code in your own origin
... the code you get from your identity provider is from a well-known URI
... you get it from skype.com
... for example

rbarnes: There is analogy to service workers

AdrianHB: Isolated execution environment with a well-known standard API into that environment from the browser.

Richard; We define that API in IDL

scribe: 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

DHM: How does it apply to payments?
... in payments you will likely have identity management...so this might be useful to you

scribe: more generally it's useful for third party integration

DHM: I thought the model was interesting enough that might inspire you for the payments APIs

<Zakim> 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

m4nu: We are talking about identity and identity integration and a number of payment use cases require strong identity.
... open question in this group on how to do this
... 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.
... that's one question (for the TAG).
... do you think that this group could just reuse the identity integration mechanism that you've built?
... we do need to verify identities...do you think it could be fit or extended for payments on the web

Richard; I don't know what identities you intend to create and consume in this content.

scribe: there are a number of assumptions here that are bound to the context in which this work operators
... one necessary piece is that the assertion you make is bound to a "context"
... the way this is constructed, the IDP sandbox doesn't need to know; the browser is responsible
... the IDP only sees a string that they want someone to attest to
... the model is simple and might be useful (produce -> consume) but you might need to tweak it

Laurent: I am interested in understanding the drivers behind the choice to have the IDP verify the credential rather than defining a fully verifiable credential outside the IDP.

Martin: We did a survey of technologies early in this process and determined there was no commonality among these things.
... we needed generation and verification of assertions
... whether these technologies did that was uncertain
... our approach of "providing code" enabled the impedance mismatch
... took away need to agree on algorithms etc.
... boiled down to "please create an assertion" and "is this assertion valid"

rbarnes: If we want to support a lot of payment systems we will likely want to support something like this

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
... if you support these two operations you can interop with webrtc

Martin: We discussed a proposal ... you can take the same interface to a sandbox and codify in an HTTP request..that's relatively straightforward
... the information that traverses that interface is relatively well-defined

jheuer: +1 to that kind of flexibility
... What did you not find specifically in openID connect or other solutions?

Martin: Commonality
... You duck a large number of interop issues by doing it this way

jheuer: So can you imagine a common credentialing / identity interface to use this context across different application fields?
... webrtc is not the only one that requires bi-lateral interaction?

Martin: Yes, I think the pattern could apply to other domains.
... but we'd need to try a few times rather than forecast universality of the approach

EKR: Sounds more like FIDO to me

<Zakim> AdrianHB, you wanted to suggest this model may be useful for "hosting" a payment instrument however it doesn't deal with UI

AdrianHB: In a conversation with Richard this came up....part of this was applying this model as the way to get payment instruments

<dom> Identity Provider Interactions in WebRTC API

<dom> Provider Interactions in WebRTC API

Martin: as opposed to downloading code from an origin, you fetch code that performs payment instrument operations
... but no UI it seems. In our conversations, the conclusion was that sandbox would reject things since UI needs not met
... the least well tested part of the API is sending user to another site for interactions with user.

AdrianHB: So the standard is how to fetch execution logic.
... this may be a way to handle payment instruments in cases where there is no UI
... could have a URI where user interactions are required
... but where not, could specify something like a URI where you fetch code to execute

Martin: That particular cat can be sliced a number of ways

<Zakim> padler, you wanted to ask about assertions/assumptions that IDP can make about ID consumer execution environments

padler: Are there assertions or assumptions that Identity providers can make ...e..g., I need to enforce that both browsers implement something in a particular way?
... also, as we are looking at browser interactions, there are some interesting use cases around P2P payments

Martin: A lot of what this enables in WebRTC is effectively UA-to-UA communications
... one use is to create isolated media...I can send you things without site involvement (they can't see or change the media)
... exposing APIs to make information available within that context is relatively straightforward...you can add payment specific hooks if you need them

padler: I can imagine there would be identity providers for certain use cases in the payment space, where the community is a restricted subset.
... the origin has available all the information it would have on a regular page
... 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
... that information can be put into the sandbox
... that's where the next level of power comes from...you can't do this with declarative forms
... we thought that was pretty powerful

<Zakim> 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?

m4nu: One thing is the design pattern; another is the implementation in the WebRTC spec

Martin: It's more loosely coupled than you'd think

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.
... I noted that other groups are also thinking of doing the same thing (TAG discussion as I mentioned)

<gjaya> wouldn't naming conventions matter? ie do they have a 'package' independent of webrtc?

<Zakim> AdrianHB, you wanted to suggest this might also be a way for payment instruments to verify request data from the merchant/payee

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
... 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.

<Laurent> +1 to verifying the merchant

EKR: The question is what are the invariants from the paying side
... in order to produce a payment, what do you need to know

AdrianHB: The way I see this working is you are on a merchant web site....payment request made ...

ERK: there is "bound" and there is "verified" and that's not the same thing

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"

ERK: Let's take something less straightforward than Merchant number
... Distinguish that which needs to be supplied to the payment instrument and ....

rbarnes: the API that the identity provider sees is different from the API that the web page sees that is making the call
... the identity provider thinks in terms of signing and verifying assertions
... the web page thinks in terms of identities.
... the browser's role is to take that identity and present it to the identity provider
... the group needs to think about what the receiving might want to see and what the payment instrument would provide

CyrilV: Regarding the payment constraint, we should have in mind to respect the contractual links of payment systems
... merchant has a contractual like with his service provider....and user with his/her service provider...crosschecking would be difficult and perhaps not useful

AdrianHB: I propose we consider this just in terms of verifying data
... it doesn't have to be integral to the payment process itself
... it's something we can look at as an option ... how we verify data being passed around

<m4nu> End of day discussion: we should review "things we agree on"

<MattSaxon> 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 assigned people

W3C Testing How-To

(Philippe Le Hégaret joins the meeting)

<m4nu> Testing Howto (in Github)

Philippe: presents testing at w3c
... testing is complicated
... starting point is "Test the web forward"
... we don't care about the w3c process
... but w3c can make use of the TTWF project
... Fixing the web is a lifetimes work
... The good news is that submitting stuff via TTWF automatically tests with some browsers. The testing infrastructure is all there
... the science of browser testing is imperfect
... API tests via testharness.js

(Philippe demonstrates on screen)

Philippe: testharness.js supports assertions, asynchronous testing
... metadata is minimal
... assessing coverage is problematic. reftest not applicable (needed for screen display)
... manual tests are sad tests
... describes visibility change example
... Web IDL tests will make you cry because browser implementations are imperfect
... client-server tests we have two examples: xmlhttprequest and web sockets
... we don't expect people to use web platform test server
... if the server is up you can use it
... but the preference is to do a local install

<Zakim> 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/?

manu: we are going to have 3 types of testing: browser apis, serverside http api, web driver
... the last is not supported by ttwf
... if we were to write web driver tests, are there requirements to ensure future compatibility

jgraham: one of our goals is to allow you to do the testing from one html file
... if you write a test today, it feels like in 6 months time you should be able to use that
... prompt dialogues aren't supported but you can think about extending web driver for that sort of thing
... for example we are looking at bluetooth but the pattern isn't there yet

<Zakim> shepazu, you wanted to ask about autogen tests

doug: do you have a pattern for json-ld?

(manu: whispers it's not needed)

ShaneM: is it providing data factories?

phillipe: no

ShaneM: your not exercising the methods, just checking that they exist

Philippe: correct

dezell: client-server: do you write your own server?

phillipe: no, we have code to do that
... we don't need to know ip or local name, we have meta-syntax to let those tests auto-generate
... we have IDNs (?) as well

shaneM: I brought up the environment on a virtual server in 20 minutes. well played.

Philippe: as a WG you need to convince the Director - one of the ways is to prove you have the test suites
... results. Stick them in the w3c/test-results repo is one approach
... we'd ideally like the results directly form the browser vendors
... There are two kinds of licenses. WG doesn't have to worry. All sorted.
...Strategies: don't wait until the last minute
... No mods without tests
... find a leader who can understand w3c/web-platform-tests and get them to guide the group
... there are no w3c dedicated resources
... but the docs are pretty good
... and there is an irc channel: #testing

<Zakim> AdrianHB, you wanted to clarify process

adrianHB: to clarify. the WG will write as we go locally but submit to TTWF repo ?

Philippe: Correct
... Submitting early heads off mistakes

AdrianHB: we are hoping to be iterating on tests and recommendations rapidly

Ian: a long time ago (2005) there was a QA Framwork Spec guidelines was published
... do the test folks have more up to date guidelines for TTWF style tests

jgraham: be careful with respec

ShaneM: don't do what RDFA did with regard to algorithms

adrianhb: can you tag things in respec to mark things for testing?

phillipe: there's no tool for that

jgraham: there _are_ tools but there is not usually a mapping between must statements and tests

phillipe: (shows directory listing of web-platform-tests repo)
... web socket server running inside each server, supports TLS

ShaneM: is there a driver to run over collection of tests

Philippe: We have a little test runner
... (shows runner)
... takes a directory as an argument
... only runs js tests
... Better way is to you WPTrunner
... runs on Firefox and chrome. Working on Edge. No safari
... advantage of the latter is that can run reftests
... and makes it more tolerant of browser crashes

ShaneM: does EARL still exist?

Everyone: nope. move along. nothing to see here.

Philippe: we don't want anyone to run manual tests

<m4nu> NO

(schepers explains the role of test lead. Test wrangling is the principal role)

<Ian> (Shane volunteers to lead the test work)

ShaneM volunteers magnificently

<Ian> Other people who will be interested in writing tests: m4nu

AdrianHB: any volunteers for testing writing.

Manu: we will be writing tests

Schepers: anyone writing product will be writing tests

How we will work

sub-topic: tooling

<zkoch> +1 to github

<zkoch> Github ALL THE THINGS

nicktr: I suspect that there is consensus on using GitHub as our primary collab tool

<Ian> https://github.com/w3c/webpayments

(chair notes no objections)

nicktr: to clarify; will we use the wiki functions of GitHub

manu: limitations on GitHub to history

ian: there is a commitment to persist work product and also to use neutral tools
... we don't need to be rigid if everyone can access the tool
... begs the question, what will we use the mailing list for

nicktr: GitHub has a notification framework should this be wired to the mailing list

<Zakim> ShaneM, you wanted to talk about the purpose of the mailing list

adrianba: it's possible, is it desirable

shanem: mailing list will be used for agenda's and other discussion
... it makes sense to be able to archive what goes on in GitHub

<Ian> (There are also discussions of archiving github repos on w3.org...another topic for another day)

shanem: we could wire event hooks from GitHub to services at W3C so they are persisted

shepazu: there are tools to do this
... everything is being archived

nicktr: is w3c archiving everything on GitHub

shepazu: there is an automated publishing framework that lets us push drafts from GitHub to the site

<Zakim> m4nu, you wanted to mention github tracker vs. being able to track stuff against spec + mailing list

shepazu: to clarify, we have talked about taking snapshots of the GitHub content but are not doing that now

manu: let's just use GitHub issue tracker as this helps with our responsibility for tracking comments

m4nu: how do issues mentioned in the mailing list get into the issue tracker?

<Ian> ACTION: Shepazu to look into connectivity in both directions between a mailing list and github repo in both directions [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action02]

ian: there appears to be an action to investigate how to do this?

adrianba: Microsoft opinion is we should no longer use mailing lists for technical discussions because using something like GitHub allows the discussion to be threaded, tagged, closed and explicitly re-opened. Mailing lists are open to abuse of the status of an issue

GitHub allows you to subscribe to issues if that's what you want

scribe: 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.
... The mailing list does have value for meta discussion

shepazu: Minutes are not filed but often issues are raised in meetings. Suggestions for addressing this?

adrianba: The practice that is encouraged is that if issues are raised in the call they are filed at the time and referenced

<zkoch> +1

adrianba: same applied on the mailing list

shepazu: does anyone have a problem with using GitHub

<Ian> NickTR: I can't get to github from my corporate account

nicktr: But this isn't an issue for me. Are there others with similar issues?

cyril: not sure

kris: we don't have access but I can work around this

shepazu: I believe it is possible to mail responses back to GitHub

Ryladog: Do we have experience with using GitHub for the WG functions

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.

<Zakim> 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.

adrianba: there is a rec that was created using GitHub

m4nu: +1000 to using GitHub but I worry about excluding non-technical or other stakeholders
... we will exclude people but I think we still want to use GitHub

ian: to clarify the only thing they can't do is make submissions?

<Ian> 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

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

MattSaxon: The flows collaborators are all potentially being excluded

nicktr: MattSaxon will look at solving this

Laurent: Can we migrate any prior work to our new repo

shepazu: if they are specs then they should be at the W3C root repo other stuff
... at the group repo

<kris> just to correct myself: i do have github access (joehoe!)

Cyril: Can we get an email that summarizes this

sub-topic: meeting cadence

nicktr: there is a request that we accommodate our participants in the East

proposal is to run weekly meetings and alternate the time to be morning (UTC) and afternoon (UTC).

<ShaneM> +1 to the alternating schedule

mattsaxon: is the expectation that people will attend them all

<nick_s> skeptical manu is skeptical

nicktr: no, but people will attend the late/early one if they feel they need so

manu: (observes that most WGs start like this but change if participation drops)

shepazu: let's start this way but I agree that often the participation drops off let's handle this when it happens

sub-topic: face to face

nicktr: do we want 2 or 3 f2f meetings next year

manu: there is a lot of other payments stuff going on, 2 is enough

nicktr: proposal then to do 1 near end Feb in USA (West Coast) backing the IG f2f and one other

padler: when will we start calls?

nicktr: propose we start calls week after next but will figure out a good time in the interim

<Zakim> padler, you wanted to ask when we start calls?

<nicktr> ACTION: nicktr to set up questionnaire to find best day for weekly meetings [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action03]

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

<adrianba> +1 to meeting between feb and tpac

<nicktr> +1 to meeting between feb and tpac

shepazu: perhaps we should try to meet at a time and place that members are already getting together
... and then also TPAC

nicktr: feels like there is a desire for a mid-year meeting but let's put off planning that for now

dezell: if we don't plan the Feb meeting now we might not
... 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)

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)?

Next steps

IJ: IG relationship - future reviews, chairs can decide to meet from time to time; joint meeting end of February

Dezell: IG meeting weekly 10am ET Monday...planning to continue that for now

NickTR: Any other comments/concerns about running the group?

jheuer: I can't join the group officially for now; I hope the IG remains a place where we can connect

<zkoch> Feb 25, 26, 27?

<zkoch> Are those the dates?

<zkoch> Things are looking good to host

(Could be those dates or any time that week

<zkoch> I just need to submit a finalized request, which I’ll do today or tomorrow

<zkoch> Okay

<scribe> ACTION: nicktr to write up the group operations in a wiki (re email, issues, etc.) [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action04]

<trackbot> Created ACTION-1 - Write up the group operations in a wiki (re email, issues, etc.) [on Nick Telford-Reed - due 2015-11-06].

adrianba: Against my better judgment I'm volunteering to help NickTR with the work mode document

<nicktr> http://bit.ly/1NEkkz8

Nick: Timelines?

<nicktr> https://docs.google.com/document/d/1yJEba_BCUK0Q1nCaD2sGM4h6HxxxEcT15ruRlvowr7o/edit?usp=sharing

Manu: 1 month?

adrianba: I've learned a bunch of lessons from the discussion and that inform the feedback on the proposal.
... my goal is that we take those lessons and incorporate them as soon as we can.
... I don't think I could predict a good time frame for making a decision on the future of the alternate proposals.
... but if we weren't having substantive discussions comparing the proposals in November then I think we would be failing the group

AdrianHB: So we need a milestone for "feedback has been incorporated"

m4nu: There are big issues we need to resolve like "does linked data play a role?" or "is remote storage in scope?"
... by having those discussions I think they reflect what's actually in the proposals.
... I don't think the specs need a full rev before we start discussion of the stickier issues
... we can rev the specs quickly while we are having the discussions

AdrianHB: How do we feel about documenting issues in github
... i mean the high-level discussions
... 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

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
... it's incumbent upon us to make a start on that.

<AdrianHB> ian: let's allow anyone to also submit issues

<scribe> ACTION: AdrianHB to start documenting general issues and inform WG of initial pass so they can add to the list or add comments [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action05]

<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

adrianHB: Then we can prioritize them based on the ones that are getting the most discussion
... I think we have a good todo list.

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

Adrianba: I think there is agreement we should discuss the various kinds of registration.
... but I don't agree we've decided in which forms there should be

AdrianHB: Anybody want to step up to lead discussion on registration scenarios?

<scribe> ACTION: adrianba to write up list of registration scenarios he he mentioned in more detail [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action06]

<trackbot> Created ACTION-2 - Write up list of registration scenarios he he mentioned in more detail [on Adrian Bateman - due 2015-11-06].

Laurent: I think we also agreed to define a payment request data format.

AdrianHB; Registration request as well

RESOLVED that we agree upon the following summary

<rbarnes> https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

<rbarnes> for context: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/


NickTR: Thank you to all! I hope you will continue to participate
... do your actions
... we will only be successful if we move things forward
... I look forward to meeting you on IRC, WebEx (and of course github)

Summary of Action Items

[NEW] ACTION: adrianba to write up list of registration scenarios he he mentioned in more detail [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action06]
[NEW] ACTION: AdrianHB to start documenting general issues and inform WG of initial pass so they can add to the list or add comments [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action05]
[NEW] ACTION: MattSaxon to lead discussion among volunteers about creating flows and diagrams [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action01]
[NEW] ACTION: nicktr to set up questionnaire to find best day for weekly meetings [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action03]
[NEW] ACTION: nicktr to write up the group operations in a wiki (re email, issues, etc.) [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action04]
[NEW] ACTION: Shepazu to look into connectivity in both directions between a mailing list and github repo in both directions [recorded in http://www.w3.org/2015/10/29-wpwg-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/11/06 17:19:36 $