13:23:41 RRSAgent has joined #wpay 13:23:41 logging to http://www.w3.org/2015/03/27-wpay-irc 13:23:44 Zakim has joined #wpay 13:23:47 zakim, this will be wpay 13:23:47 ok, manu; I see T&S_WEBPYMT(WPAY_AGENT)9:30AM scheduled to start in 7 minutes 13:24:03 Meeting: Web Payments IG Payment Agent Task Force 13:24:13 rrsagent, make logs public 13:24:18 rrsagent, draft minutes 13:24:18 I have made the request to generate http://www.w3.org/2015/03/27-wpay-minutes.html manu 13:29:02 zakim, code? 13:29:02 the conference code is 9729 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), manu 13:29:12 jheuer has joined #wpay 13:29:29 T&S_WEBPYMT(WPAY_AGENT)9:30AM has now started 13:29:30 +Joerg 13:29:31 +??P21 13:29:37 -??P21 13:29:38 +??P21 13:29:49 dezell has joined #wpay 13:29:51 +Istvan 13:29:51 zakim, I am ??P21 13:29:51 +manu; got it 13:30:08 Istvan has joined #wpay 13:30:19 +padler 13:30:38 padler has joined #wpay 13:30:41 +dezell 13:30:59 +Dsr 13:31:08 zakim, who is on the call 13:31:08 I don't understand 'who is on the call', padler 13:31:15 present+ Dave_Raggett 13:31:21 zakim, who is on the phone 13:31:21 I don't understand 'who is on the phone', padler 13:31:30 Present+ Manu 13:32:27 +dlongley 13:32:38 zakim, dlongley is hassan 13:32:38 +hassan; got it 13:32:54 pbazin has joined #wpay 13:33:01 +Pascal 13:33:38 Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0138.html 13:34:35 halmas has joined #wpay 13:35:20 zakim, pick a victim 13:35:20 Not knowing who is chairing or who scribed recently, I propose padler 13:35:27 scribe: manu 13:35:39 Topic: Agenda Bashing 13:36:01 Pat goes over the agenda... 13:37:14 Pat: We had a lot of discussion on diagrams, those haven't been updated yet. 13:37:42 Pat: Payment Agents that we're calling wallets - there is a list of functions/features - additional things - payment agent more abstract - incorporate those with big picture view. 13:37:47 q+ 13:37:48 q? 13:38:14 jheuer: One question for David - does it make sense to discuss your topic today - we'll have a talk about it later? 13:38:37 DavidE: I'd like to hear what you have in your head and how to get that down onto paper. 13:39:00 q? 13:39:40 manu: no framework yet to put the discussion topics into the document… 13:40:07 q+ 13:40:09 +1 to first review the doc structure 13:40:10 ack manu 13:40:33 manu: I'd like us to focus on document structure / framework. 13:40:34 manu: we need to focus on how the document should be structured… this will help to allow people provide input to the document 13:41:04 dezell: There are a number of not fully formed thoughts in this area - this is an exercise - don't know if it'll work... might precipitate some discussion. 13:41:27 Here is the current version of the document.. https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html 13:41:30 q? 13:41:35 ack dezell 13:43:01 q? 13:43:03 q+ 13:43:04 q+ 13:43:12 q+ 13:43:23 dezell: Joerg has a number of things in his head - this is what is driving him - it would be good to get those out into the group, but I want it to translate to spec text. 13:43:30 manu: would like to see actions taken to translate list into tech specs.. 13:43:43 s/but I want it to translate to spec text.// 13:43:57 dsr: We can't run before we can walk - we need to understand at some broader level what we're trying to achieve. 13:44:04 dsr: I think you're right, but it may be too early. 13:44:08 ack dsr 13:44:41 dezell: I think the list you're talking about was an aside that we want everyone to look at. It's more of a bottom-up approach - manu is suggesting a top-down approach, it assumes alignment with the use cases document. 13:44:41 ack dezell 13:45:07 q+ 13:45:36 dezell: I think that's a good suggestion - if the use cases - the chunks of functionality that are re-used in various places, if we created a thought map into the components of the architecture, we'd either discover that it fits nicely, or it rocks our world. In which case, we'd have to look at them. 13:45:48 s/look at them/look at reviewing them again./ 13:45:59 dezell: Is such a mapping possible to the proposed bits in our architecture. 13:46:00 ack padler 13:47:08 padler: There have been a number of conversations since the call last week. We've tried to work with everyone on the editorial schedule - what's the structure of what we're going to produce? We need a good way for the sections to be represented in the Payment Agent conceptual architecture... the use cases document and micro-use cases - what's in the payment agent architecture - ties to discussion w/ joerg - in the large picture, for payment agent. 13:47:51 padler: It's hard to represent specific use cases - those are very concrete, specific to one place that payment agent may be deployed. The back and forth has been around use cases - but payment agent itself is more abstract than that. We were going back and forth - do we start w/ abstract view of payment agent and walk into specific linkages to use cases. 13:48:11 padler: So, what is a payment agent and what does it do vs. specific use case tie-ins, then work more abstract. 13:48:52 padler: There are pros and cons to both ways, but not always a one to one correlation between use cases and payment agent architecture. Not one to one tie for a particular sequence. 13:49:32 padler: There might be approaches that are easier for merchants to understand - specific ways the payment agent is built for merchants... if you're a wallet provider, how does the payment agent concept applies to what Joerg sent out earlier. 13:49:34 q? 13:49:37 q+ 13:49:46 padler: We need a big picture thing, but we need smaller more focused concrete use cases. 13:49:50 ack jheuer 13:49:52 q? 13:49:56 q+ to propose a way forward. 13:50:26 jheuer: Would you say that it would be possible within a few hours to take up to 3 of the use cases and run them through your diagrams? See whether they're useful? Or should there be work done on architecture? 13:50:55 +1 to continuing the "validating the architecture against the use cases" excercise. 13:50:58 padler: We had five examples of diagrams - specific use cases - core/common things... figure out required capabilities of payment agent - had to be in all five of those use cases. 13:51:23 padler: If you're a payment agent that's being deployed in context of user - there might be a set of required capabilities that you're required to implement. 13:51:43 padler: There are capabilities that need to be added - not just payment related things, but other services that may be required on that host. 13:52:38 padler: That's the way the document in its current form is structure - working from more abstract in to use cases - broad introduction - forget diagrams for a second, look at the outline. High-level description of what a payment agent does - section 3 in context, it'll explain why it was broken down that way - four and five - required and optional capabilities, respectively. 13:53:11 padler: There are a couple of places we can put it - we could have a section for mobile handset providers... in context of a smart phone - is it a secure element, is it some kind of a cloud encryption mechanism, etc. 13:53:29 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html 13:53:30 jheuer: Could you send the URL to the document you're talking about Pat? 13:53:35 padler: Ok, it's above. 13:53:44 q? 13:54:09 jheuer: The new picture that Pat put together - really creates a big picture from the view of the payment expert. 13:54:46 jheuer: I wouldn't have included some of those - not visible to user - so may have not included that, but that big view makes sense - you need to see where the work we're doing fits in. 13:55:01 jheuer: I'm happy to have big picture that makes all payment people happy - then see what part of it is user-facing. 13:55:03 q? 13:55:27 jheuer: I like to see user side of it for browser for credentials and claims - wallet - payment agent is abstract for it... what the term means has changed. 13:56:08 jheuer: We need to find a concrete form for a payment agent - before we can go into the use cases - that makes me a bit unsure - don't know if we can map the use cases properly w/o doing that step. Coming from big picture, boiling down to abstraction level, how do we map to use cases? 13:56:35 jheuer: If we need to map use cases, we should do it very soon. We should use the use cases as a guiding light for us. The use cases are the most advanced and best aligned w/ what we have so far. 13:56:49 q? 13:57:00 jheuer: We need to boil down the big picture to something that meets the use cases. 13:57:19 ack dezell 13:58:01 dezell: That all makes sense to me - with my agile hat on - we're kind of stuck here - almost too complicated - concrete set of steps that we can get in the next few weeks - don't see any problem with what's been done... all looks pretty good. We need to bring these things together. 13:58:12 dezell: We need to make progress. 13:58:17 [with hundreds of use cases in Manu’s backlog, it is indeed like a log jam] 13:58:24 q? 13:58:34 q+ 13:58:34 jheuer: We can still be goal driven... 13:58:37 ack manu 13:58:37 manu, you wanted to propose a way forward. 13:59:42 q? 14:00:13 -Dsr 14:00:27 ACTION: Manu to propose an alternative document flow/section break up for payment agent document. 14:00:28 Created ACTION-84 - Propose an alternative document flow/section break up for payment agent document. [on Manu Sporny - due 2015-04-03]. 14:00:37 manu: I'll volunteer to put my thoughts down into a document. 14:01:04 q? 14:01:04 padler: Yeah, we may need to work from both directions... bottom-up and top-down - we need to show concrete and abstract at the right points. 14:01:22 q+ 14:01:25 padler: Rather than coming up with a separate document - is there a way that we can comment on what's in the editor's draft? 14:02:39 q- 14:02:48 ack padler 14:03:35 padler: So use that document as a collaborative thing - don't mess w/ diagrams - goal #1 is getting document together. Put pieces together in the document... 14:03:39 padler: I want to make sure we're all focus on getting everything back into the same place. 14:04:01 manu: What's good about the group - we have the big picture - focused on use cases - that'll help us in the long term - it'll be good - compressing them into the one document would be good. 14:04:02 q? 14:04:12 s/manu: What's/padler: What's/ 14:04:45 Topic: Timelines for Payment Agent FPWD 14:04:52 padler: What's required for some of the upcoming meetings? 14:05:04 padler: Joerg - we want to make sure we have a FPWD by June 1st 14:05:32 padler: That would be basically - put us in a good position to have the document in place before the face-to-face in New York. Roundtable discussion on where the group is at, get more of the browser vendors involved. 14:05:54 padler: It's critical that we start making some direct progress on that. It's important to get those things moving. 14:05:57 q? 14:05:59 q+ 14:06:02 ack manu 14:06:46 manu: W3c Publishes on Tuesday's and Thursdays 14:07:09 we need to have text in really good shape by May 15th to allow for the document to be reviewed prior to publication.. 14:07:29 q? 14:08:39 manu: typically it is Task force first then IG review 14:09:21 manu: internal reviews on this document should be targeted for last two weeks of May 14:09:33 q? 14:10:13 q? 14:10:14 jheuer: Any vacations that could get in the way of this? 14:11:06 padler: When we do FPWD on June 2nd - what's the process from there? 14:11:57 Could somebody write the link to the document for everyone ? 14:12:15 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html 14:12:29 thanks 14:13:15 q? 14:13:36 manu: We would probably ask for external reviews - tell X9 / ISO groups to review the FPWD by July 15th 2015, for example. 14:15:13 padler: re: socializing - if we need some innovation/web crypto - what are those going to be - thinking through the document, how we choose to organize the document may be tied to overview - specific sections, specific areas of the document targeted to specific user communities... don't have to read through 500 pages that isn't relevant to them. As we think about the document framework - how we proceed - if we can figure out how to prioritize overview section. Eno 14:15:13 ugh weight - recruit specific members - compile how payment agent concept fits in - best done by people that are operating in those areas. 14:15:23 padler: We don't want whole group trying to comment on secure element. 14:15:28 q? 14:16:02 padler: When I think about the document - let's say a payment system company implementing the payment agent - understand basics of payment agent - then "what do I have to do to be payment agent compliant?" 14:16:47 padler: When I think of people doing wallets - they may not be interested in PoS terminals and how they tie into merchant back-end systems. They're interested in a different set of scenarios - if they're framed in payment agent/verticals - that might make it easier to make it easier to use the document. 14:17:05 q? 14:17:16 q+ 14:17:19 padler: There is no good way to walk through the document - makes sense from a use cases standpoint - difference from vending machine vs. PoS terminal. There are probably big implementation differences that are important to understand. 14:17:21 ack dezell 14:17:47 dezell: I think what you're touching on is that somehow we're going to have to put these things in various languages that each of these stakeholders understand. I'm not sure that's even possible. 14:17:55 dezell: There may be a less onerous way to approach it 14:18:01 q+ 14:18:08 q+ to propose less onerous way to approach what padler wants. 14:18:24 dezell: There are certain APIs that certain verticals want and ones that they don't want. 14:18:48 q? 14:19:27 dezell: This fits my particular use case vs. I don't care about these other use cases. When I say API - I don't mean WebIDL - it's this abstract notion of a restful web service and a WebIDL call - whether you're on the device or off the device. There are some examples of these things in the wild - FirstData's PayEze - initiating a sale. 14:19:41 dezell: We need to identify, in our diagrams, where those APIs are... so people can reason about the content. 14:20:23 padler: Yes, that's where I was going w/ the comment - I think you're right - the rationale for the diagram in section 2 initially - it's organized around breaking the concept of the payment agent up around sending payments, receiving payments, PoS, etc. 14:20:53 padler: So, for linkages for particular standards - host container itself matters a lot - host containers may be PoS terminal, smartphone, cloud, etc. 14:21:51 q? 14:21:52 padler: If you're a scenario - Cyril brought this up - I've got a reader, the payment stuff shows up on my device - communication is broken up by API or functional area - payment agent is implemented across different implementations. 14:22:12 dezell: I think that makes sense - concerned about what we're going to do before next meeting. 14:22:16 ack jheuer 14:22:38 q? 14:22:48 jheuer: My impression here is that things have gotten more abstract from when I left a few weeks ago - that might be good. We need to drill things down to something that matches the use cases. 14:23:22 jheuer: I do have the feeling that we're in a similar situation wrt. reinventing WWW and web browser - ecommerce has started out w/ web being there - developing the first web browsers, we didn't know what ecommerce would look like. 14:24:12 jheuer: Without understanding supply chains, delivery mechanisms, etc. it was still possible to make ecommerce happen. I was hoping we'd do something similar w/ users claims/credentials - user agent analogy - objects in that to be displayed/handled - web page that has virtualized cards/snippets/tickets/etc. 14:25:00 jheuer: If we start from totally abstract view - we won't be able to handle it. I don't think we are creating something that's needed... when we did it, we found it very helpful - we had the example of the infocards, for example. That proved to be useful. 14:25:05 q? 14:25:34 jheuer: No one talks about virtualized cards - we talk about abstract dependencies - allows for any kind of solution, it's nice - you can do everything via networks, but you have to do it all by yourself. Which approach are we going to take? 14:25:53 q+ 14:26:00 jheuer: Do we start w/ big picture? Or somewhere else. 14:26:12 jheuer: The big picture that we have no is probably a bit too far away from the use cases. 14:26:13 q? 14:26:21 ack manu 14:26:21 manu, you wanted to propose less onerous way to approach what padler wants. 14:26:35 ack dezell 14:27:35 dezell: Joerg, this is why I wanted you to make that list - it's apparent to me - the structure of the wallet - cards or coupons - those are absolutely going to have to be there. It's not clear that they're first-class citizens of the wallet... or are they? 14:27:46 dezell: We need a shorter list than the one you sent if we're going to think about it that way - we need a model that's manageable. 14:27:53 -hassan 14:28:08 dezell: The sheer number of things in your list - those need to be abstracted - maybe we haven't abstracted it correctly. 14:28:14 q? 14:28:17 q+ 14:28:26 dezell: Maybe we want an overly thoughtful view of a perfect world... and the other is an industrial view of the nuts and bolts. 14:28:35 q? 14:28:35 q+ 14:28:35 q+ to say I remembered my proposal! 14:29:23 padler: Let me comment on what david said - I think this is a good thing - we have both the big picture and some practical things. This weeks priority - standard X or standard Y - we've gotta figure out a way to represent both of those view points. 14:29:46 padler: A payment agent and why does the abstraction exist - that's what gets us to something where the payment agent can be extended over time. What's coming next? 14:30:23 q? 14:30:24 padler: There has to be sections on where payment agent lives in the wild - give industry players examples on how that happens. 14:30:25 ack padler 14:30:52 ack manu 14:30:52 manu, you wanted to say I remembered my proposal! 14:31:30 +1 14:32:55 meeting into the middle by defining core blocks of functionality (which may or may not be required)… 14:33:14 q? 14:33:15 ack jheuer 14:33:35 s/meeting into/manu: meeting into/ 14:34:17 jheuer: I think we can consolidate - we have inconsistencies wrt. payment agent / wallet, etc. - if we do that over the week, we'll need more communication - expect myself to be ready to react to mails more - will try to make my contributions, hope others can do the same over the next week. 14:35:13 jheuer: wrt. the verticals - agree that we may want vocabulary here - important to understand the tool - like the web browser, serving many different verticals... but they didn't have to know what those verticals are - my list is lengthy, but serves all those different means - I think we can do that and the consolidation should happen over the table of contents perhaps. 14:35:13 q? 14:35:44 jheuer: ok, we'll chat over mailing list - we need to align over vocabulary - by next week, we'll have an idea of how these things will connect to each other. 14:35:57 dezell: Don't forget, I'm publishing agenda for telecon - please send suggestions my way. 14:36:13 Thanks everyone!!! :D 14:36:25 -manu 14:36:26 -dezell 14:36:26 -Istvan 14:36:27 -Joerg 14:36:29 -padler 14:36:29 -padler 14:36:30 -Pascal 14:36:31 T&S_WEBPYMT(WPAY_AGENT)9:30AM has ended 14:36:31 Attendees were Joerg, Istvan, manu, padler, dezell, Dsr, hassan, Pascal 14:36:56 Present: Joerg, Istvan, Manu, Pat, DavidEzell, DaveRaggett, Hassan, Pascal 14:37:01 rrsagent, draft minutes 14:37:01 I have made the request to generate http://www.w3.org/2015/03/27-wpay-minutes.html manu 14:37:28 Chair: Joerg, Pat 14:51:13 rrsagent, draft minutes 14:51:13 I have made the request to generate http://www.w3.org/2015/03/27-wpay-minutes.html manu 14:52:08 i/re: socializing - if we need some/Topic: Payment Agent Document Structure 14:52:14 i/re: socializing - if we need some/Topic: Payment Agent Document Structure/ 14:52:17 rrsagent, draft minutes 14:52:17 I have made the request to generate http://www.w3.org/2015/03/27-wpay-minutes.html manu 15:38:57 rrsagent, bye 15:38:57 I see 1 open action item saved in http://www.w3.org/2015/03/27-wpay-actions.rdf : 15:38:57 ACTION: Manu to propose an alternative document flow/section break up for payment agent document. [1] 15:38:57 recorded in http://www.w3.org/2015/03/27-wpay-irc#T14-00-27