- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Tue, 26 May 2015 15:50:12 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Antonio Ruiz Martínez <arm@um.es>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CA+eFz_+Dcyxio-g2+3bmsVPoZUSEpQOBSVsw_J4Z1096YzJh2A@mail.gmail.com>
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. 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 13:50:45 UTC