16:52:41 RRSAgent has joined #wpay 16:52:41 logging to http://www.w3.org/2015/02/26-wpay-irc 16:52:59 zakim, room for 15 for 90 minutes? 16:52:59 sorry, manu; could not schedule an adhoc conference; passcode overlap; if you do not have a fixed code you may try again 16:53:09 zakim, this is wpay 16:53:09 manu, I see T&S_WEBPYMT(WPAY_USE)12:00PM in the schedule but not yet started. Perhaps you mean "this will be wpay". 16:53:23 zakim, this will be wpay 16:53:23 ok, manu; I see T&S_WEBPYMT(WPAY_USE)12:00PM scheduled to start in 7 minutes 16:53:38 rrsagent, make logs public 16:53:41 rrsagent, draft minutes 16:53:41 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html manu 16:57:13 T&S_WEBPYMT(WPAY_USE)12:00PM has now started 16:57:15 T&S_WEBPYMT(WPAY_USE)12:00PM has ended 16:57:16 Attendees were 16:57:27 zakim, this will be wpay 16:57:27 ok, manu; I see T&S_WEBPYMT(WPAY_USE)12:00PM scheduled to start in 3 minutes 16:58:16 T&S_WEBPYMT(WPAY_USE)12:00PM has now started 16:58:24 + +1.540.961.aaaa 16:58:32 zakim, aaaa is me 16:58:32 +manu; got it 16:58:57 halmas has joined #wpay 16:59:10 +manu.a 16:59:25 zakim, manu.a is dlongley 16:59:25 +dlongley; got it 17:00:01 +dlongley.a 17:00:18 zakim, dlongley.a is dlehn 17:00:20 +dlehn; got it 17:00:22 + +1.703.628.aabb 17:00:23 +dlehn.a 17:00:30 zakim, call Ian-Office 17:00:30 ok, Ian; the call is being made 17:00:30 zakim, dlehn.a is omalik 17:00:32 +omalik; got it 17:00:32 +Ian 17:00:46 zakim, aabb is halmas 17:00:46 +halmas; got it 17:02:39 dezell has joined #wpay 17:02:54 +dezell 17:03:51 zakim, who is on the phone 17:03:52 I don't understand 'who is on the phone', dezell 17:04:06 jean-yves has joined #wpay 17:04:22 zakim, who's here? 17:04:23 On the phone I see manu, dlongley, dlehn, halmas, omalik, Ian, dezell 17:04:24 On IRC I see jean-yves, dezell, halmas, RRSAgent, Zakim, Omar, dlongley-db, chaals, dsr, manu, wseltzer, Erik, Ian, dlehn, Karen 17:05:16 +jean-yves 17:05:23 zakim, call dsr-office 17:05:23 ok, dsr; the call is being made 17:05:24 +Dsr 17:05:25 Laurent_ has joined #wpay 17:05:47 Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0050.html 17:06:00 regrets+ wseltzer 17:06:19 + +33.1.55.01.aacc 17:06:38 zakim, +33.1.55.01.aacc is me 17:06:38 +Laurent_; got it 17:07:10 +1 to change 17:07:13 +1 17:07:17 scribe: manu 17:07:18 +1 17:07:28 manu: Any objections to change agenda to talk about Ian's slides? 17:07:46 manu: ok, no objections - any other changes/additions to agenda? 17:07:55 Topic: Organizing Web Payments Use Cases 17:07:59 http://www.w3.org/2015/Talks/ij-usecases/ 17:08:08 http://www.w3.org/2015/Talks/ij-usecases/?full#1 17:08:28 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html 17:08:34 Ian: Thanks for accommodating, I had started to look at the use cases document, 3.1 17:08:36 -jean-yves 17:08:55 Ian: I thought I'd try to do something w/ it - I struggled, I needed a backgrounder up front - a mental model. 17:09:15 Ian: I started to play with that - chatted with Manu to try and get a baseline sanity check on it - but we wanted to have it in time for the meeting. 17:09:28 http://www.w3.org/2015/Talks/ij-usecases/?full#2 17:09:47 Ian: This is just a proposal - Laurent's review of it was very helpful. Two main questions that come out of that review - those have been added to end of deck. 17:10:11 +jean-yves 17:10:16 Ian: Wanted to distinguish the goals for this slide deck w/ use cases - different goals for this slide deck. This proposal is meant to give a simplified view of one or more payment flows. 17:10:38 Ian: Several reasons for this deck - it's challenging to understand all the detailed scenarios that all of you already know. 17:11:07 Ian: second reason - it helps to have a simple model in mind so that when you get to use cases, you know how they relate to one another. 17:11:13 q+ to ask about "do not overlap" on slide 3 17:11:17 Ian: Once we see how they relate, it's easy to see where the gaps are. 17:11:33 Ian: Another thing I felt at the face-to-face meeting, some of the use cases overlap - why? 17:12:13 Ian: For example, use case where someone picks one payment instrument out of a digital wallet, or two - are they similar enough that we should get them into the same use case? 17:12:27 Ian: Or maybe they're not different - we need to understand that we're not duplicating use cases. 17:13:11 Ian: recognize at the same time that many other efforts in industry have done something like this - Manu pointed me to previous work a month and a half ago wrt. phases of transaction. We want to align w/ what others have done, we want to make sure that by being simple, we're not giving the false impression that we're not aware of the other stuff out there. 17:13:23 Ian: This is a starting point, we need to bind to ISO20022, ISO12812, etc. 17:13:26 ack dezell 17:13:26 dezell, you wanted to ask about "do not overlap" on slide 3 17:13:36 dezell: You examples were fine, I get that. 17:14:07 dezell: Obviously overlap is going to be almost impossible to avoid, we do want to reduce it as much as possible. 17:14:34 dezell: I want to make sure that people in W3C understand this document, but people outside should really understand it as well. I know X9 has done this sort of exercise before - we should be aware of that. 17:15:02 Evgeny has joined #wpay 17:15:03 dezell: Channelling Erik - we have ISO20022 - european way of looking at everything payment - there is a natural business lens that you can look at this stuff through. 17:15:25 dezell: That's an aside - we could gain credibility by making sure we link to ISO20022. 17:15:26 q+ 17:16:00 manu: Yes, we need to show how all the bits map to iso20022 and other docs 17:16:27 http://www.w3.org/2015/Talks/ij-usecases/?full#4 17:16:43 Ian: One of the thoughts is that we have one simple framework - all primary financial transactions we have in mind can be put into that framework. 17:16:48 Ian: Overall, it should just work. 17:17:03 Ian: Laurent said he's not sure that it does, but we do want to try. 17:17:07 Ian: We do want to discuss this later. 17:17:15 +1 to David's suggestion to link to industry's standards 17:17:17 Ian: In this presentation, we could have a single flow description. 17:17:34 Ian: So keep that in mind as we're going through this slide deck. 17:17:38 http://www.w3.org/2015/Talks/ij-usecases/?full#5 17:17:44 Ian: So this is broken into 3 phases... 17:17:47 q+ to ask about "flow" 17:18:00 1. Payer Initiates Payment 17:18:00 2. Payee Receives Payment 17:18:00 3. Payer Receives Product/Receipt 17:18:01 ack manu 17:18:21 Ian: One of the goals of the description is to not take exceptions into account - that'll complicate the simple model. 17:18:35 q+ to discuss 4th phase 17:18:37 Ian: Again, Laurent said that maybe 4 phases is a better approach - would love to hear from him on the call - at the end of the call. 17:18:51 http://www.w3.org/2015/Talks/ij-usecases/?full#6 17:18:56 Ian: Each phase has multiple steps 17:19:09 Ian: I give money to someone, the get the money, I get my stuff, basically. 17:19:21 Ian: I gave some examples of how some steps are skipped/ignored. 17:19:40 q? 17:20:01 q- 17:20:17 Laurent: I can wait on my comment until the end. 17:20:44 dezell: I like these, I also like the 4 phases, I can think where these things happen in some other order... maybe we should talk about "flow" or "steps" 17:21:00 dezell: In order to come up with something universal - the moment we force an order, we may have to add other steps. 17:21:19 dezell: I think for our primary actors in our charter - payer/payee - these are the three things in payment that count. 17:21:26 dezell: we may lose the narrative elsewhere. 17:21:37 Ian: So when we talk about steps/phases/flows - we need examples that don't fit. 17:21:51 Ian: Concrete examples where it's a bad fit would be helpful. 17:21:57 http://www.w3.org/2015/Talks/ij-usecases/?full#7 17:22:09 Ian: Going faster through these in order to get to the discussion. 17:22:42 Ian: Discovery of Offer, Agreement on Terms - lots can happen in here, we can touch on specifics like authentication deeper in the use cases. 17:22:56 Ian: Selection of Instruments and Authorization to Access Instruments. 17:23:03 http://www.w3.org/2015/Talks/ij-usecases/?full#8 17:23:08 Ian: Steps for Payee Receives Payment 17:23:21 Ian: Verification of Available Funds. In some cases, Payee may need proof of funds or proof of hold before finalizing payment and delivery of the product. 17:23:27 Ian: Authorization of Transfer. Payee receives proof that the transfer of funds has been authorized. 17:23:35 Ian: Based on Laurent's comments, I tweaked the text. 17:23:50 Ian: unfortunately, slide content disappears at bottom at slide 8 - I'll fix that... 17:24:07 Ian: Funds Transferred. The actual transfer of funds will be initiated (e.g., by a merchant, customer's payment processor, acquiring or issuing banks, etc.) and carried out in a variety of (scheme-dependent) ways. Time can be immediate transfer, or delay of 2-7 days, etc. 17:24:12 http://www.w3.org/2015/Talks/ij-usecases/?full#9 17:24:34 Ian: Delivery of Product. Payer receives goods or services immediately, at a later date, automatically on a recurring basis, etc. depending on the terms of the purchase. 17:24:39 Ian: Delivery of Receipt. Depending on the payment scheme(s) chosen, there are various ways and times that a receipt may be delivered (e.g., credit card receipt, digital proof of purchase, etc.). 17:24:48 http://www.w3.org/2015/Talks/ij-usecases/?full#10 17:25:01 Ian: So, maybe the steps aren't perfect... point taken, but maybe general arrangement is good. 17:25:27 Ian: Coming at this as a reader trying to understand what we are doing - maybe this is better than priority-order. 17:25:45 Ian: As Laurent mentioned, we're hinting about how these might be expressed. 17:25:52 http://www.w3.org/2015/Talks/ij-usecases/?full#12 17:26:08 Ian: So, there are alternative ways of achieving each sub-step... for example, payment initiated via browser, or via mobile app. 17:26:24 http://www.w3.org/2015/Talks/ij-usecases/?full#13 17:27:11 Ian: This is about revealing personal information - the use cases felt similar to me - could be described under similar use case - in one case you have to have an account and login, in another one you need to tell the payee who you are, but you may not need an account, and third one is no need to identify, no need for account. 17:27:29 Ian: I'd like that these don't overlap - I want to make sure we're not describing things that are essentially the same, but saying they're different. 17:27:36 Ian: If they are different, we need to be very clear about it. 17:27:41 Ian: That's all up for discussion. 17:27:52 http://www.w3.org/2015/Talks/ij-usecases/?full#14 17:28:34 Ian: Some use cases that are not prioritized - put them in there anyway - term negotiation. Sometimes merchant might want to tell customer about instrument. Agreement of terms will affect selection of payment instrument. Or machine-readable negotiation is an optimization. 17:28:46 Ian: Assisted term negotation is the key point here. 17:28:51 http://www.w3.org/2015/Talks/ij-usecases/?full#15 17:29:05 Ian: Manual selection of payment instruments vs. assisted selection of instruments. 17:29:20 Ian: I'm trying very hard to make them not overlap... assisted selection vs. manual selection. 17:29:43 Ian: Again, these are things that seem to suggest that things might affect users' selection of payment instrument. 17:29:48 http://www.w3.org/2015/Talks/ij-usecases/?full#16 17:30:03 Ian: Manu said proof of funds and proof of hold may be appropriate here. 17:30:11 http://www.w3.org/2015/Talks/ij-usecases/?full#17 17:30:29 Ian: These are manu's additions as well - these might be good items for authorization of transfer... 17:30:35 http://www.w3.org/2015/Talks/ij-usecases/?full#18 17:30:47 Ian: I just wanted to point out here that some delays may happen in here. 17:30:51 -Laurent_ 17:30:58 q+ to mention 3-corner / 4-corner 17:31:01 ack dezell 17:31:01 dezell, you wanted to ask about "flow" 17:31:25 http://www.w3.org/2015/Talks/ij-usecases/?full#20 17:31:28 ack 17:31:31 ack manu 17:31:31 manu, you wanted to mention 3-corner / 4-corner 17:31:48 +Laurent_ 17:31:53 manu: not sure where 3 corner or 4 corner fit into this. 17:31:56 q+ 17:32:03 manu: I think slide 17 is a good place for that. 17:32:12 q+ 17:32:41 manu: just because it doesn't say "push/pull" or "3 corner/4 corner" doesn't mean that's out. 17:32:59 Ian: There's an interesting question about whether the simple model needs to spell out deep technical details about how payment schemes work. 17:33:21 ian: it's not clear whether we should mention these things parenthetically, or have the use cases carry the load of the terminology. 17:33:30 Ian: Maybe parenthetically these things are mentioned, but we don't want to overburden the framework w/ talking about those things. We need to make sure that the people that are looking for that know what's going on. 17:33:58 jean-yves: This is interesting - so far, I feel a bit ??? about it. I don't identify the payment service providers in here - where are they? 17:34:17 jean-yves: I can't imagine any scheme without defining who are the payment service providers. 17:34:41 jean-yves: for one, in the 3 corner or 4 corner schemes, so far not having the PSPs in here is problematic. 17:34:58 Ian: My goal would be that at that level of abstraction, you don't need to know who a PSP is - use cases can talk about payment service provider. 17:35:18 Ian: If I want to go to a store and get my things - I don't know anything about payment service provider. If we can introduce people to the topic w/o that level of detail. 17:35:21 Ian: That would be good. 17:35:35 Ian: We also need to show how real payment schemes fit into this model. That's mentioned a little further down. 17:35:59 jean-yves: I don't agree - you may not know who is the payment service provider - the PSP is the one that enforces the rules. If you don't know the rules, you don't pay. 17:36:09 agenda+ Exposing the rules of a payment scheme 17:36:13 Ian: Let's add that to the agenda - Exposing the rules of a payment scheme. 17:36:18 agenda+ Number of flows and phases 17:36:27 q? 17:36:30 ack jean-yves 17:36:32 ack jean-yves 17:36:32 q+ to suggest we consider the target audiences for our use case work 17:36:35 ack Laurent_ 17:36:35 david: Katie has provided an email (ref slide 17) about how order might change. https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0079.html 17:37:00 (Dave, see goals: "Introduce a simple payment processing framework to so that all readers understand how use cases relate to one another and how, together, they represent a logical sequence of payment activities.") 17:37:00 Laurent: I just want to clarify - your presentation focuses on customer and merchant - I like that, most of the work of the group should be focused there. 17:37:12 Laurent: I'm wondering why 3-corner / 4-corner isn't mentioned or push vs. pull. 17:37:47 Laurent_: By focusing on interaction between merchant/customer, we definitely put the PSPs and acquirers and issuers on the sideline. That might be a good thing to scope the discussion. 17:38:21 Ian: It's true that it's not clear to me where the details will come in. For example, it could be that some use cases are one level of detail down in a piece of the overall flow. 17:38:27 Ian: You still don't need to know what's going on in the background to know the use case. 17:38:39 Ian: We may have to surface two different use cases to talk about detailed flows. 17:38:46 q+ to mention that we still keep the use cases we have. 17:38:53 Ian: This is the framework, not the use cases. 17:39:23 q? 17:39:24 Ian: We will see the exact exchange of data of all parties at the level of detail of who the PSPs, acquirers, etc. are. It's complementary work to high-level discussion. 17:39:27 ack dsr 17:39:27 dsr, you wanted to suggest we consider the target audiences for our use case work 17:39:27 q+ to ask about 1) clarification of Laurant's view, and 2) iteration of this model 17:40:00 dsr: I like the analysis - who is the target audience. Are the use cases for the end user? We don't need any technical detail in that case. 17:40:27 dsr: Or, do we have analysis from a technical expert perspective? Then we have people that are interested in this stuff from a "what does this mean for the Web?" perspective. 17:40:49 Ian: Todays answer to that question - this framework which lives at beginning of use cases document is for both the web community and the payments industry. 17:41:15 Ian: This high-level is for everybody, then the use cases will dive into the details for payment industry folks. 17:41:33 s/I feel a bit ???/I feel puzzled 17:41:35 Ian: I don't have info yet on how to talk to Web community... good point, and part of that may emerge when we start to hear from browser vendors. 17:41:42 q? 17:41:44 ack manu 17:41:44 manu, you wanted to mention that we still keep the use cases we have. 17:41:44 ack manu 17:42:11 manu: Ian is not proposing we get rid of use cases; this is a framework for organizing the ones we have 17:42:38 ...this is a high-level explanation of flow, then you get to the use cases for more detail 17:43:00 ...so when the document is done, there will be material for people who are new to the topic, and also for veterans who can dig into the details in the use cases. 17:43:12 ...and they will understand that we are talking about 3/4-corner, regulatory issues, etc. 17:43:12 ack dezell 17:43:12 dezell, you wanted to ask about 1) clarification of Laurant's view, and 2) iteration of this model 17:43:34 dezell: First of all, thanks Ian for all the hard work. It's a thankless job to try and simplify this - this is the right thing to try. 17:43:41 dezell: Three points... 17:43:57 dezell: 1) The role of iteration in this taxonomy that you're proposing. 17:44:08 dezell: 2) Can we adopt this as a move forward strategy? 17:44:31 dezell: 3) I'm not quite clear on Laurent's view 17:44:48 dezell: So far everything I see here looks good, we need to make this into a living taxonomy and I think we need to use it to move forward. 17:44:59 agenda? 17:45:14 Ian: Let me finish and I'll pick up the next agenda item. 17:45:51 Ian: if this is done well - at the front of the document, that would be good. People should be able to navigate easily once they've understood the high-level. 17:46:27 Ian: We know that people will need to understand how the flow works. My favorite payment scheme, how does it work in this framework. 17:46:58 Ian: If there are other flow models that are in usage in other parts of industry - especially ones that are widely accepted (liek ISO20022), don't know about those - please suggest ones we can re-use. 17:47:06 manu: Erik should chime in wrt. ISO20022 17:47:22 Ian: Dave made a good point, we'll have to make sure browser vendors see what this makes for them. 17:47:37 Ian: here's an example of a person-to-person payment scheme: http://www.w3.org/2015/Talks/ij-usecases/?full#22 17:47:46 Ian: Very rough analysis to illustrate what I mean. 17:47:53 q+ to mention the time. 17:48:09 Ian: Refunds - http://www.w3.org/2015/Talks/ij-usecases/?full#23 17:48:28 Ian: I still didn't do my actual action item to work on 3.1 - but if we start to adopt something like this, that'll affect the templates for the use cases. 17:48:33 q? 17:48:37 agenda? 17:48:39 ack manu 17:48:39 manu, you wanted to mention the time. 17:48:51 zakim, take up item 2 17:48:51 agendum 2. "Number of flows and phases" taken up [from Ian] 17:49:00 Topic: Number of Phases/Flow 17:50:16 Laurent: In description of phases, first phase - payer initiates payment - what you put as steps in this phase - it's the steps diagram - select the item, agree on terms, pick payment facilities - purchase part of payment flow. 17:50:26 -> https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0071.html Laurent comments 17:50:30 Laurent: interesting to separate purchase part from payment part. 17:50:51 Laurent: What sort of instrument does payer have - what do you select/trigger - 4 phases 17:50:58 Laurent: payer initiates the purchase. 17:51:12 evert has joined #wpay 17:51:32 Laurent: That's good - contains offer discovery, add optional step - coupons/loyalty overall selection of payment - payment trigger phase. 17:51:51 Laurent: Related to right implement to do the payment, trigger the payment processing - either on merchant side or payer side. 17:52:06 Laurent: After the payment figure case - payer receives payment... slide 8 and 9 - don't have much comments. 17:52:12 q? 17:52:13 Laurent: You integrated most of my comments already 17:52:14 q+ 17:52:19 q- 17:52:26 q+ to ask Laurent if he things this is a good way forward? 17:53:16 ack manu 17:53:16 manu, you wanted to ask Laurent if he things this is a good way forward? 17:53:32 Manu: Not quite ready to speak to 3 phases or 4 17:54:12 Manu question to group: Can we turn slides 1-10 into the intro of the use cases docs 17:54:29 Laurent: +1 to a model for organizing and scoping use cases 17:54:41 Laurent: I like the approach of describing various steps in payment transaction - classify / scope that - so not opposed to that. I like this direction and would like it to be the main approach of the group. 17:54:42 ...really like the direction and want it to be the main approach for the group 17:55:01 zakim, take up item 2 17:55:01 agendum 2. "Number of flows and phases" taken up [from Ian] 17:55:02 zakim, take up item 1 17:55:02 agendum 1. "Exposing the rules of a payment scheme" taken up [from Ian] 17:55:03 david: I think Laurent's suggestion is a +1 for flexibility going forward, and we're good. 17:55:21 jean-yves: About the approach - it's a big step forward. 17:55:46 jean-yves: You have two things to think about - 1) is about the how , then 2) is about what is described. 17:56:02 jean-yves: I wonder about managing rules in this process. 17:56:19 jean-yves: about the way we're describing - I think it's an improvement over the current document. 17:56:39 jean-yves: I'm convinced by the approach, not sure about the result of this approach. One of my concerns is about rules. 17:57:00 jean-yves: When you pick up paypal or google wallet, you're supposed to know how it works - you know the rules. 17:57:55 jean-yves: When we are making a transaction between one payer and one payee - the rules for the same instrument could be quite different if you are a customer w/ paypal vs. SEPA - rules can change based on location of payer payee too. Managing rules is really difficult - scheme - rule embedded in location of payer and payee. 17:58:21 jean-yves: You can call it regulation/jurisdiction - managing rules is one of the most difficult and relevant things we have to pay attention to. 17:58:45 jean-yves: so far, I can't imagine how we'll be able to integrate that problem of managing rules - it will be something we have to do. 17:58:50 q? 17:59:21 Ian: What I propose to do is, talking with Laurent and Manu, offline - maybe we can tease out second topic - one flow or multiple flows. 17:59:40 Ian: Jean-Yves - if we end up having multiple flows - some of them are more readily conducive to talking about regulatory topics than others. 18:00:20 Ian: I don't think about regulations / terms when I use my credit card - doesn't surface as much in consumer->merchant direction. However, if we do more to address different types of flows - regulatory topics appear. 18:00:41 Ian: Second thing to think about - learn about regulatory topics you care about should be integrated into second draft. 18:01:34 no objections 18:01:37 Manu: Proposed to transform the heart of this presentation (after it is updated) to make this the intro the FPWD of the use cases docs 18:01:39 no objection 18:01:40 s/docs/doc 18:01:43 +1 18:01:53 =& 18:01:55 manu: +1 18:01:56 +1 18:01:58 +1 18:02:00 +1 18:02:27 ACTION: Ian to revise the presentation based on discussion today and email comments. 18:02:45 -manu 18:02:49 -omalik 18:02:50 -jean-yves 18:02:50 -Laurent_ 18:02:51 -dlongley 18:02:51 -halmas 18:02:53 -dlehn 18:02:58 -dezell 18:03:02 zakim, who is on the call? 18:03:03 On the phone I see Ian, Dsr 18:03:08 zakim, disconnect Ian 18:03:09 Ian is being disconnected 18:03:10 -Ian 18:03:11 zakim, disconnect dsr 18:03:11 Dsr is being disconnected 18:03:13 T&S_WEBPYMT(WPAY_USE)12:00PM has ended 18:03:13 Attendees were +1.540.961.aaaa, manu, dlongley, dlehn, +1.703.628.aabb, omalik, Ian, halmas, dezell, jean-yves, Dsr, Laurent_ 18:03:22 zakim, who is on the call? 18:03:22 apparently T&S_WEBPYMT(WPAY_USE)12:00PM has ended, manu 18:03:23 s/I feel a bit ???/I feel puzzled/ 18:03:24 On IRC I see Evgeny, Laurent_, jean-yves, dezell, halmas, RRSAgent, Zakim, Omar, dlongley-db, chaals, dsr, manu, wseltzer, Erik, Ian, dlehn, Karen 18:03:47 rrsagent, make minutes 18:03:47 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html Ian 18:03:53 rrsagent, set logs member 18:06:45 s/???/puzzled/ 18:07:22 [apologies - had a once/month conflict :( ] 18:07:42 dlongley-db has left #wpay 18:39:03 Meeting: Web Payments IG: Use Cases Task Force 18:39:54 Present: Manu, Omar, Jean-Yves, Laurent, Dave_Longley, Hassan, David_Lehn, David_Ezell, Ian, Dave_Raggett 18:41:13 rrsagent, make minutes 18:41:13 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html manu 18:41:52 s/Number of flows and phases// 18:42:03 rrsagent, make minutes 18:42:03 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html manu 18:42:21 rrsagent, make logs public 18:42:25 rrsagent, make minutes 18:42:25 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html manu 18:43:33 rrsagent, make minutes public 18:43:33 I'm logging. I don't understand 'make minutes public', manu. Try /msg RRSAgent help 18:46:42 rrsagent, make minutes 18:46:42 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html manu 18:47:23 rrsagent, make logs public 18:47:28 rrsagent, draft minutes 18:47:28 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html manu 18:47:38 zakim, bye 18:47:38 Zakim has left #wpay 18:50:27 ACTION: Manu to integrate Ian's revised presentation into Web Payments IG Use Cases introductory section. 18:51:46 rrsagent, make logs world-visible 18:52:14 Chair: manu 18:52:21 rrsagent, make minutes 18:52:21 I have made the request to generate http://www.w3.org/2015/02/26-wpay-minutes.html manu