- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Tue, 26 May 2015 16:01:51 +0200
- To: Timothy Holborn <timothy.holborn@gmail.com>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Antonio Ruiz Martínez <arm@um.es>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CA+eFz_+EoF=-Vvs-V4qSL0TfkSwhtQ0Qxt+EpfSWrom5N1D8Tg@mail.gmail.com>
Thanks Tim. It's an excellent document. I need to read it again a few times and then will provide some feedback On 26 May 2015 at 15:56, Timothy Holborn <timothy.holborn@gmail.com> wrote: > More work has been done on the framing document I've been working on. > > > https://docs.google.com/document/d/1pRtTu9EssjhyyK3qkQymZepIUkqCwvMo6imnr4fqsrg/edit?usp=sharing > > Theory is to boil down some very big concept, Into something that can be > used to reduce further to the 'vision statement' page or so... > > Link should enable commenting... > On Tue, 26 May 2015 at 11:52 pm, 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. >> >> >> >> 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:02:20 UTC