- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 26 May 2015 16:10:26 +0200
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Antonio Ruiz Martínez <arm@um.es>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKaEYhKxwR2Xh6U6OP2hEH_g9ETprtSevtubeY6FPB5PkHLUbg@mail.gmail.com>
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 Tuesday, 26 May 2015 14:10:55 UTC