- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 30 May 2015 20:29:47 +0200
- To: Adrian Hope-Bailie <adrian@ripple.com>
- Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Antonio Ruiz Martínez <arm@um.es>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKaEYhKERuy0tDYd-d5TGvAb-=qNW=dAezLNdneyKtSsm3KwMA@mail.gmail.com>
On 26 May 2015 at 16:29, Adrian Hope-Bailie <adrian@ripple.com> wrote: > How does this change the fact that when sending value over the Web the > analogy with the Web of today and sending of information breaks down? There > is no double-spend problem to overcome in designing a system to send email > over the Internet. > One other point about double spend. The web is so big it will throw up some use cases where double spend is more of a problem and double spend is less of a problem. Let's consider a currency as an anti spam measure (which is a typical motivation for creation). I might charge a certain amount of credits to read or write a certain resource, to keep out spammers. However if that person is a trusted friend, then I might not even cash the charge at all, simply give access for free. In this scenario, a double spend is not expensive to me, or to the user. > > On Tue, May 26, 2015 at 4:10 PM, Melvin Carvalho <melvincarvalho@gmail.com > > wrote: > >> >> >> On 26 May 2015 at 15:50, Adrian Hope-Bailie <adrian@hopebailie.com> >> wrote: >> >>> One must remember that this analogy breaks down when you consider that >>> data can be replicated infinitely and yet we want to send "value" in a way >>> that it can only be sent once and once it has been sent it is held be the >>> receiver. >>> >> >> Data cant be sent infintiely, since storage is finite. Data can be >> replicated, however, to very large degrees. This is part of what we call >> the "open world assumption" [1]. Out of this mass of data comes a >> consensus, for it to be useful. This is either top down through central >> authorities. Or bottom up, in a self organizing way, which is the design >> philosophy of the web. We've seen both system work as a hybrid solution on >> the web. >> >> [1] http://en.wikipedia.org/wiki/Open-world_assumption >> >> >>> >>> >>> >>> On 26 May 2015 at 15:32, Melvin Carvalho <melvincarvalho@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 26 May 2015 at 13:03, Adrian Hope-Bailie <adrian@hopebailie.com> >>>> wrote: >>>> >>>>> >>>>>> The second is explicitly calling out the need for the architecture to >>>>>> allow payers and payees to make a transfer of value between one >>>>>> another, >>>>>> even if they don't have a common payment instrument or scheme. i.e. >>>>>> The >>>>>> Web must work like the Web is supposed to and have a mechanism to fill >>>>>> the gaps and comment the two. >>>>>> >>>>> >>>>> With this explanaition I understand your idea. But, from my point of >>>>> view, in the end, this is making a kind of "P2P payment", which we could >>>>> consider as a new payment scheme. >>>>> >>>>> +1 Yes. I wouldn't say it has to be P2P (person to person) it could be >>>>> a business or government or any other entity on either end of the payment >>>>> but the point is we ARE suggesting that there be a new payment scheme, >>>>> called the Web. It will provide the glue between existing schemes so we >>>>> have a truly decentralized system as Melvin suggests. >>>>> >>>> >>>> There's two aspects of the web, one is the glue and one is the core. >>>> Just like UNIX has a kernel and drivers. >>>> >>>> If you consider every HTTP request returns a number of bytes, which are >>>> information. This is transferring something of value. Extending the core >>>> of the web to be agnostic to what items of value are transferred. At the >>>> same time the web acts as a very good glue and can incorporate existing >>>> payments systems on a per need basis, much as webmail incorporated email. >>>> >>>> Different teams will work on different aspects. The part that intersts >>>> me is stitching payments into the fabric of the web itself (if it isnt >>>> already) and sharing common patterns and experiences. Probably to start >>>> with the frameworks around existing payments will be the bigger work. But >>>> to see that in the context of a decentralized web will hopefully allow >>>> incentives to become aligned with value creation, with less friction. >>>> >>>> >>>>> >>>>> >>>>> >>>>> On 26 May 2015 at 11:13, Antonio Ruiz Martínez <arm@um.es> wrote: >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> First of all, many thanks for you comments and explanations. >>>>>> >>>>>> El 22/05/2015 a las 15:27, Adrian Hope-Bailie escribió: >>>>>> >>>>>>> Hi Antonio, >>>>>>> >>>>>>> After reading the current version of the document, I have some >>>>>>> comments and suggestions that I would like to share. I hope they >>>>>>> are >>>>>>> useful. >>>>>>> >>>>>>> >>>>>>> Thanks for your input >>>>>>> >>>>>>> - Regarding user experience, I would mention that the payment >>>>>>> process (initiation, purchase, obtaining a receipt and the >>>>>>> product/service) should be uniform so that the user can see the >>>>>>> process is conducted in the same way and, thus, it generates >>>>>>> trust >>>>>>> to the users. I do not know if this is what you want to mean with >>>>>>> "harmonizing the checkout experience across e-commerce websites." >>>>>>> >>>>>>> >>>>>>> Yes, this is what that sentence is intending to say. Perhaps >>>>>>> "harmonizing the payment experience across all Web applications and >>>>>>> sites." >>>>>>> >>>>>> >>>>>> it sounds ok. >>>>>> >>>>>> >>>>>>> I would also include that it should facilitate that the user can >>>>>>> know the payment options available and even the (automatic) >>>>>>> negotiation of these options. >>>>>>> >>>>>>> >>>>>>> Is this not covered under the bullet: "*Provides payees and payers >>>>>>> unencumbered knowledge and choice in how to undertake payments*"? >>>>>>> >>>>>> >>>>>> May be. >>>>>> >>>>>> >>>>>>> - I would also incluse some comment on that the way of making the >>>>>>> encapsulation of (new or existing) payment schemes should be >>>>>>> uniform >>>>>>> and independent of the type of payment scheme (mobile or not). >>>>>>> >>>>>>> >>>>>>> I think this is implied by the fact that we are "standardizing" this >>>>>>> process. >>>>>>> >>>>>>> - From my point of view, I do not why know why the document needs >>>>>>> the bullets "Enables monetization on the spectrum of Web to >>>>>>> native >>>>>>> apps" and "Bridges distributed value networks should part of the >>>>>>> vision.". From my point of view, these issues are a consequence >>>>>>> of >>>>>>> "Encapsulates existing payment schemes and enables new schemes. " >>>>>>> >>>>>>> >>>>>>> No, the first bullet you mention is explicitly talking about enabling >>>>>>> new business models on the Web due to the reduction in friction and >>>>>>> cost >>>>>>> of payments (monetization). This speaks to things like enabling >>>>>>> pay-per-click/read/watch/listen media consumption or >>>>>>> similar which >>>>>>> >>>>>> >>>>>> >>>>>> This last explanation is clearer since the previous one, in my >>>>>> opinion, do not involve something clear related to the defintion of the >>>>>> payment architecture. >>>>>> >>>>>> can't be easily done today because the way payments are >>>>>>> processed makes these business models non-viable. >>>>>>> >>>>>>> The second is explicitly calling out the need for the architecture to >>>>>>> allow payers and payees to make a transfer of value between one >>>>>>> another, >>>>>>> even if they don't have a common payment instrument or scheme. i.e. >>>>>>> The >>>>>>> Web must work like the Web is supposed to and have a mechanism to >>>>>>> fill >>>>>>> the gaps and comment the two. >>>>>>> >>>>>> >>>>>> With this explanaition I understand your idea. But, from my point of >>>>>> view, in the end, this is making a kind of "P2P payment", which we could >>>>>> consider as a new payment scheme. >>>>>> >>>>>> Best regards, >>>>>> Antonio. >>>>>> >>>>>> >>>>>>> - As for security and privacy, the sentences that mention >>>>>>> "Supports >>>>>>> a wide spectrum of security requirements and solutions" or >>>>>>> similar >>>>>>> should be reworded. Why a "wide spectrum"?. I consider that the >>>>>>> security, privacy and regulatory issues have to be taken into in >>>>>>> the >>>>>>> development of an e-commerce website or e-payment solution. >>>>>>> However, >>>>>>> I consider that, e.g., the support of different authentication >>>>>>> mechanisms is not part of the payment architecture. However, in >>>>>>> the >>>>>>> processes that are part of the payment process, for example, >>>>>>> getting >>>>>>> a payment offer, the payment architecture should define the >>>>>>> mechanisms to protect this information. Then, I consider that in >>>>>>> the >>>>>>> bullet we could say that security, privacy and regulatory issues >>>>>>> will be taken into account to design the different process of >>>>>>> payment architecture that need to be securized. >>>>>>> >>>>>>> >>>>>>> Our intention is to propose an architecture and ultimately define >>>>>>> some >>>>>>> standards. When it comes to regulation and security I think our >>>>>>> approach >>>>>>> is to cater for everything we know is out there but not prescribe how >>>>>>> implementations are built. When it comes down to an implementer >>>>>>> deploying a solution in a specific jurisdiction subject to specific >>>>>>> laws >>>>>>> and regulations they should not be restricted by the architecture in >>>>>>> trying to adhere to these. On the other hand the architecture should >>>>>>> describe at what points these issues come into scope and provide >>>>>>> mechanisms to deal with them so that we make the life of the >>>>>>> implementer >>>>>>> easier. >>>>>>> >>>>>>> Best regards, >>>>>>> Antonio. >>>>>>> >>>>>>> >>>>>>> >>>>>>> El 18/05/2015 a las 14:58, Adrian Hope-Bailie escribió: >>>>>>> >>>>>>> The IG are trying to finalize a short vision statement for >>>>>>> the >>>>>>> work we >>>>>>> are undertaking, specifically with regards to the >>>>>>> architecture >>>>>>> we will >>>>>>> be developing, for payments on the Web. >>>>>>> >>>>>>> The document is intended to express the technical principles >>>>>>> we >>>>>>> consider >>>>>>> important in the design of the architecture and I'd >>>>>>> appreciate some >>>>>>> input on it's content. >>>>>>> >>>>>>> The document is also intended to be short, less than a page, >>>>>>> and >>>>>>> as such >>>>>>> not too detailed. It's purpose is to frame the design and >>>>>>> allow all >>>>>>> stakeholders to agree up front that we are aligned on our >>>>>>> vision. >>>>>>> >>>>>>> The audience should be broad, and not necessarily payments >>>>>>> or Web >>>>>>> technology experts, but since this is related to the design >>>>>>> of a >>>>>>> technical architecture the content will be technical. >>>>>>> >>>>>>> Please have a look at the first draft of this document and >>>>>>> send >>>>>>> me your >>>>>>> feedback. >>>>>>> >>>>>>> >>>>>>> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision >>>>>>> >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> >>>>>>> p.s. Thanks Ian Jacobs for the initial work in getting this >>>>>>> started. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -------------------------------------------------------- >>>>>>> Antonio Ruiz Martínez >>>>>>> Department of Information and Communications Engineering >>>>>>> Faculty of Computer Science-University of Murcia >>>>>>> 30100 Murcia - Spain >>>>>>> http://ants.inf.um.es/~arm/ or http://webs.um.es/arm/ >>>>>>> e-mail: arm@um.es <mailto:arm@um.es> or arm [at] um [dot] es >>>>>>> -------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> -------------------------------------------------------- >>>>>> Antonio Ruiz Martínez >>>>>> Department of Information and Communications Engineering >>>>>> Faculty of Computer Science-University of Murcia >>>>>> 30100 Murcia - Spain >>>>>> http://ants.inf.um.es/~arm/ or http://webs.um.es/arm/ >>>>>> e-mail: arm@um.es or arm [at] um [dot] es >>>>>> -------------------------------------------------------- >>>>>> >>>>> >>>>> >>>> >>> >> >
Received on Saturday, 30 May 2015 18:30:17 UTC