W3C home > Mailing lists > Public > public-webpayments@w3.org > May 2015

Re: [Payments Architecture] A vision statement for the web payments architecture work

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:40 UTC