13:20:51 RRSAgent has joined #wpay 13:20:51 logging to http://www.w3.org/2015/04/24-wpay-irc 13:20:56 rrsagent, make logs public 13:21:04 zakim, this will be wpay 13:21:04 ok, manu; I see T&S_WEBPYMT(WPAY_AGENT)9:30AM scheduled to start in 9 minutes 13:26:13 andersr has joined #wpay 13:28:46 T&S_WEBPYMT(WPAY_AGENT)9:30AM has now started 13:28:47 AdrianHB has joined #wpay 13:28:53 +padler 13:29:06 Zakim, who is on the call? 13:29:06 On the phone I see padler 13:29:36 +manu 13:29:44 +Davd_Ezell 13:29:49 Agenda for todays call has been posted here: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0148.html 13:29:59 zakim, Davd is me 13:29:59 +dezell; got it 13:30:24 pbazin has joined #wpay 13:30:33 + +33.1.55.01.aaaa 13:30:59 zakim, aaaa is pbazin 13:30:59 +pbazin; got it 13:31:49 +??P38 13:31:54 AdrianHB has joined #wpay 13:32:04 zakim, ??P38 is AdrianHB 13:32:04 +AdrianHB; got it 13:32:15 Zakim, who is on the call? 13:32:15 On the phone I see padler, manu, dezell, pbazin, AdrianHB 13:32:43 zakim, who is making noise? 13:32:54 dezell, listening for 10 seconds I heard sound from the following: padler (52%) 13:33:04 https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0148.html 13:33:08 scribenick: manu 13:33:20 Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Apr/0148.html 13:33:30 jheuer has joined #wpay 13:33:48 Pat: We had a good discussion last week - was not able to document yet, we should talk about that now. 13:34:08 Pat: We're going to discuss Adrian's request - document goals vs. architecture goals 13:34:24 +Joerg 13:34:27 Pat: Key concepts/framework for requirements capture - Ian and I met and talked about what we thought were core foundational concepts. 13:34:46 Pat: If we can agree to those things, we can divide and conquer - concepts... section 2 will take up significant chunk. 13:34:56 Pat: Section 3 of agenda - likely interfaces/communication boundaries. 13:35:11 Pat: What do actual requests look like - what's talking to what? 13:35:36 Pat: Suggestion by manu - prioritization/docs - high priority vs. low priority needs - iterate document to try this approach out. 13:35:53 Pat: Lastly, scaffolding - as we go through use cases/architecture iterations - do we need X, and Y... etc. 13:36:10 Pat: This list is not meant to be final/concrete... they are suggestions for discussion... 13:36:23 Pat: Want to try to break down work so we can put something out. 13:36:35 q? 13:36:36 Pat: We need volunteers on each section. 13:36:59 Topic: Goal of Payment Architecture Document 13:37:23 Pat: Goal is to describe what we're trying to achieve - what's the vision for Web Payments from a high-level narrative, across different WGs. 13:37:36 Pat: Maybe another requirements document... this is the glue that provides the unified vision. 13:37:52 Pat: Specifically, what sections - document what's on the call - what do people want from this document? 13:37:53 q? 13:38:08 AdrianHB: Then the goal of this document is to define the vision? 13:38:17 q+ to say the goal should be to outline the technical vision. 13:38:22 zakim, call Ian-Office 13:38:22 ok, Ian; the call is being made 13:38:23 +Ian 13:38:34 Pat: Yes, I think that's where it's going - executive summary / use cases. 13:39:26 Pat: "This is what the group feels like payments on the Web should look like - doesn't go into detail on 'how', but 'what we want to achieve'" - SMTP for payments - this document captures that. Terms/concepts that we want to reinforce. 13:39:41 q? 13:39:52 Pat: WGs should be able to look at this document and understand what they need to produce from a technical perspective to achieve what's in this document. 13:40:28 q? 13:40:41 AdrianHB: So, that's what this document is going to define... are we only talking about technical perspective? Anything more? Are we calling this the architecture document? 13:41:22 Pat: The key is that there is some high-level conceptual construct - maybe the "vision" document - architecture crept in ... maybe it's not architecture, it's technical vision for the Web Payments work. 13:42:08 AdrianHB: Then, this document will contain a vision statement - then more technical stuff around definitions - players/entities - terminology stuff so we're all talking about the same things - common glossary - two parts of the document, then? 13:42:50 Pat: yes, you want every WG that picks this up to look at the document - "here's what's needed from an identity perspective" - how do we identify accounts in an interchangeable way - key concepts we want to connect, goals. 13:42:56 q? 13:43:16 AdrianHB: That's three parts - vision, definition/glossary, then there's a high-level requirements piece. 13:43:29 q? 13:43:43 ack manu 13:43:43 manu, you wanted to say the goal should be to outline the technical vision. 13:43:58 [Sounds reasonable to me: what we want to accomplish; how we will talk about it; requirements that are derived from use cases] 13:44:18 q? 13:44:23 q+ 13:44:46 Manu: we have goals: https://www.w3.org/Payments/IG/wiki/ExecSummary 13:44:49 ...we could refine that 13:44:56 ..but I think we need an architecture document; how things fit together 13:44:58 +1 to making this a "technical" vision as opposed to just a vision... 13:45:07 ..i would be concerned if we avoided enough detail 13:45:22 q? 13:45:31 q+ 13:45:37 .e.g, we need to be able to say that we need an extensible data format; and crypto to ensure that it's secure in transmission, etc. 13:45:46 ...you want the WG to address a clear set of problems 13:46:22 (IJ agrees that we should get to some technical detail about requirements, but not stating how those requirements will be met (except for seeding ideas)) 13:46:25 ack pat 13:46:28 ack pad 13:46:42 Padler: There is a high-level conceptual architecture...but not protocol details 13:46:48 ...it's the mental model for what we want to achieve 13:46:55 Pat: That's the way I see this too - high level conceptual - not protocol/weed-level architecture - more like conceptual architecture - mental model - it's documented and crisp - outlines what we want technical WGs to do. 13:46:59 ...it's documented, crisp, and says clearly what we need the WGs to do 13:47:24 Pat: If people need to know what the Payment Agent does - it specifies what it is at a high-level. 13:47:25 q? 13:47:33 ack AdrianHB 13:47:44 q+ 13:48:00 AdrianHB: I agree that we have an executive summary, and a vision - but that's just sitting in the wiki - if people are fine w/ that, then that's okay... but that needs to go somewhere. 13:48:12 manu: +1 for working executive summary in wiki into an actual document. 13:48:19 +1 13:48:19 +Dsr 13:48:20 AdrianHB: That should be somewhere 13:48:36 AdrianHB: The scope of this document is growing very quickly - just highlighting the concern. 13:48:40 q? 13:48:48 q+ to agree w/ AdrianHB - where do we put it? 13:49:10 Pat: Everyone should feel free to update that document - payment agent document. 13:49:15 ack Ian 13:50:04 Ian: AdrianHB - one of the things about that goals wiki page - the group said it wanted to create a more endorsed version of that. I have an action to work on that - we could discuss having it as architecture document. It's useful as a stand-alone short document. 13:50:20 Ian: I'd like for it to be more refined/prominent document - wouldn't put it in architecture document. 13:51:03 q? 13:51:13 Ian: What I found compelling in discussion with Pat this week - talking w/ media and prospective members - lots of recurring questions. One question is "What will be different? Things work pretty well, it better be very improved in order for there to be industry adoption. What will the experience be as a consumer or retailer or bank?" 13:51:31 q+ 13:51:43 Ian: So, we don't know the answer to that yet - there's been enough discussion about Web of Payment Agents - that's how group is answering the question. How do we tell that story? 13:52:19 Ian: What's the information in a payment request? It's not idempotent - common story is quite powerful - I have thought about it as a communications tool - also as a shared model, next level down. 13:52:23 q? 13:52:45 Manu: I agree with Adrian that we need to take exec summary and move to a doc 13:52:57 ...I agree with Ian we should not put that vision in the architecture document 13:53:13 q+ to ask about handing a Value Web Manifesto (developed by Ripple) over to the W3C to publish as a group note 13:53:44 ...doc needs to convince customers, merchants, and banks that this will be useful 13:54:04 ..they will be protected by extra security and much less friction to do payments 13:54:29 ...for banks, this is a great option for them to continue to have strong customer relations 13:54:44 q? 13:54:47 q+ 13:54:57 ack manu 13:54:57 manu, you wanted to agree w/ AdrianHB - where do we put it? 13:55:03 ack pbazin 13:55:05 Manu: So we need to answer the questions Ian asked in one doc, but arch is separate 13:55:37 +10 to interoperability!! 13:55:55 pbazin: The thing we're expecting from W3C is interoperability, mainly - it's important that every service provider, any retailer will be able to use this (especially on mobile). The very important thing from W3C is standardization of interoperability of all those modules. 13:55:56 +1 to interop as the ultimate _technical_ goal 13:55:58 q? 13:56:03 ack AdrianHB 13:56:03 AdrianHB, you wanted to ask about handing a Value Web Manifesto (developed by Ripple) over to the W3C to publish as a group note 13:56:46 AdrianHB: We have a "Value Web Manifesto" at Ripple - a vision statement around exchanging value as easily as email. Couldn't we take that work and hand it over to W3C? Could we publish that as a group note? 13:57:01 AdrianHB: People seem pretty happy to do that - if group is comfortable with that - I think I can make that happen. 13:57:15 q? 13:57:19 AdrianHB: Would people be comfortable with that? 13:57:45 q+ to say that Value Web document should be an input, but not directly published. 13:58:11 -dezell 13:58:13 q+ 13:58:21 +1 to interoperability (to me the only people who should be worried aboutwhat we are doing are integrators not banks, retailers etc) 13:59:04 padler: I'd like to take a look at it... don't want to just have a payment system to just exchange value w/ customers... but want to exchange value w/ employees, merchants, partners, etc. 13:59:46 padler: Even though there are definite use cases at POS - the goal here is "SMTP for Money" - outlined via Ripple document - there should be a way to pass value. 14:00:19 padler: As I think about the vision - we need to hit those things pretty hard. Different groups prioritizing different things - core concepts are very important. If we don't unify, we won't be relevant. 14:00:22 ack Ian 14:00:28 ack padler 14:01:14 Ian: AdrianHB, one idea is for you to do a blog post using the IG blog where you put forth Ripple's vision and say that you're excited by this vision and why. Bringing this to WPIG because you see this as a forum to achieve this vision. That establishes it as a Ripple thing, doesn't preclude getting more IG buy-in, and also is a good way to seed that discussion faster. 14:01:23 Ian: Just wanted to mention that before I go. 14:01:39 +1 to checking it out 14:01:43 AdrianHB: I can send this up to have a look at it - can do a blog post, look at it, not a Ripple thing at all. 14:01:57 +1 to Generic Document!!! 14:02:05 AdrianHB: It doesn't talk about Ripple / ledgers / etc. It's basically about value-exchange on the Web. 14:02:10 ack manu 14:02:10 manu, you wanted to say that Value Web document should be an input, but not directly published. 14:03:04 jackson has joined #wpay 14:03:21 manu: I'm concerned that we're talking about "vision" stuff, rather than "Payment Architecture" stuff. We need vision, but this call is supposed to be about Payment Architecture. 14:03:45 + +1.614.588.aabb 14:03:52 zakim aabb is me 14:03:56 Pat: if we can get agreement on key concepts - we can move forward. 14:04:04 s/zakim aabb is me// 14:04:06 zakim, aabb is jackson 14:04:06 +jackson; got it 14:04:12 q? 14:04:14 manu: +1 to moving on to second topic. 14:04:35 Topic: Key Concepts and Framework 14:04:50 Pat: Discussion around payment architecture and narrative - want to describe them at a high level. 14:04:59 Pat: If that's a good starting point, we can iterate on it quickly. 14:05:34 Pat: We're trying to boil this down into a series of simple standards... five key concepts. If we get these right, we can start to build around the key concepts. 14:05:50 Pat: Interoperable payments on the Web can flourish if we get this right. 14:06:44 q? 14:06:48 Pat: So, "Payment Agent" - a wrapper for a thing that exchanges information around payments and accounts on the Web. Responsible for high-level communication between payment agents. It can run as native mobile app, browser app, part of car dashboard. Payment Agent uses standard/consistent set of request and response and with accounts that they're interacting w/ in a standard way. 14:06:53 q+ to ask about Payment Agent. 14:07:50 Pat: "Accounts" are representations of value - accounts are provided by somebody - "Account Provider" is organization or person or thing that's responsible for maintaining rules and state of account. A couple of things may illustrate this - one, account providers like banks - banks provide accounts, you deposit money into accounts... 14:08:44 ... you can make requests from your phone to send money from A to B. If it's two people, peer-to-peer, you may have a local store of value (local account - app provider owns payment agent, because they're responsible for store of value - submit requests to transfer money from local/app accounts) 14:09:33 Pat: Merchant scenario also applies - run agent in the cloud - shop via browser or in store. Payment Agents talk to each other, are provided by an entity that's responsible for account information that they have access to. 14:09:35 q? 14:09:40 ack manu 14:09:40 manu, you wanted to ask about Payment Agent. 14:10:42 manu: need to disambiguate Account from other non-money accounts.. 14:11:11 +1 for value account unless we are only focusing on money 14:12:25 account provider -> custodian ? 14:12:25 Pat: The Payment Agent has two communication boundaries - maybe three - one is that payment agent is a piece of software that interacts with a user agent. Car/browser - payment agent talks to user agent and interacts with other payment agents/accounts. 14:12:38 account -> value store? 14:12:45 q+ to mention that "Account provider" may not make sense in cryptocurrency scenarios. 14:14:43 Pat: Bank is responsible for that - in that scenario, I might use carphone/browser to make a request to the payment agent to pay - pay gas pump/merchant - payment agent that I interact w/ will send request to bank payment agent and bank endpoint where bank's payment agent will instruct their systems to affect the change. The account provider, we don't care about implementation details. When PA communicates that state, it's consistent. Payment Agent construct can b 14:14:44 e used interoperably whether they're using a DDA account at a bank, or a Visa account. Instruct Visa to move value in their network. In both cases, value is moved and result sent back to Payment Agent. 14:15:00 q? 14:15:36 Pat: The three interfaces are 1) user agent to payment agent, and 2) payment agent to payment agent, and 3) payment agent to account. 14:15:44 Manu: Account or Account Provider? 14:17:16 Pat: We'll get into more discusison around rules associated with what Payment Agent is able to do to an account. For example, if I have a scenario where I have an app - transfer value from bankCo to mobileCo account. MobileCo is on the hook to protect their account - responsible for updating state of that account, their payment agent is bound to perimeter. They're responsible for the boundary. 14:17:32 Pat: Account providers are in charge of managing accounts. 14:18:17 q+ to ask if payment agent can be the account provider 14:18:22 Pat: Accounts can have Authorized Users - DDA account at bank, two people can be authorized to access the same account. State change all happens via bank's payment agent, and then returns status of what happened. 14:18:24 ack manu 14:18:24 manu, you wanted to mention that "Account provider" may not make sense in cryptocurrency scenarios. 14:18:34 q+ 14:18:45 -Dsr 14:18:58 +Dsr 14:19:01 q? to talk about account provider 14:19:02 +1 "provider" is probably the wrong term 14:20:58 Pat: "Account Provider" and "crypto" - same thing, I'm going to transfer value - if I want to transfer Coinbase - they're responsible for store of value and what happens there. Same thing w/ Ripple trade account. Some software provider, some provider helps you access the value. We may want to think about terminology - maybe "cryptocurrency account" "cash account" "credit account"... scenario like Mint or Quicken, use some abstract term for account. Interchangeably 14:20:58 , we can integrate all those mechanisms because they're all sharing a common format. 14:21:07 +1 for ledger 14:21:32 q? 14:21:34 ack AdrianHB 14:21:34 AdrianHB, you wanted to ask if payment agent can be the account provider 14:21:56 AdrianHB: I agree with Manu, cryptocurrency scenario - bitcoin/blockchain is the account provider - you can trade directly. 14:22:04 manu: +1 to what Adrian is saying - exactly my point. 14:23:08 AdrianHB: Instead of "provider" maybe something like "custodian". In some cases, Payment Agent is speaking to provider - but in some instances the agent holds whatever it needs to execute a transaction directly against the ledger. Difficult to have both worlds have a common set of terminology. If we acknowledge the cryptocurrency use cases, we can come up with good terminology. 14:23:28 Pat: Yes, I like "custodian" - those things represent the account or amount or value - what's available on the network. 14:23:54 AdrianHB: In the world of value exchange, I like ledger - ultimately that's what people that exchange value, you're writing to a ledger. 14:24:40 +1 to ledger concept 14:24:44 AdrianHB: "Who can write to the ledger" is who is the custodian... banks can write to internal ledgers, Bitcoin/Ripple can write to public ledgers. Banks are custodians of their ledgers. Bitcoin clients are the custodians of their accounts on the public ledger. 14:24:46 q? 14:24:59 AdrianHB: If there is no intermediary, then payment agent is the custodian. 14:25:04 q? 14:25:50 jheuer: There are some topics that we're not covering - giving power to user - level playing field - we're going too generic? We can process the payments, where do credentials get aggregated, where do I hold my payment instruments, 14:25:54 q+ to agree with jheuer 14:25:57 ack jheuer 14:26:16 jheuer: We're mixing up terminology - we really need to take care of user view - that's not in the narrative now. 14:26:42 Pat: That's not the focus of conversation right now - the key is "payment agent" is an abstraction that allows users to use same constructs to communicate value. 14:27:26 Pat: If I want to pay via "credit cards" or "ripple" mechanisms - we want agents to be able to interact with one another - distributed vs. centralized. 14:27:32 ack manu 14:27:32 manu, you wanted to agree with jheuer 14:28:05 +DavidJ 14:28:08 -jackson 14:28:10 sounds a bit like "it's payment agents all the way down" - but where does it start? 14:29:04 Manu: Like Joerg, I'm concerned about not doing "user-first" design too. I think it's in there, but it's a bit hidden now. 14:29:43 Pat: Yes, we want the same construct to be used. We're wildly successful if we can enable broad adoption and choice. 14:30:34 Pat: That's where that scaffolding comes in - how do payment agents exchange information about loyalty, coupons, identity of the agent, authorization data. Three boundaries - checklist - how do agents find each other. How do you make sure there aren't "payment agents in the middle"? It's more about scaffolding - but we're definitely going toward what you want, Joerg. 14:30:35 No contradiction - just think we should address it. Probably just point me to where it's supposed to be - underneath the scaffolding. 14:31:22 Pat: Adrian, what we're trying to get to with "provider" concept - they're going to be providers - Coinbase is acting as provider of software - affecting value change on some store of value. 14:32:11 Pat: The key is that two things need to be decoupled - rules provided for money transmission (regulatory), and things that probably relate to things that happen (store of value itself). So, you're right - bank as custodian has regulatory requirements, some are scheme-dependent. 14:32:54 q? 14:32:56 Pat: So, we have a construct - three surfaces that exchange info w/ other pieces of software - speaking a certain dialect - ledgers - do like that term. Ledgers, I should be able to combine all of them together into "my net worth" whether a person or a company. 14:33:51 Pat: If this is moving in a good direction - put in some synonyms - "account" "ledger" "value account" - concepts are clear at least as a starter - put them in document. 14:33:58 manu: +1 to putting it into the document and going from there. 14:34:12 q? 14:34:50 Pat: Adrian's going to send value web manifesto 14:35:04 Pat: I'm going to add glossary to document soon-ish 14:35:11 Pat: Send comments to mailing list 14:35:19 q? 14:35:20 Manu: If people could look at this: https://www.w3.org/Payments/IG/wiki/Payment_Architecture_Feature_Priorities 14:36:03 q+ to ask about using GitHub for document collaboration 14:36:46 Erik3 has joined #wpay 14:37:27 Manu: I think we need to discuss Payment Architecture (how all this fits together) - that's the most important thing we can do. 14:37:38 Manu: Are we putting out a FPWD before June? 14:37:52 Pat: If we can get those three things into the document, I think the group will be able to go faster. 14:38:17 Pat: "What credentials are required for payment agents?" - we'll be able to start talking about stuff like that if terminology is set. 14:38:58 Pat: I would like to push for a FPWD before the face-to-face. Personally, if it's just Pat and a couple of others doing this - it'll be difficult. 14:39:23 1? 14:39:25 q? 14:39:26 q+ about people contributing. 14:39:27 ack AdrianHB 14:39:27 AdrianHB, you wanted to ask about using GitHub for document collaboration 14:39:50 AdrianHB: is everyone comfortable w/ using github? Easier than mailing list - commentary/collaboration is tied to content. 14:39:55 manu: +1 to using Google Docs 14:40:01 manu: We failed w/ Github 14:40:24 +1 to using either github or google docs.. 14:40:26 q+ 14:41:29 Sorry, not in the office today. 14:41:38 Call is now? 14:41:55 Payment Agent call I mean 14:42:02 just wrapping up.. 14:44:05 Manu: We shouldn't wait for more people to contribute, let's move now. We should use Google Docs - personal account is fine. 14:44:20 Pat: Ok, I'll setup google doc and we'll do collaboration there. 14:44:31 q? 14:44:33 pat: Good comments/input on synonyms. - will update 14:44:34 ack manu 14:44:37 ack manu 14:44:52 -AdrianHB 14:44:54 -DavidJ 14:44:54 -manu 14:44:55 -Joerg 14:44:55 -padler 14:44:57 -pbazin 14:46:53 -Dsr 14:47:05 zakim, who is on the call? 14:47:05 On the phone I see Ian 14:47:08 zakim, disconnect Ian 14:47:08 Ian is being disconnected 14:47:09 T&S_WEBPYMT(WPAY_AGENT)9:30AM has ended 14:47:09 Attendees were padler, manu, Davd_Ezell, dezell, +33.1.55.01.aaaa, pbazin, AdrianHB, Joerg, Ian, Dsr, +1.614.588.aabb, jackson, DavidJ 14:51:55 Adrian_Ripple has joined #wpay 14:54:31 Present: Pat, Manu, DavidEzell, Adrian, DavidJackson, Joerg, Pascal, Ian, DavidRaggett 15:19:46 Karen_ has joined #wpay 15:46:11 chaals has joined #wpay 16:41:29 Karen has joined #wpay 17:27:01 chaals has joined #wpay 19:38:11 Karen_ has joined #wpay 21:21:44 rrsagent, draft minutes 21:21:44 I have made the request to generate http://www.w3.org/2015/04/24-wpay-minutes.html manu 21:22:51 Chair: Pat 21:23:05 Meeting: Web Payments Interest Group Payment Agent Task Force 21:23:07 rrsagent, draft minutes 21:23:07 I have made the request to generate http://www.w3.org/2015/04/24-wpay-minutes.html manu 21:26:28 s/ Sorry, not in the office today.// 21:26:31 s/Sorry, not in the office today.// 21:26:39 s/Call is now?// 21:26:47 s/Payment Agent call I mean// 21:26:55 s/just wrapping up..//